メールヘッダーを調べるときは、受信側が記録した認証結果を確認し、その後に送信経路を追います。ただし、SPF・DKIM・DMARCがすべてpassでも、メールの内容や送信者本人の安全性を保証するものではありません。

調査のためにヘッダーを読むことと、メールに書かれた依頼へ応じることは別です。支払いやログインを急かすメールなら、解析結果にかかわらず別の連絡経路で確認してください。利用者としての初動はフィッシングメールへの対応で扱っています。

受信したメールの原文を取得する

調べるのは、受信した元メールのヘッダーです。普通の転送操作をしたメールでは、転送メッセージ側の情報を見てしまう場合があります。元メールを選び、使っているメールサービスの原文表示機能を開きます。

Gmailのパソコン版では、メールの返信ボタン横にあるその他のメニューから「メッセージのソースを表示」を選びます。画面名や他のメールソフトの手順は、Googleのヘッダー確認手順など、利用環境に対応した案内を確認してください。

原文には本文や添付ファイルが続く場合があります。調査に必要なヘッダーと、それ以外の部分を区別し、社内の共有方法に従って保管します。メールアドレスや内部サーバー名が含まれるため、そのまま公開掲示板へ貼り付けない方が良いです。外部へ相談する場合も、原本は保存したまま共有用のコピーを用意します。

最初に受信側のAuthentication-Resultsを探す

Authentication-Results は、そのメールを認証したシステムの判定記録です。次は形式を説明するための仮の例で、実在するメールの安全判定ではありません。

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.sender.example;
  dkim=pass header.d=sender.example;
  dmarc=pass header.from=sender.example

最初の mx.receiver.example は判定したシステムの識別子です。複数の同名ヘッダーがある場合、都合の良いpassだけを選んではいけません。受信サービスが信頼する経路で付けた記録を確認します。識別子の文字列は偽装もできるため、有名サービス名が書かれているだけでは根拠になりません。

認証結果を信頼できる範囲についてはRFC 8601に定義されています。どの記録が受信側のものか分からなければ、メール管理者に原文と受信日時を渡し、判定元を確認するところで止めます。

passの対象は認証方式ごとに違う

判定結果の文字だけでなく、どのドメインに対する結果かを見ます。差出人の表示名が本物に似ているかどうかを、これらの認証が判定しているわけではありません。

項目主に照合するものpassだけでは分からないこと
SPF送信元IPとエンベロープ送信元等のドメインの許可表示上のFromが同じドメインか
DKIM署名ドメインの公開鍵と署名対象部分書いた人が本人か、内容が無害か
DMARCFromのドメインと、成功したSPFまたはDKIMのドメインの整合依頼内容やリンク先が安全か

DMARCは、SPFかDKIMの少なくとも一方が成功し、Fromとの整合条件も満たすとpassになります。両方の成功が必須という意味ではありません。この関係はDMARCの仕様で説明されています。

転送やメーリングリストを通ると、正規のメールでも認証結果が変わる場合があります。一方、攻撃者自身が管理するドメインのメールも認証に成功できます。Gmailの認証に関する説明も、未認証だから迷惑メールとは限らず、迷惑メール側が認証を利用する場合もあるとしています。

none は認証方式ごとの「判定できる情報がない」などの状態で、一律にDNS未設定と決めません。temperror や permerror があれば、単なる不一致と分けて調べます。Microsoft 365では認証結果のトラブルシューティングに各方式の値が整理されています。結果に応じて送信・受信側のどちらへ確認するかを決めてください。

FromとReturn-Pathが違っても偽装とは限らない

表示上の差出人は From、通常の返信先を別途指定する項目は Reply-To です。Return-Path は配送エラーの通知先を表すもので、通常の返信先や送信者本人の身元を証明する項目ではありません。

配信サービスを経由したメールでは、FromとReturn-Pathが別ドメインになる場合があります。一致・不一致だけで結論を出さず、受信側の認証結果と合わせて読みます。メール形式のRFC 5322と配送を定義するRFC 5321では、それぞれの役割が分けられています。

同様に、Message-ID のドメインや X-Mailer の製品名だけでは正当性を確認できません。メールを探す際の手がかりとして管理者へ渡す情報と、安全と判断する根拠を混同しないことが重要です。

Receivedは受信側から信頼できる範囲をたどる

Received はメールを受け取ったサーバーが先頭側へ追加する記録です。通常、並びを下から上へ見ると古い順になります。ただし、最下段まで本物の記録とは限りません。まず自分の受信サービスが付けた行を確認し、そのサービスが受け取った相手へとさかのぼります。

Received: from relay.sender.example (relay.sender.example [203.0.113.10])
  by mx.receiver.example with ESMTP;
  Fri, 18 Sep 2026 10:00:05 +0900

この仮の例では、by が記録した受信側、from が受け渡し相手です。信頼できる受信側の記録から読み始めれば、送信側が事前に入れた偽の行をそのまま出発点にする誤りを避けられます。ヘッダーだけで送信者の端末IPまで必ず追えるわけではありません。

配送遅延を調べる場合は、タイムゾーンを揃えて隣り合う記録の時刻を比較します。サーバー時計のずれもあるため、一つの差だけで障害箇所を断定せず、管理者側の配送ログと照合します。時刻表記で迷う場合はUTCと日本時間の読み方も参照してください。

解析ツールは記録を整理するために使う

メールヘッダー解析ツールでは、貼り付けたヘッダーから項目を抽出できます。現在の実装はブラウザ内で処理しますが、入力された記録そのものの真偽や、受信サービスの信頼関係まで証明するものではありません。表示されたpassや警告は、調査の出発点として扱います。

また、メール認証チェッカーが見る現在のDNS設定と、ヘッダーに残る受信時点の判定は別です。設定変更後に古いメールを解析しても、記録された結果は更新されません。再確認には変更後に送ったテストメールを使います。

問い合わせる際は、元メールと受信日時を用意します。期待した動作と実際の症状も伝えてください。認証の問題なら判定元と結果を、遅延なら信頼できるReceivedの区間を示します。ヘッダーから分かる事実と、まだ確かめていない原因を分けて渡すと、次の調査へつなげやすくなります。