メッセージには両方は必要ありません SPF そして DKIM メッセージレベルを生成する DMARC 合格。少なくとも 1 つの適格なパスが必要です。SPF SPF合格して調整されるか、少なくとも 1 つ必要です。 DKIM署名 通過して整列する必要があります。
このルールは簡単に単純化しすぎます。メッセージ レベルのパスは、完全なドメイン認証の展開と同じではありません。また、送信者がSPFとDKIM両方を構成することを期待する個別のメールボックス プロバイダーの要件をオーバーライドすることもありません。プロトコルの結果、送信プログラム、およびプロバイダーの要件を 3 つの個別の決定として保持します。
ブール ルールを正しく適用する
適用可能な有効なポリシーと完了したチェックを含む整形式のメッセージの場合、 RFC 9989 §5.3.5 メッセージレベルの検証ルールを示します。
DMARC pass = ( SPFが合格し、 SPF ID が整列する) OR ( DKIM署名が合格し、かつその d= ドメインが整列する)OR という言葉が重要です。どちらのブランチでもメッセージ レベルの条件を満たすことができます。単語 AND は各ブランチ内で重要です。何も含まれていない生の認証パス アライメント それを満たさない。
アラインメントでは、認証されたドメインと From の作成者ドメインが比較されます。厳密モードでは、以下の正確な等価性が必要です。 RFC 9989 §3.2.10.2。リラックス モードでは、検出関係が使用されます。 RFC 9989 §4.10.2.
3 つの重要なケースを比較する
次の架空の例では From を使用しています。 orders@example.com。これらは合成された教育ケースであり、顧客トラフィックを捉えたものではありません。
- ケース: A; SPF : example.comをパスし、整列させます。 DKIM : 失敗。 DMARC結果: 合格。理由: SPFブランチは適格です
- ケース: B; SPF : 失敗; DKIM : d=example.com,をアライメントして渡します。 DMARC結果: 合格。理由: DKIMブランチは適格です
- ケース: C; SPF : vendor.example.netのパス、アライメントなし。 DKIM : d=vendor.example.net,アライメントされていません。 DMARC結果: 失敗。理由: どちらのブランチも資格がありません
ケース A は、 DKIM障害が自動的にDMARC障害を意味しない理由を示しています。ケース B は、 SPFを中断する転送によっても、調整されたDKIMパスが残される理由を示しています。ケース C は、2 つの緑色の生の結果が依然としてDMARC障害を引き起こす可能性がある理由を示しています。
これらの例を設計目標として読まないでください。エンベロープ パスのみに依存すると、メッセージの転送時に脆弱になる可能性があります。 DKIMのみに依存すると、仲介者が署名されたコンテンツを変更する場合に脆弱になる可能性があります。復元力は通常、両方のメカニズムを正しく構成し、実際のメッセージがどのように動作するかを検証することで得られます。
検証と完全参加を区別する
メッセージ レベルの検証では、受信したメッセージに少なくとも 1 つのパス調整されたパスがあるかどうかがわかります。成熟したドメイン プログラムでは、正当なメッセージが一貫してカバーされているか、両方のメカニズムが必要に応じて展開されているか、ポリシーは適切か、レポートはレビューされているか、運用所有者は例外を修正しているかなど、より広範な質問が行われます。
RFC 9989 また、単一メッセージの検証結果よりも広範囲にドメインへの完全な参加を定義します。特に、ドメイン公開拒否はSPFのみに依存してはならず、有効なDKIM署名を適用しなければなりません。 RFC 9989 §7.4。完全参加は以下で指定されます RFC 9989 §8。メッセージレベルの OR ルールを、組織全体で 1 つのメカニズムを無視してもよいというアドバイスに変えないでください。
メールボックス プロバイダーが送信者の要件を公開する場合も、同じ区別が重要になります。例えば、 Google の送信者ガイドライン SPF 、 DKIM 、 DMARCセットアップが必要です 一括送信者 個人のGmailアカウントに送信します。プロバイダーは、特定のメッセージのDMARC検証で aligned-path ルールが引き続き使用されている場合でも、送信者カテゴリに対してSPFとDKIM両方を構成することを要求する場合があります。プロバイダーの個別の要件を満たしていないことは、 DMARCブール式を引用して反論することはできません。
ポリシーを変更する前に障害が発生したブランチを診断する
正当なメッセージがDMARC失敗した場合、以下をキャプチャします。
- 証拠: ドメインから。質問: どの作成者のドメインが保護されていますか?
- 証拠: SPF結果と評価されたドメイン。質問: 封筒のパスは通過しましたか?また、位置は揃っていましたか?
- 証拠: 各DKIM結果と d= ドメイン。質問: 合格して一致した署名はありますか?
- 証拠: アライメントモード。質問: 厳密な比較が適用されましたか?または緩和された比較が適用されましたか?
- 証拠: 信頼できる受信者の結果。質問: 結論はどこで出されましたか?
次に、送信者が使用する予定のブランチを修復します。 SPFの場合、カスタム エンベロープ ドメインと承認された送信パスが関係する場合があります。 DKIMの場合、組織のドメインでの署名を有効にし、代表者が受信したメッセージを検証することが必要になる場合があります。 ID テーブルがまだ組み立てられていないという理由だけでポリシーを弱めないでください。
間接メールを理解する
で説明されているように、 RFC 7208 §10.3、転送では接続元が変更されることが多いため、 SPF先に通過したとしても最後の受信側で失敗する可能性があります。残っている整列されたDKIM署名は依然として適格なパスを提供する可能性があります。署名付きコンテンツを変更すると、 DKIM無効になる可能性があります。 RFC 6376 §3.7一方、他の中間動作は両方のパスに影響を与える可能性があります。
DMARC 、すべての正当な間接フローが適格なパスを保持することを保証しません。実際のルート、受信者の証拠、ビジネス ニーズを評価します。受信者は、処分を決定する際にローカルポリシーやその他の証拠を適用することもできます。
4 つの一般的な結論を避ける
まず、すべてのメッセージがDMARCを通過するにはSPFとDKIM両方が通過する必要があるとは言わないでください。それはメッセージレベルのルールではありません。
第二に、送り出し機関全体にとって 1 つのメカニズムで十分だとは言わないでください。たった 1 つの合格例だけでは、適用範囲、回復力、または完全な参加を確立することはできません。
第三に、パスを受信トレイの配置と同一視しないでください。認証は、決定を受け取るための 1 つの入力です。
第四に、失敗を証明された不正行為と同一視しないでください。正規のサービスが誤って設定される可能性がある一方で、攻撃者が所有するドメインは独自のメールを認証する可能性があります。
を使用します。 電子メール ID チェーン ガイド 証拠を集めて、 SPF 、 DKIM 、 DMARCガイド 結果をより広範なプログラムに組み込むためです。
結論は証拠の範囲内に留めておく
ブール フィクスチャの場合、OR で結合する前に、各ブランチをパス AND として評価し、整列させます。失敗した署名は別の署名からアライメントを借用できず、 SPFパスは別のドメインのアライメントを借用できません。必要なDNSチェックが完了しない場合は、 RFC 9989 §5.3.6 そのエラーを通常の合否結果から区別します。実際のベリファイアは実行されませんでした。