RFC 8601 — Authentication-Results ヘッダーフィールド

Proposed Standard Email Authentication Obsoletes RFC 7601 Published March 2026

ELI5: 手紙が企業の郵便室に到着すると、警備員は配送ドライバーのIDを確認し、差出人住所を検証し、改ざん防止シールを検査します。その後、調査結果をまとめた付箋を手紙に貼り付けます。「ドライバーID確認済み、差出人住所確認済み、シール無傷。」Authentication-Resultsヘッダーはその付箋です。受信メールサーバーがすべての認証チェック結果を記録するための標準化された方法で、これにより下流のフィルター、スパムエンジン、メールクライアントが再度チェックを実行することなく情報を利用できます。

このRFCが存在する理由

メール認証には複数の独立したメカニズムが関わります：SPF、DKIM、DMARC、ARCなど。それぞれが独自の結果を生成します。これらの結果を記録する標準的な方法がなければ、メール配信パイプラインのすべてのコンポーネント（コンテンツフィルタ、スパム分類器、ユーザーフェイシングクライアント）が、すべての認証メカニズムを独立して再評価する必要があります。

RFC 8601はAuthentication-Resultsヘッダーフィールドを定義しており、これはボーダーMTA（インターネットからメッセージを受け取るインフラストラクチャ内の最初のサーバー）がすべての認証チェックの結果を単一のヘッダーに記録するための構造化された方法です。この結果は、その後のすべてのコンポーネントで使用できます。

RFC 8601はRFC 7601を廃止し、RFC 7601はRFC 5451を廃止しました。更新により、構文が改善され、追加のメソッドキーワードが登録され、信頼境界の処理が明確化されました。

動作方法

ヘッダー構造

Authentication-Resultsヘッダーには定義された文法があります：

Authentication-Results: <authserv-id>; <method>=<result> [reason=<text>] [<property>.<type>=<value>] [; ...]

実例

Authentication-Results: mx.receiver.com;
dkim=pass header.d=example.com header.s=mtg20240101 header.b=LjIEJLN;
spf=pass (sender IP is 198.51.100.25) smtp.mailfrom=example.com;
dmarc=pass (p=reject dis=none) header.from=example.com;
arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

生成方法

ボーダーMTAがSMTP経由でインターネットからメッセージを受け取ります。
エンベロープ送信者と接続IPに対してSPFチェックを実行します。
DNSで公開鍵をクエリしてDKIM署名を検証します。
DMARCポリシーと整合性を評価します。
メッセージ上に存在するAARCチェーンを検証します。
すべての結果を要約したAuthentication-Resultsヘッダーを、自身のホスト名（authserv-id）を識別子として前置します。
下流のコンテンツフィルタ、スパムエンジン、配信ロジックはこのヘッダーを読み、チェックを再実行しません。

主要な技術的詳細

authserv-id

Authentication-Results:の後の最初のトークンはauthserv-idで、通常はチェックを実行したサーバーのホスト名です。これは信頼のために重要です：受け取るシステムは、authserv-idが自身の管理ドメイン内のサーバーと一致するAuthentication-Resultsヘッダーのみを信頼すべきです。外部サーバーからのヘッダーは削除または無視する必要があります。

メソッドキーワード

IANAは認証メソッドキーワードのレジストリを保持しています。最も一般的に使用されるのは：

メソッド	チェック内容	定義
`spf`	エンベロープ送信者のSPF評価	RFC 7208
`dkim`	DKIM署名検証	RFC 6376
`dmarc`	DMARC整合性とポリシー評価	RFC 7489
`arc`	ARCチェーン検証	RFC 8617
`auth`	SMTP AUTH（RFC 4954）認証情報	RFC 4954
`iprev`	接続IPの逆引きDNS検証	RFC 8601

結果値

各メソッドは以下の結果値のいずれかを生成します：

結果	意味
`pass`	認証に成功しました。
`fail`	認証が明確に失敗しました。
`softfail`	認証が失敗しましたが、送信者ポリシーは拒否するのではなく疑わしいものとして扱うことを示唆しています（SPF固有）。
`neutral`	送信者は主張がありません（SPF `?all`）。
`none`	認証レコードが見つかりません（SPFレコードがない、DKIM署名がない、DMARCポリシーがないなど）。
`temperror`	一時的な失敗（DNSタイムアウトなど）。後でもう一度試してください。
`permerror`	永続的なエラー（不正な形式のレコード、DNS照会が多すぎるなど）。
`policy`	メッセージは認証に合格しましたが、ローカルポリシーチェックに失敗しました。

