メールヘッダーの見方と仕組み

ヘッダーの要件

ヘッダーフィールドはメッセージ形式に従う

RFC 5322では、メールのヘッダーはヘッダーフィールドの並びでなければなりません。各フィールドはフィールド名、コロン、フィールド本体からなります。フィールド名には、スペース、制御文字、コロンを除く印字可能なUS-ASCII文字を使います。長いフィールドを次の物理行に続けられる折り返し規則も定義されています。

From: alerts@yourdomain.com
To: recipient@example.net
Subject: Illustrative delivery notice
Date: Tue, 11 Aug 2026 12:00:00 +0000
Message-ID: <example-12345@yourdomain.com>

上の値は説明用です。Fromは受信者に示される作成者のアドレスを、Message-IDは特定のメールを識別します。どちらのフィールドも、それだけではドメインがそのメールを許可したことの証明になりません。認証チェックでは別の入力とポリシーを使います。

フィールドがメールに含まれる理由は、RFC 5322で定義されているから、SMTPサーバーが追加したから、受信システムが運用データを追加したから、とさまざまです。各フィールドは、その出どころと目的に沿って読みます。生のヘッダーのすべての行を同じように信頼してはいけません。

SMTPリレーはReceivedを先頭に追加

SMTPサーバーがメールを受信して次へ転送する場合、RFC 5321はReceivedタイムスタンプのトレースレコードの挿入を求めています。挿入位置はメッセージ内容の先頭です。新しいトレースレコードが先頭に追加されるため、最も古いサーバーのトレースは通常ヘッダーの下のほうに、最新のものは上のほうにあります。

Received: from outbound.yourdomain.com (outbound.yourdomain.com [192.0.2.10])
        by mx.example.net with ESMTPS id example123
        for <recipient@example.net>; Tue, 11 Aug 2026 12:00:00 +0000

これは説明用のトレースで、公開するレコードではありません。経路を再構成するときは、Receivedの連なりの下のほうから上へ読みます。トレース行は、受信したサーバーが受け取ったと主張する内容です。信頼できるインフラに届く前に追加された行は偽造できるため、この連なりだけでは完全なフォレンジックの結論になりません。

例にある転送ラベルについてはESMTPSの意味をご覧ください。

認証サービスは自身の結果を記録する

Authentication-Resultsは、認証サービスが実行したチェックの結果を報告するためのトレースフィールドです。RFC 8601では、認証サービスの識別子、方式ごとの結果、任意のプロパティなどの構文を定めています。一般的な方式はSPF、DKIM、DMARCです。

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=mail.yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

この例は説明用です。smtp.mailfromはSPF関連の識別情報、header.dはDKIMの署名ドメイン、header.fromはDMARCで評価されるドメインを示します。dkim=passという結果は、認証サービスが独自の規則で有効なDKIM署名を評価したことを意味します。それだけでは、表示上のFromドメインとのDMARCアライメントは確定しません。

RFC 8601は信頼の境界も定めています。受信側は、どの認証サービスを信頼するかを決めなければなりません。送信者は配信前に、認証結果に見える文字列を挿入できます。ヘッダーの下のほうにある未検証の行に頼らず、メールボックスプロバイダーなど信頼できる受信インフラが追加した結果を重視してください。

要件の適用時期

メールヘッダーに関する新しい準拠期限は1つもありません。RFC 5322は2008年10月にインターネット標準として公開され、RFC 2822を廃止しました。RFC 5321は2008年10月に公開され、Receivedレコードを含むSMTPのトレース要件を定義しています。RFC 8601は2019年5月に公開され、Authentication-Resultsヘッダーフィールドを定義し、RFC 7601を廃止しました。

これらの規格が定めるのは、メッセージとトレースの動作です。すべての送信者にSPF、DKIM、DMARCの導入を求める共通の期限は定めていません。メールボックスプロバイダーの送信者要件では、別の要件、しきい値、適用開始日が課されることがあります。それらはヘッダーの構文そのものとは分けて考えてください。

メールヘッダーの見方：確認手順

1. 本番経路で検証用のメールを送る

本番メールを送るのとまったく同じアプリケーション、ESP、リレーからテストメールを送ります。元のソースを開ける安全な受信用メールボックスを使います。別のテストシステムから送ったメールでは、本番の送信経路を検証できません。

2. メールのソースを書き出す

メールボックスプロバイダーが案内している方法で、元のメールまたはメールのソースを表示します。Gmailの場合は、Gmailでメールヘッダーを表示するに「メッセージのソースを表示」の手順があります。転送するとフィールドが追加され、証拠が変わることがあるため、転送する前にヘッダー全体をコピーします。

3. メッセージフィールドとトレースフィールドを分けて読む

まずFrom、Date、Subject、Message-IDの各フィールドを確認します。次にReceivedレコードを見つけ、信頼できる最も古いレコードから最終配信に向けてサーバーのトレースを読みます。

表示される送信者アドレスが認証済みだと思い込まないでください。これはRFC 5322の作成者フィールドです。認証の証拠は、信頼できるAuthentication-Resultsレコードと、その元になるSPF、DKIM、DMARCの評価にあります。

4. 認証の識別情報を表示上のドメインと比べる

信頼できるAuthentication-Resultsフィールドの中でspf=、dkim=、dmarc=を探します。header.fromをFromのドメインと比べます。DMARCが失敗している場合は、DNSや送信プラットフォームを変更する前に、報告されたSPFとDKIMの識別情報を確認します。

DNSレコードに問題がなくても、アプリケーションがそのレコードを使ったとは限りません。ヘッダーに別のReturn-PathドメインやDKIM署名ドメインが出ている場合は、その本番設定を個別に調査します。プロトコル層の関連情報はメール認証の学習ハブにあります。

正しく設定できているかの検証

検証には、複数の層の証拠が必要です。

• DNS：公開された認証設定を調べる場合は、権威DNSと公開リゾルバーで、ドメインの公開SPF、DKIM、DMARCレコードを確認します。
• ベンダー：送信プロバイダーにドメイン認証のステータス表示があれば、現在の状態を確認します。緑のステータスは、メールが配信されたことの証明ではありません。
• メール：本番経路から実際に配信されたメールと、その信頼できるAuthentication-Resultsフィールドを確認します。
• DMARC：集計レポートのデータが蓄積したら確認し、送信元と繰り返し起きるアライメントの失敗を特定します。

ヘッダーに認証の失敗があり、Gmailがメールをブロックしている場合は、Gmailの未認証送信者に関するガイドと照らし合わせます。Outlookで迷惑メールに振り分けられる問題なら、配信されたメールとプロバイダー側の証拠を、Outlookでメールが迷惑メールになる場合の対処法とあわせて確認します。認証は配信判断を支えますが、受信トレイへの到達は保証しません。

一通のヘッダーでは見えない送信元を把握する

ヘッダーが説明するのは、配信された一通のメールです。そのドメインを使うすべてのシステムの一覧、その後のアライメントのずれ、より厳しいDMARCポリシーに移行できる時期は分かりません。

Palisadeはエージェント型DMARCソフトウェアです。DMARC集計レポートのデータを分析し、送信元と、認証やアライメントの問題を特定して、優先度付きの修正チケットを作成します。証拠に基づいて次のポリシー段階を提案できますが、証拠を確認してDNSの変更を反映するのは人です。

Palisadeを始める

PalisadeがDMARCポリシーを自動で変更することはありません。配信や受信トレイへの到達も、今後のすべてのメールが認証されることも保証しません。