← RFC Reference

メール認証の説明

SPF、DKIM、DMARC、およびARCがシステムとしてどのように連携するか、またはメッセージが受信サーバーに到着したときにステップバイステップで何が起こるかについて説明します。

メール認証が必要な理由

SMTPは1980年代初期に設計され、送信者の検証が組み込まれていません。どのサーバーでも他のサーバーに接続し、任意のアドレスからメールを送信していると主張できます。これはバグではなく、プロトコルがどのように構築されているかです。

メール認証は、3つの質問に答えるためにSMTPの上に層状に配置された標準のセットです。

1. SPF: このサーバーはこのドメインのメール送信を許可されていますか?
2. DKIM: このメッセージは本当に指定されたドメインによって送信され、変更されていないですか?
3. DMARC: SPFとDKIMの両方が失敗した場合、何をすべきか、またはいずれかの結果がFrom:ヘッダーと一致していますか?

各メカニズムは異なる攻撃面に対処します。一緒に、多層防御システムを形成します。

SPF: 送信を許可されている者

SPF(送信者ポリシーフレームワーク、RFC 7208)により、ドメインは自社の代わりにメールを送信することを許可されたサーバーのリストを公開できます。これはDNS TXTレコードです。

メッセージが到着すると、受信サーバーはMAIL FROM(エンベロープ送信者)からドメインを抽出し、DNS経由でSPFレコードをクエリします。接続サーバーのIPアドレスが許可されたメカニズムのいずれかと一致しているかどうかを確認します。

SPF評価結果:

• pass — IPは明示的に許可されています
• fail — IPは明示的に許可されていません(-all)
• softfail — IPはおそらく許可されていません(~all) — 受け入れるが記録する
• neutral — ドメインはこのIPについて何も主張しません(?all)
• temperror / permerror — DNSルックアップが失敗したか、レコードが不正です

SPFの制限

SPFはエンベロープ送信者を検証し、ユーザーが見るFrom:ヘッダーを検証しません。フィッシャーは、エンベロープで独自のドメインを使用し、From:ヘッダーであなたのドメインを詐称することでSPFをパスできます。SPFは、メールが転送される場合に破損します。元のドメインのSPFレコードに転送サーバーのIPが含まれていないからです。これらの制限により、SPFだけでは十分ではありません。

DKIM: 暗号署名メッセージ

DKIM(DomainKeysIdentifiedMail、RFC 6376)は、メッセージに電子署名を追加します。送信サーバーは、秘密鍵を使用して選択されたヘッダーとボディに署名します。対応する公開鍵がDNSに公開されます。

署名はDKIM-Signatureヘッダーとして追加されます。

キーDKIM-Signatureフィールド:

• d= — 署名ドメイン(DMARCがアライメントをチェックするもの)
• s= — セレクター、DNSで公開鍵を検索するために使用されます
• h= — 署名に含まれるヘッダー
• bh= — メッセージ本文のハッシュ
• b= — 実際の署名
• c= — 正規化アルゴリズム(relaxed/relaxedは標準 — 軽微な空白の変更を許容)

受信サーバーはDNSから公開鍵を取得し、署名付きヘッダーとボディ上でハッシュを再計算し、署名を検証します。一致する場合、メッセージはそのドメインの秘密鍵にアクセスできる者によって署名され、署名されたコンテンツは変更されていません。

DKIMの制限

DKIM署名はメッセージと一緒に移動するため、転送を生き残ります(SPFとは異なります)。ただし、サブジェクトまたはボディを変更するメーリングリストは署名を破壊します。DKIMも、失敗した署名をレシーバーが何をするかを示しません— これはDMARCの仕事です。

DMARC: ポリシーレイヤー

DMARC(ドメインベースのメッセージ認証、レポート、および適合性、RFC 7489)はSPFとDKIMを結び付け、ポリシーを追加します。_dmarc.example.com上のDNS TXTレコードとして公開されます。

DMARCはアライメントの重要な概念を導入します — 認証結果のドメインはユーザーが見るFrom:ヘッダーのドメインと一致する必要があります。

• SPFアライメント: MAIL FROMのドメインは(またはサブドメイン)From:ヘッダードメインと一致する必要があり、SPFはパスする必要があります。
• DKIMアライメント: 有効なDKIM署名のd=ドメインは(またはサブドメイン)From:ヘッダードメインと一致する必要があります。

メッセージは、SPFまたはDKIMのいずれかがアライメントでパスする場合、DMARCをパスします。両方を個別に失敗することができます。

DMARCポリシー

• p=none — 監視のみ。失敗に対してアクションを取らないでください。ロールアウト中に使用してください。
• p=quarantine — 失敗を疑わしいものとして扱う(通常はスパムフォルダーにルーティング)。
• p=reject — DMARCに失敗したメッセージを拒否します。これが目標です。

rua=タグは集約レポートの送信先を指定します — あなたのドメインを主張するすべてのメッセージの認証結果を示すXMLレポート。これらのレポートは、ポリシーを厳しくする前にメール環境を理解するために重要です。

メッセージが到着したときに何が起こるか

mx.receiver.comがalice@example.comからのメッセージを受け取ると、完全な認証シーケンス、ステップバイステップは以下の通りです。

