ドメイン番人
メール認証DMARCトラブルシューティング

メールヘッダの読み方｜認証結果の確認手順

ドメイン番人約 8 分で読めます
目次

この記事でわかること

  • メールヘッダのうち、最初に読むべき 3 つのフィールド
  • Authentication-Results の spf= / dkim= / dmarc= の見分け方
  • Received ヘッダから配送経路と遅延箇所を特定する手順
  • 「届かない」「なりすまされた」のどちらに該当するかの切り分け

メールヘッダは「配送の領収書」

「取引先からメールが届かない」「迷惑メールに入る」と相談を受けたとき、最初に開くべきはメール本文ではなくヘッダです。ヘッダにはメールがどのサーバーを経由し、どの認証に通り（あるいは落ち）、最終的にどう判定されたかが時系列で書かれています。

Gmail なら「メッセージのソースを表示」、Outlook なら「メッセージ オプション」→「インターネット ヘッダー」で取得できます。テキストの塊として表示されますが、最初に見るべきフィールドは決まっています。

本記事は、ヘッダ解析の入口として Authentication-Results / Received / Return-Path の 3 点に絞って読み方を解説します。SMTP 応答コード視点の切り分けは SMTP 応答コード一覧 を併せて参照してください。

メールヘッダの主要 3 フィールドと読み解き順序

まず読むべき Authentication-Results

Authentication-Results は受信側メールサーバーが SPF / DKIM / DMARC の検証結果を 1 行にまとめたフィールドです。「届いた・届かない」「迷惑メールに入った」の原因の 8 割はこの行を読めば見当がつきます。

典型例：

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.co.jp header.s=selector1 header.b=ABC123;
       spf=pass (google.com: domain of bounce@example.co.jp designates 203.0.113.5 as permitted sender) smtp.mailfrom=bounce@example.co.jp;
       dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=example.co.jp

読み方は以下の通りです。

キー 値 意味
dkim= pass / fail / none DKIM 署名の検証結果。pass なら本文・ヘッダが改ざんされていない
spf= pass / softfail / fail / none 送信元 IP が SPF レコードに許可されているか
dmarc= pass / fail SPF または DKIM がアライメント込みで通ったか
header.from= 表示上の差出人ドメイン DMARC が評価したドメイン
smtp.mailfrom= エンベロープ送信者 バウンスが返るアドレス（Return-Path と同じ）
p= / sp= none / quarantine / reject 受信側が読み取った DMARC ポリシー

「dkim=pass だけど dmarc=fail」「spf=pass だけど dmarc=fail」というケースはアライメント不一致（署名ドメインと差出人ドメインが揃っていない）が原因です。用語の整理は SPF / DKIM / DMARC の違い を参照。

dkim= の補助フィールド

  • header.i= — 署名者の identity（多くは差出人と同じドメイン）
  • header.s= ：DKIM セレクタ（公開鍵を引く DNS 名）
  • header.b= ：署名の先頭バイト（同一署名の追跡用）

セレクタが想定外（例：SaaS の汎用セレクタが残っている、独自セレクタに切り替えたつもりが旧セレクタのまま）の場合、ここで気づけます。

spf= の括弧内コメント

spf=pass (google.com: domain of ... designates 203.0.113.5 as permitted sender) の括弧内は受信側 Google が独自に書き込むコメントです。designates ... as permitted sender の IP が、実際の送信元 IP になります。SPF レコードに含まれていない IP が出てきたら、そのメールは想定外の経路を通っています。

Received ヘッダで配送経路を遡る

Received ヘッダは経由したサーバーごとに 1 行追加され、下から上に時系列で並びます。一番下が送信側 MTA、一番上が受信側 MTA です。

Received: from mail-edge-01.example.co.jp (mail-edge-01.example.co.jp. [203.0.113.5])
        by mx.google.com with ESMTPS id ab1cd2ef3
        for <user@gmail.com>;
        Thu, 22 May 2026 09:15:23 -0700 (PDT)
Received: from app-server-7.internal (app-server-7.internal [10.0.7.42])
        by mail-edge-01.example.co.jp (Postfix) with ESMTPSA id 4XYZ12;
        Thu, 22 May 2026 09:14:08 +0900 (JST)

ここから読み取れることは 3 つあります。

  1. 送信元 IP：一番下の from IP（203.0.113.5）が外部に出た IP。SPF の spf= 行で見た IP と一致するか確認
  2. タイムスタンプの差：上下の時刻差が大きい（例：30 秒以上）なら、そのホップで遅延している
  3. 経由ホスト名：身に覚えのない中継サーバーが入っていれば、転送設定の存在や経路改変を疑う

配送遅延のクレームでは、Received のタイムスタンプを上から下に見れば、どのホップで時間が止まったかが一目でわかります。

