要約

  • DMARC pass が示すのは Author Domain の利用が認められたことだけで、本文の真偽、安全性、意図、価値ではない。
  • p=reject は Domain Owner の処理希望であり、RFC 9989 は最終処理と例外理由を Mail Receiver の責任に置く。

正規の送信基盤から届いた危険なメールは DMARC を通過し得る。一方、転送やメーリングリストを経た正規メールは失敗し得る。pass を「安全」、fail を「詐欺」と読む装置は、両方を取り違える。

2026 年 5 月に IETF Standards Track として公開された RFC 9989 は RFC 7489 と 9091 を置き換えた。公開情報、Datatracker、正誤情報は規格の来歴を示すが、実装結果までは証明しない。

SPF は SMTP 送信元と認証対象の識別子を結び、DKIM はドメイン署名を検証する。DMARC は、そこで得た Authenticated Identifier と RFC5322.From の Author Domain が整合するかを調べる。一つでも整合した pass があれば DMARC pass、なければ fail となる。

RFC 9989 は、その意味を Author Domain の利用許可に限定する。メールや所有者への価値判断は含まれず、受信側は pass でも拒否できる。fail も不正の証明ではない。RFC 7960が扱う転送、別名、メーリングリストは、正規メールの認証や整合を壊す場合がある。

IANA の DMARC 登録簿にある none、quarantine、reject は Domain Owner の評価である。それは重要な外部情報だが、受信側の評判履歴、利用者事情、濫用観測を持ってはいない。

そのため 5.3.6 節と 5.4 節は処理をローカルポリシーに委ねる。受信側は p=reject でも fail を受け入れ、別の根拠で pass を止められる。RFC 9989 は、公開値だけを理由に拒否しないよう勧告する。正規の間接配送を壊すからだ。ただし例外は濫用を通す危険も生む。必要なのは無条件服従ではなく、帰属可能な理由である。

DNS エラーは fail ではない。必要な問い合わせが完了しなければ pass/fail を決められず、ドメインのポリシーも適用できない。延期などの処置は、未知状態を踏まえた別の受信判断になる。

RFC 9990 の PolicyOverride は逸脱と理由を伝え、RFC 8601 の Authentication-Results は認証記録を残す。RFC 9991 の詳細報告は任意の開示であり、処理権限ではない。

Heng Lu の最小初期仕様は共有信号と地域判断を両立させる。現実の層は記号を実行権へ膨張させず、動くコードの優先は受信側が実際に何を適用したかを問う。

正確な記録はこうなる。これらの証拠がこの整合結果を生み、ドメインがこの希望を示し、受信側がこの理由でこの処理を選んだ。