【要点】メールの認証結果は、差出人を確かめる材料ですが、本文やリンクの安全証明ではありません。Return-Pathが表示差出人と違うだけで詐欺とはいえず、SPF・DKIM・DMARCが成功していても、請求やログイン要求が正当とは限りません。
なりすましの確認では「誰を名乗っているか」「どのドメインが認証されたか」「何を要求しているか」を分けます。企業名が見えることと、企業がその手続きを依頼したことを混同しないための読み方です。
ADVERTISEMENT
本文の食い違いと、差出人の確認を組み合わせる
管理者を名乗るメールには、次のような文面がありました。本文の抜粋です。
Access will be suspended by the end of today unless the password is updated.
Keep Same Password ►
上の文は「パスワードを更新しなければ今日中に停止」、ボタンは「同じパスワードを維持」という意味で、要求が食い違っています。このような不自然さに気付いたら、差出人の表示名だけで結論を出さず、認証対象のドメインと、会社が指定する正規の変更手順を照合してください。
文面の不整合を見つけても、それだけでSPF・DKIM・DMARCが失敗しているとは判断できません。本文の判断と認証の検証は別です。設定確認・パスワード期限メールの本文全体と注意点も確認できます。
From・Return-Path・Reply-Toは別の項目
メールソフトで見える差出人には、表示名とメールアドレスがあります。「Microsoft」「Amazon」などの表示名は、それ自体では本人確認をしていません。まず詳細表示を開き、表示名の隣や下にあるアドレスを確認します。
- From:通常、利用者に差出人として表示されるヘッダー。表示名だけを見ないでください。
- Return-Path:配送エラーの通知先に関わるエンベロープ送信者の情報。一般の返信先と同じ意味ではありません。
- Reply-To:返信先として指定されるアドレス。存在しなければ通常はFromが返信先になります。
メール配信代行や問い合わせシステムでは、これらのドメインが異なる正規メールもあります。反対に、すべてが似た文字列でそろっていても、似せた別ドメインを使っている可能性があります。「不一致なら100%詐欺」「一致なら安全」という判定には使わないでください。
SPF・DKIM・DMARCがそれぞれ確認していること
| 方式 | 主な確認対象 | 保証しないこと |
|---|---|---|
| SPF | 送信IPが、エンベロープ送信者などのドメインから許可されているか。 | 画面の表示名が本物であることや、本文の正しさ。 |
| DKIM | 署名ドメインの鍵で、署名対象のヘッダー・本文を検証できるか。 | 署名した組織が信用できることや、添付の安全性。 |
| DMARC | SPFまたはDKIMの成功と、表示Fromのドメインとの整合。 | そのメールが正当な請求・依頼であること。 |
DMARCはSPFとDKIMの両方が成功しなければ必ず失敗する、という仕組みではありません。少なくとも一方が成功し、対応するドメインがFromと整合することが判定の要点です。整合の条件には厳格・緩和の違いがあるため、文字列が完全一致しているかだけで手計算しないでください。MicrosoftのDMARC解説が詳しく説明しています。
攻撃者が自分のドメインで送ったメールでも、認証は成功し得ます。また、正規アカウントやサービスが悪用される場合もあります。認証PASSは「そのメールの要求に従ってよい」という許可ではありません。
認証失敗や未認証も、単独では詐欺確定にならない
転送や配信経路によってSPFが失敗したり、途中の本文変更などでDKIMが失敗したりすることがあります。正規のメールでも設定上の問題が起きます。Gmailの認証確認に関する説明でも、認証の有無とスパム判定を同一視しない注意が示されています。
未認証だから無視してよい業務連絡だと決めつけず、送信者へ別経路で照会してください。反対に、以前やり取りした相手だからと警告を解除してリンクを開くのも避けます。Microsoftの認証トラブルの説明は、管理者が転送・整合・設定の問題を切り分ける際に使えます。
ヘッダーを見るときの順番と注意点
- メールを返信・転送せず、元のメッセージの詳細やソース表示を開きます。通常の転送では、調査対象のヘッダーが失われることがあります。
- From、Reply-To、Return-Path、Authentication-Resultsなどの項目を確認します。
- 認証結果の文字だけでなく、対象ドメインも確認します。「pass」がどのドメインについての判定なのかを見ます。
- 契約・注文・依頼の内容は、公式アプリや既知の連絡先で別に照合します。
Authentication-Resultsが複数あるときは、どのサーバーが付けた結果かも問題になります。攻撃者がヘッダーのような文字列を付けることもできるため、本文に貼られた「SPF:PASS」を信用せず、利用中の受信サービスが付与・表示する結果を起点にしてください。どの行を信頼できるか分からない場合は、管理者に原本を渡して確認してもらいます。
Received行にも偽装可能な部分があります。行数や国名らしい表示だけで発信国・犯人を特定しないでください。差出人に表示されたアドレスの持ち主が、なりすましやアカウント侵害の被害者である場合もあります。
企業名・金額・件名から見分けるときの注意
支払い更新やポイント失効を告げるメールは、身近な企業名と具体的な数字で本物らしく見せることがあります。ロゴや署名だけに頼らず、自分の契約や残高を公式の管理画面で確認してください。
認証結果がメールソフトに表示されない場合、それだけで「認証失敗」とは限りません。詳細表示や元のメッセージで確認し、判断が難しければ管理者へ相談してください。
空白や見えない文字が混じる件名は、見た目と文字列が一致しないことがあります。件名検索で同じ例が出なくても、安全の証明にはなりません。ブランド名や要求内容でも調べ、公式側の契約・利用状況と照合してください。
解析結果を見た後にすること
不審な要求には返信・入力せず、メールサービスの報告機能を使います。ログイン情報を入力した場合は、安全な端末から公式のアカウント保護手続きへ進んでください。会社アカウントなら管理者への連絡を優先します。認証結果の精読より、すでに渡した情報への対処を先にすべき場面です。
不審メール・URL安全確認ツールは、情報を整理するための補助です。判定だけで送信者やリンク先の安全を保証するものではありません。元メールには宛先、内部サーバー名、追跡用の識別子などが含まれることがあるため、公開の掲示板やSNSに原文を載せないでください。
具体的な通知への対応は、Amazonの配送・ログイン・返金通知の確認方法、メール設定確認・停止予告への対処を参照できます。
まとめ
メールヘッダーは「認証された送信ドメイン」を調べる手掛かりです。「安全な内容」を証明するものではありません。FromとReturn-Pathの違いだけで決めず、認証結果の対象、受信サービスの判定、公式画面での事実確認を組み合わせましょう。
届いたメールの内容から確認する
超解決 第一編集部
疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。