Received ヘッダの読み順とタイムスタンプ追跡

Received-SPF / DKIM-Signature

Received-SPF は SPF 検証だけを独立して記録した旧形式のヘッダで、Authentication-Results と並んで残っていることがあります。値が食い違うことは基本ありませんが、Received-SPF: softfail のように具体的な softfail 理由が書かれている場合があります。

DKIM-Signature は署名そのもので、v=1; a=rsa-sha256; d=example.co.jp; s=selector1; のように構造化されています。d= が DKIM 署名ドメイン、s= がセレクタです。DNS 上の DKIM レコードを引くときの座標になります。検証手順は dig での SPF / DKIM / DMARC 確認方法 を参照。

Return-Path と From のずれを見抜く

Return-Path: はエンベロープ送信者（バウンスが返る先）、From: は表示上の差出人です。この 2 つのドメインが大きく異なる場合、メール送信代行サービス（メルマガ配信 / 通知サービス）か、なりすましの可能性があります。

Return-Path: <bounce+abc123@mailer.thirdparty.net>
From: "営業部 山田" <yamada@example.co.jp>

この例は ESP（外部メール送信業者）を経由したパターンで、正規利用ならよくあります。ただし DMARC は From: ドメインで評価するため、mailer.thirdparty.net の SPF を借りても example.co.jp の DMARC を pass させることはできません。DKIM を example.co.jp 名義で署名する（カスタムドメイン DKIM）か、DKIM アライメントが取れる構成が必須です。

なりすましメールでは、Return-Path / From の両方が攻撃者のサーバーに向き、表示名だけ正規っぽく書かれます。ヘッダで dmarc=fail かつ p=reject なのに配送されている場合、受信側の DMARC 評価が緩い（古い MTA や転送経由）か、表示上のなりすまし（display name spoofing）です。DMARC の用語整理は DMARC とは何か を参照。

5 分で切り分ける読解フロー

ヘッダ解析の現場でやる順番をまとめると以下のとおりです。

  1. Authentication-Results を 1 行目から見る ：dmarc= の結果がすべての出発点
  2. dmarc=fail なら SPF / DKIM どちらが落ちたか確認 ：spf=pass dkim=fail ならアライメントか署名失敗
  3. spf= の括弧内 IP と Received の一番下の IP を照合 ：想定の送信元か
  4. Return-Path と From のドメインを比較 ：一致しないなら ESP 経由 or なりすまし
  5. Received のタイムスタンプを上下で比較 ：遅延箇所の特定
  6. 必要に応じて DKIM-Signature の d= s= を確認 ：該当 DNS レコードを dig で引く

このフローで切り分けがつかない場合、受信側の隔離フィルタ（content filter）や IP レピュテーション要因の可能性があります。その場合は DMARC レポートの読み方 を参考に、複数日分の集約データで傾向を見るのが次の一手です。

よくある質問

Authentication-Results が複数行ある場合は

複数の MTA（受信前のゲートウェイ + Gmail 本体など）がそれぞれ検証結果を書き込むことがあります。最上段（Gmail 本体）の Authentication-Results が最終判定です。中間ゲートウェイの判定と異なる場合、ARC（Authenticated Received Chain）で結果を引き継いでいる可能性があります。

spf=none / dkim=none と書かれている場合は

「none」は検証されなかったという意味で、fail とは違います。SPF レコードが未設定、DKIM 署名が付与されていないと none になります。送信側で SPF / DKIM が未設定の場合の対処は SPF / DKIM / DMARC 設定方法 を参照。

ヘッダだけで「なりすまし」と断定できるか

dmarc=fail + 表示名と Return-Path のドメイン乖離 + 送信元 IP の地理的不自然さ、の 3 点が揃えばかなり濃厚ですが、最終的にはドメイン所有者にも確認するのが安全です。社内ドメインを名乗るメールが外部 IP から来ていれば、ほぼなりすましです。

まとめ

  • 最初に見るのは Authentication-Results。dmarc= の結果が起点
  • Received は下から上に時系列。タイムスタンプ差で遅延箇所が特定できる
  • Return-Path と From のずれは ESP 経由かなりすましのサイン
  • DKIM-Signature の d= s= は DNS で実物を確認するための座標
  • ヘッダ解析の習慣化が、配送トラブル対応の所要時間を 1/3 にする

まずは自社ドメインの状態を確認

ヘッダの解析方法を覚えても、自社の SPF / DKIM / DMARC が未設定だと「届かない」原因の特定は難しくなります。ドメイン番人の無料診断で、自社ドメインの認証状態を 30 秒で可視化できます。設定にお困りの場合はお問い合わせからご相談ください。

関連記事

次の一歩は無料診断から。

無料診断を試す →相談したい方はこちらから