DMARC

Identity

• IETFのRFC 9989（2026年5月発行のStandards Track文書）は、SPF（RFC 7208）とDKIM（RFC 6376）がドメインレベルの認証を提供する一方で、メールのRFC5322.From（作成者ドメイン）とは直接結びついていないと説明している。DMARCはこの2つのプロトコルを活用し、ドメイン所有者が作成者ドメインの認証ポリシーをDNSのTXTレコード（DMARC Policy Record）として公開し、検証に失敗したメールの扱いを要請できる仕組みとされる。検証待ち RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989は2026年5月に発行されたInternet Standards Track文書で、RFC 7489と RFC 9091を置き換える（obsoletes）と明記されている。付録C.1は、RFC 7489がIETFの作業部会の成果物ではなくIndependent Submissions Editorを通じて発行されたInformational RFCだったのに対し、本文書はStandards Trackの文書であると説明している。また本文は、集約レポートをRFC 9990、失敗レポートをRFC 9991の関連文書で規定するとしている。検証待ち RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

Capability

• IETFのRFC 9989（2026年5月発行のStandards Track文書）は、SPF（RFC 7208）とDKIM（RFC 6376）がドメインレベルの認証を提供する一方で、メールのRFC5322.From（作成者ドメイン）とは直接結びついていないと説明している。DMARCはこの2つのプロトコルを活用し、ドメイン所有者が作成者ドメインの認証ポリシーをDNSのTXTレコード（DMARC Policy Record）として公開し、検証に失敗したメールの扱いを要請できる仕組みとされる。検証待ち RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989のDMARC Policy Recordでは、ポリシー（pタグ）に3つの値がある。「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす（正当な可能性は残るが重大な懸念がある）、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされる。あわせて、集約レポートの宛先を指定するruaタグと、メッセージ単位の失敗情報の宛先を指定するrufタグ（いずれも任意）が定義されている。検証待ち Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989, plain text)
• IETF DatatrackerのRFC 9989ページによれば、同RFCはStandards TrackのProposed Standard（IETFストリーム）で、ページの最終更新日は2026年5月20日、RFC 7489とRFC 9091を廃止する。編集者はT. Herr（Valimail）とJ. Levine（Standcore LLC）で、要旨はドメイン所有者が自ドメインの利用検証・検証失敗時の取り扱い方針の表明・レポート要請を行えるプロトコルとしてDMARCを説明している。検証待ち RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

Credibility

• IETF DatatrackerのRFC 9989ページによれば、同RFCはStandards TrackのProposed Standard（IETFストリーム）で、ページの最終更新日は2026年5月20日、RFC 7489とRFC 9091を廃止する。編集者はT. Herr（Valimail）とJ. Levine（Standcore LLC）で、要旨はドメイン所有者が自ドメインの利用検証・検証失敗時の取り扱い方針の表明・レポート要請を行えるプロトコルとしてDMARCを説明している。検証待ち RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC EditorのRFC 7489ページによれば、RFC 7489は2015年3月公開のInformational（Independent Submission）で、編集者はM. KucherawyとE. Zwicky（Yahoo!）。同ページは現在「このRFCは廃止（obsolete）、RFC 9989・RFC 9990・RFC 9991を参照」と表示している。検証待ち RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) | RFC Editor
• Gmailヘルプの「Email sender guidelines」は、2024年2月1日以降にGmailアカウントへ1日5,000通を超えて送る送信者がセクション内の要件を満たす必要があるとしている。バルク送信者にはSPF・DKIM・DMARCが求められ、DMARCの強制ポリシーは「none」でもよいと記されている。検証待ち Email sender guidelines - Gmail Help

Use Case

• RFC 9989のDMARC Policy Recordでは、ポリシー（pタグ）に3つの値がある。「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす（正当な可能性は残るが重大な懸念がある）、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされる。あわせて、集約レポートの宛先を指定するruaタグと、メッセージ単位の失敗情報の宛先を指定するrufタグ（いずれも任意）が定義されている。検証待ち Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989, plain text)
• Gmailヘルプの「Email sender guidelines」は、2024年2月1日以降にGmailアカウントへ1日5,000通を超えて送る送信者がセクション内の要件を満たす必要があるとしている。バルク送信者にはSPF・DKIM・DMARCが求められ、DMARCの強制ポリシーは「none」でもよいと記されている。検証待ち Email sender guidelines - Gmail Help

Constraints / Current Status

• RFC 9989は2026年5月に発行されたInternet Standards Track文書で、RFC 7489と RFC 9091を置き換える（obsoletes）と明記されている。付録C.1は、RFC 7489がIETFの作業部会の成果物ではなくIndependent Submissions Editorを通じて発行されたInformational RFCだったのに対し、本文書はStandards Trackの文書であると説明している。また本文は、集約レポートをRFC 9990、失敗レポートをRFC 9991の関連文書で規定するとしている。検証待ち RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC EditorのRFC 7489ページによれば、RFC 7489は2015年3月公開のInformational（Independent Submission）で、編集者はM. KucherawyとE. Zwicky（Yahoo!）。同ページは現在「このRFCは廃止（obsolete）、RFC 9989・RFC 9990・RFC 9991を参照」と表示している。検証待ち RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) | RFC Editor

Key References

• DMARCが送信ドメインのメール管理で重視されるのはなぜですか？
• DMARCの仕様や現在のステータスは、どの一次資料で確認できますか？
• DMARCとは何で、メール認証のどの部分を担う仕様ですか？

Related

• IETF— DMARCの現行仕様RFC 9989はIETFストリームのStandards Track文書として、2026年5月にIETFのRFC Editorから公開された（IETF Datatracker）。