プロパティタイプ

各結果には詳細を提供するプロパティ/値のペアを含めることができます：

プロパティ	説明
`header.d`	DKIM署名ドメイン（`d=`タグ）
`header.s`	DKIMセレクタ（`s=`タグ）
`header.b`	短縮されたDKIM署名ハッシュ（最初の8文字）
`header.from`	メッセージ`From:`ヘッダーのドメイン
`smtp.mailfrom`	エンベロープ送信者ドメイン（MAIL FROM）
`smtp.helo`	送信者が使用するEHLO/HELOホスト名

複数の結果

単一のAuthentication-Resultsヘッダーは複数のメソッドからの結果を含むことができ、セミコロンで区切られます。また、複数のAuthentication-Resultsヘッダーが存在することもあります（例：メソッドごとに1つ）。どちらのアプローチも有効です。

信頼境界

最も重大なセキュリティ上の考慮事項：外部ソースからAuthentication-Resultsヘッダーを信頼しないでください。攻撃者はdkim=passとdmarc=passを主張する偽造Authentication-Resultsヘッダーを含めることができます。ボーダーMTAは、自身のauthserv-idと一致するすべての既存Authentication-Resultsヘッダーを削除するか、自身の管理ドメイン内で追加されたことを確認できるヘッダーのみを信頼する必要があります。

一般的な間違い

外部A-Rヘッダーを信頼する：最も危険な間違い。メールシステムが外部からのAuthentication-Resultsヘッダーを削除または無視しない場合、攻撃者は偽の結果を注入できます。常に自身のauthserv-idを使用する受信A-Rヘッダーを削除してください。
ボーダーで結果を記録しない：認証チェックがボーダーMTAで実行されるが、結果がヘッダーに記録されない場合、内部フィルタリングシステムは認証データを持たず、すべてのチェックを再実行する必要があります（ネットワーク位置が変わったため異なる結果が生成される可能性があります）。
曖昧なauthserv-id：一般的なホスト名（「localhost」など）をauthserv-idとして使用すると、自身のシステムからのA-Rヘッダーと他のシステムからのヘッダーを区別することが不可能になります。完全なMXホスト名を使用してください。
DKIM結果の誤読：dkim=passの結果だけでは、メッセージが安全であることを意味しません。header.d値をチェックして、どのドメインがそれに署名したかを確認してください。d=attacker.comの合格はexample.comからのメッセージには無意味です。これがDMARC整合性が重要な理由です。
noneの結果を無視する：noneの結果は、レコードが見つからなかったことを意味します。SPFやDMARCの場合、これはドメインが認証ポリシーを公開していないことを意味します。この欠落は明示的なfailとは異なる扱いを受けるべきです。

配信可能性への影響

診断の宝庫：配信可能性の問題をトラブルシューティングする場合、Authentication-Resultsヘッダーが最初に確認する場所です。受け取るサーバーが見たもの、どのチェックが合格したか失敗したか、そしてその理由が正確に分かります。
フィルタリング決定を駆動：主要なメールプロバイダ（Gmail、Microsoft、Yahoo）は認証結果をスパムフィルタリングの主要な入力として使用します。spf=pass、dkim=pass、dmarc=passを持つメッセージはインボックスに到達する可能性が大幅に高まります。
ARC統合：ARC内のARC-Authentication-Resultsヘッダーは標準のAuthentication-Resultsヘッダーと同じ形式に従い、転送ホップ全体での一貫した報告を保証します。
透明性：RFC 8601はメール認証結果をメッセージヘッダーで公開することにより、メール認証を観察可能かつデバッグ可能にしています。送信者は受信者に生のヘッダーを転送させて認証失敗を診断するようリクエストできます。
機械可読形式：構造化されたフォーマットにより、自動化されたシステムが認証結果を解析して対応するのが簡単になり、プログラマティック配信可能性監視が可能になります。