1. 接続: 送信サーバーはIP198.51.100.42から接続し、MAIL FROM:<bounce-123@sender.example.com>を送信します。
2. SPFチェック: レシーバーはsender.example.comのSPFレコードをクエリします。IP 198.51.100.42がリストされています — SPFパス。しかし、エンベロープドメインはsender.example.comであり、From:ヘッダーはexample.comと言っています — これらは一致しないため、SPFアライメントがありません。
3. メッセージ受信: DATAフェーズがヘッダーとボディを配信します。
4. DKIMチェック: レシーバーはd=example.com; s=mtgのDKIM-Signatureヘッダーを見つけます。それはmtg._domainkey.example.comから公開鍵を取得し、署名を検証します — DKIMパス。d=ドメインはFrom:ヘッダーと一致します — DKIMアライメント。
5. DMARCチェック: レシーバーは_dmarc.example.comを取得します。ポリシーはp=rejectです。SPFはパスしましたが、アライメントされていません。DKIMはパスし、アライメントされています。少なくとも1つのメカニズムがアライメントでパスします — DMARCパス。
6. Authentication-Results: レシーバーはヘッダーに結果を記録します。

このヘッダー(RFC 8601)は受信サーバーによって追加され、そのホップの認証結果の権限のある記録です。

ARC: 転送を通じた認証の保持

ARC(認証済み受信チェーン、RFC 8617)は転送の問題を解決します。メッセージが中間者(メーリングリストまたは転送サービスなど)を通過する場合、SPFが破損し(フォワーダーのIPが元のSPFレコードにない)、DKIMが破損する可能性があります(リストがメッセージを変更した場合)。

ARCは、各中間者がメッセージを変更する前に観察した認証結果を記録し、それらの結果に署名することで機能します。ホップごとに3つのヘッダーを追加します。

• ARC-Authentication-Results (AAR): このホップの認証結果
• ARC-Message-Signature (AMS): このホップでのメッセージのDKIMのような署名
• ARC-Seal (AS): すべての前のARCヘッダーをチェーンでリンクするシグネチャ

各ヘッダーセットには番号が付けられています(i=1、i=2など)。チェーンを形成します。最終受信者はチェーンを検査して、ホップ2でフォワーダーが変更してから失敗するようになったことでメッセージが元々ホップ1でDMARCをパスしたことを確認できます。

ARCはDMARCをオーバーライドしません。最終受信者が信頼することを選択できる証拠を提供します。ARC結果を受け入れるかどうかは、レシーバーの裁量に委ねられます。

一般的な設定: サードパーティを通じた送信

MailerToGoなどのトランザクショナルメールサービスを使用してyour-domain.comとしてメールを送信する場合、3つのレイヤーすべてを構成する必要があります。

メールサービスはDKIMd=フィールドであなたのドメインで送信し、DKIMアライメントを確保します。SPFinclude:ディレクティブはサーバーを許可します。DMARCはそれを結び付けます。

何が問題になる可能性があるか

SPFが多くのDNSルックアップをしている

SPFにはDNSルックアップの上限が10個あります。各include:、a:、mx:、およびredirect=メカニズムは1つのルックアップとしてカウントされます。ネストされたインクルードは合計に数えられます。10を超える場合、SPF評価はpermerrorを返し、DMARCはそれを失敗として扱います。SPFレコードを検証ツールで監査してください。

DKIMキーローテーションの失敗

DKIMキーをローテーションする(新しい公開鍵を公開する)前に、送信インフラストラクチャが新しい秘密鍵を使い始める場合、飛行中のすべてのメッセージはDKIM検証に失敗します。常に新しいキーを最初に公開し、DNS伝播を待ってから、新しい秘密鍵に切り替え、猶予期間の後に古い公開鍵を削除します。

DMARCアライメント不一致

SPFはパス、DKIMはパス、しかしDMARCはまだ失敗。これは、どの結果もFrom:ヘッダーと一致しない場合に発生します。たとえば、SPFはbounces.esp.com(エンベロープ送信者)を検証していますが、From:ヘッダーはyour-domain.comと言っています。修正: DKIMがd=your-domain.comで署名することを確認してください。

転送されたメールが拒否されました

ユーザーがold@example.comメールをnew@gmail.comに転送します。メッセージは元のサーバーでDMARCをパスしますが、Gmailはフォワーディングサーバーのip(SPF失敗)と変更されたメッセージ(DKIM失敗)を見ます。p=rejectでは、転送されたコピーは拒否されます。ARCは役立つことができますが、採用は異なります。

サブドメインポリシーギャップ

_dmarc.example.comでp=rejectを公開していますが、フィッシャーはbilling.example.comから送信しており、DMARCレコードがありません。DMARCレコードにsp=reject(サブドメインポリシー)がない場合、サブドメインは組織的ポリシーを継承します — 但し別個のレコードがない場合に限ります。sp=rejectを明示的に設定するか、すべてのサブドメインのDMARCレコードを公開してください。

重要なポイント

• SPFは送信サーバーのIPをDNSに対してチェックします。エンベロープ送信者を検証し、From:ヘッダーは検証しません。
• DKIMメッセージに暗号署名します。転送を生き残ります(メッセージが変更されない限り)、署名ドメインを検証します。
• DMARCはSPFまたはDKIMがFrom:ヘッダーへのアライメントでパスすることを要求します。失敗時にすべきことのためにポリシーを公開します。
• ARCは転送ホップ全体で認証証拠を保持します。
• 3つ(SPF、DKIM、DMARC)すべてを正しく構成する必要があります。たった1つでは悪用可能なギャップがあります。
• p=noneで始め、DMARCの集計レポートを読み、p=rejectに進みます。

さらに読む

Related RFCs