電子メールヘッダーの SPF、DKIM、および DMARC の結果を読み取る方法
Once Email 編集部レビュー Once Email 日本語編集レビュー
記事ガイド
この記事を読む価値
- 独自分析
- 当社は、認証 ID、アラインメント、およびメッセージの安全性を区別し、パスを信頼として扱うのではなく、結合された SPF、DKIM、および DMARC の証拠を解釈します。
- トレンドの背景
- 電子メール認証標準と展開ガイダンスは、新しい DMARC 作業を含めて成熟し続けていますが、可視的な送信者 ID を解釈する上で中心となるのは調整です。
- 実用的な価値
- 読者は、共通の結果フィールドを読み、メカニズムが一致しない理由を理解し、ヘッダーの証拠をコンテキストおよび独立した検証と組み合わせる必要がある場合を知ることができます。
このページの内容
電子メールのヘッダーには、SPF、DKIM、DMARC の結果が含まれることがよくあります。これらのメカニズムは、配信に関与するドメインとシステムに関する証拠を提供します。あらゆる種類の欺瞞を検査するわけではなく、メッセージ、送信者、またはリンクが安全であることを証明するものでもありません。
このガイドでは、Once Email メール ヘッダー アナライザー .アナライザーは、ブラウザーにローカルに貼り付けられたテキストを読み取ります。 DNS、レピュテーション、マルウェア、またはライブ ポリシー ルックアップは実行されません。
SPF: このシステムはエンベロープ ドメインに対して承認されましたか?
Sender Policy Framework を使用すると、ドメインは SPF ID を使用して送信を許可されているシステムを公開できます。受信システムは、接続している送信者と公開されたポリシーを比較し、pass、fail、softfail、neutral、none などの結果を記録します。
SPF は、表示される差出人フィールドに表示されるアドレスを単にチェックするだけではありません。 DMARC は SMTP MAIL FROM ID の SPF 結果を使用し、そのドメインが表示されている作成者のドメインと一致するかどうかを評価します。
転送サーバーが最終受信者に接続するシステムになるため、転送では SPF が複雑になる可能性があります。したがって、失敗した SPF 結果にはコンテキストが必要です。それ自体はメッセージについての完全な判断を下すものではありません。
DKIM: メッセージの署名された部分は検証されましたか?
DomainKeys Identified Mail は、署名ドメインに関連付けられた暗号署名を追加します。受信者は DNS から公開キーを取得し、署名されたヘッダー フィールドと本文がまだ検証されているかどうかを確認します。
DKIM パスは、署名されたマテリアルが署名ドメインに対して検証されたことを示す証拠です。表示名が正直であること、表示されるすべての要素が署名されているのか、リンクされた Web サイトが安全であることは証明されません。メール システムは、署名を破る方法でメッセージを合法的に変更することもできます。
DMARC: 認証された ID は、表示される作成者のドメインと一致しますか?
DMARC は SPF と DKIM に基づいて構築されています。認証された SPF または DKIM ドメインと、表示されている From アドレスのドメインを比較し、ドメイン所有者の公開ポリシーと受信者ポリシーを適用します。
現在の IETF 仕様 RFC 9989 では、DMARC がドメインレベルの識別子を認証し、表示名攻撃に対処したりメッセージの内容を分析したりしないと説明しています。 2026 年 5 月に古い RFC 7489 に置き換わりました。
2026 年の DMARC 改訂での変更点
RFC 9989 は、すべてのメッセージ システムが 2026 年に突然動作を変更したという証拠ではありません。RFC 9989 は、現在のプロトコル定義を統合し、RFC 7489 と RFC 9091 を明示的に廃止し、集計および障害レポートの形式を関連仕様に分離します。実際の読み取りルールは安定しています。DMARC パスは、可視の作成者ドメインの使用が許可された、調整された SPF または DKIM ID を意味します。これは、評判スコア、メッセージを書いた人の身元確認、リンクや添付ファイルのスキャンではありません。
この区別は、製品発表における「新しい DMARC 要件」を解釈する際に重要になります。プロバイダーは、基本プロトコルとは関係なく、配信ポリシーやバルク送信者の要件を変更する場合があります。たとえば、Gmail の 送信者ガイドライン では、送信量によって異なる認証要件が適用されます。プロバイダー ポリシー、プロトコル検証、メッセージ セーフティを 3 つの別個のレイヤーとして扱います。
DMARC パスとは、必要な調整を行って渡された、サポートされている少なくとも 1 つの認証パスを意味します。これは、作成者が個人的に認証されている、アカウントが侵害されていない、またはメッセージが無害であることを意味するものではありません。
認証結果の読み取り
簡略化されたヘッダーは次のようになります。
Authentication-Results: mx.example;
spf=pass smtp.mailfrom=mailer.example;
dkim=pass header.d=mailer.example;
dmarc=pass header.from=mailer.example
これらの値を一緒に確認してください。
Authentication-Resultsフィールドを書き込んだサーバーはどれですか?- SPF に合格したドメインはどれですか?
- DKIM で署名されたドメインはどれですか?
- 表示される差出人アドレスにどのドメインが表示されますか?
- DMARC は調整、失敗、またはポリシーを報告しませんか?
- 配送ルートは、予想した差出人にとって意味がありますか?
複数のシステムがメッセージを処理するため、ヘッダーには複数の結果フィールドが含まれる場合があります。多くの場合、信頼できる最新の受信者の結果が最も関連性が高くなりますが、どの仲介者が信頼できるかを判断するには、メールボックス プロバイダーと配信パスに関する知識が必要です。
パスが安全を保証しない理由
攻撃者は、自分が制御するドメインを認証できる可能性があります。正当な送信者のアカウントが侵害される可能性があります。正しく認証されたメッセージにも、誤解を招くリクエスト、悪意のある添付ファイル、または危険なリンクが含まれている可能性があります。
Gmail 送信者ガイドライン では、送信量に応じて異なる認証制御が必要であり、配信性と不正行為防止策として認証について説明されています。これらは、認証を一般的なコンテンツの安全性の判定に変えるものではありません。
メッセージが資格情報、金銭、緊急のアクション、または機密ファイルを要求する場合は、既知の連絡チャネルを通じて要求を確認してください。 From 名や緑色の認証結果のみに依存しないでください。
アナライザーは慎重に使用してください
メッセージ本文や添付ファイルではなく、ヘッダー フィールドのみを貼り付けます。アナライザーの概要とメッセージが到着したコンテキストを比較します。不足している証拠、不正な証拠、または矛盾する証拠は、自動的に不正が証明されるものとしてではなく、追加検証の理由として扱います。
インシデント対応、ドメイン構成、または影響の大きい決定については、メールボックス プロバイダーの元のメッセージ ビューを使用し、資格のある電子メール管理者またはセキュリティ専門家に相談してください。