DMARCに関するRFC 9989、9990、および9991は、RFC 7489に取って代わる

IETFのDMARCワーキンググループにおける長年の取り組みを経て、待望のDMARC規格の更新版が公開されました。RFC 9989、RFC 9990、RFC 9991の3つの新しい文書が、2015年に策定された元のRFC 7489に正式に取って代わりました。公式な用語ではありませんが、これらのRFCはコミュニティ内で総称して「DMARCbis」として知られており、現在は同じバージョン番号を持つ更新されたDMARC仕様として公開されています。

新しい仕様は2026年5月に公開され、DMARCはIETFの標準化プロセスにおいて、従来の「Informational」ステータスから「Proposed Standard」へと移行しました。これは、DMARCがインターネット標準の体系において、より強固かつ正式な位置づけを得ることを意味するため、大きな前進と言えます。

各RFCの内容

DMARC仕様は、1つの巨大なファイルではなく、3つの専門的な文書に分割されました。RFC 9989には、ポリシー評価、整合性ルール、レコード処理を含むコアプロトコルが記載されています。RFC 9990では、集計（RUA）レポートのフォーマットが定義されています。RFC 9991では、しばしばフォレンジックレポートと呼ばれる失敗レポートについて扱っています。

既存のDMARCレコードは引き続き機能します

ドメイン所有者にとって最も重要な点の一つは、これが互換性を損なう変更ではないということです。プロトコル識別子は変更されないため、レコードは引き続き「v=DMARC1」で始まります。設定を一から作り直したり、すべてのレコードを一夜にして再公開したりする必要はありません。

レコードの構成について復習したい場合は、DMARCタグに関するガイドで各フィールドについて詳しく解説しています。

主な技術的な変更点

いくつかの更新点が特に目立ちますが、そのうちのいくつかは、レコードを編集する前に詳しく理解しておく価値があります。

「パブリックサフィックスリスト」が「DNSツリーウォーク」に置き換えられました

受信側は、組織ドメインを特定するために、外部で管理されているパブリックサフィックスリストに依存しなくなりました。その代わりに、DNS階層を上って行き、各レベルで_dmarcレコードを検索します。実際には、受信側は対象のドメインから開始し、公開されているDMARCレコードが見つかるまで、最大8回のルックアップまで段階的に上位のラベルに対してクエリを実行します。これにより、サードパーティへの依存が解消され、複雑なドメイン構造における精度が向上します。

ここで注目すべき実用上の影響があります。ツリーウォークでは、従来のパブリックサフィックスリスト方式とは異なる方法で組織ドメインを解決するため、RFC 9989 を実装している受信側は、RFC 7489 を依然として使用している受信側とは、場合によっては異なる組織ドメインを特定してしまう可能性があります。複雑なサブドメイン階層を運用している場合や、委任ドメインを使用している場合は、実際にメールを送信するすべてのドメインおよびサブドメインに対して、明示的なDMARCレコードを公開することが最も安全なアプローチです。そうすることで、特定の受信者がどのバージョンを使用しているかに関係なく、どのポリシーが適用されるかについての曖昧さを排除できます。

新しいタグ：np、psd、t

RFC 9989 では、3つの新しいタグが導入されています。以下に、それぞれの機能と、実際にどのような場面で使用するかを説明します。

np（存在しないサブドメインポリシー）

spタグではすでにサブドメインに対するポリシーを設定できますが、npはさらに一歩進んで、DNSがNXDOMAINを返すような、そもそも存在しないサブドメインに対するポリシーを区別します。攻撃者は登録されたことのないサブドメインを装ってメールを送信することが多いため、これによりサブドメインのなりすましという重大な脆弱性が解消されます。例えば、v=DMARC1; p=none; np=reject; というレコードを設定すると、ルートドメインおよびその正規のサブドメインにはポリシーが適用されませんが、存在しないサブドメインからのメールは依然として拒否されます。ドメインがすでにp=rejectまたは sp=reject に設定されている場合、厳格なポリシーは自動的に継承されるため、np=reject を追加しても新たな効果は得られず、変更も必要ありません。より緩やかなポリシーを採用しているものの、この特定の攻撃に対して的を絞った保護を望む場合は、np=reject を追加する価値は十分にあります。

t（テストモード）

これは、誤解されやすいタグです。t=y に設定しても、ポリシーが無効になるわけではありません。その代わりに、受信側に対して、公開したポリシーよりも1段階緩いポリシーを適用するよう要求します。つまり、「reject」ポリシーは「quarantine」として扱われ、「quarantine」ポリシーは「none」として扱われ、「none」の場合は影響を受けません。これは、実質的に置き換えられる旧来の pct の動作よりもはるかに正確です。重要な注意点として、まだすべての受信者が RFC 9989 をサポートしているわけではないため、t=y を単に無視してしまう受信者もいます。移行期間中は、pct と t を併用して、古い受信者と新しい受信者の両方があなたの意図を理解できるようにするのが、より安全なアプローチです。段階的なレコードの例としては、v=DMARC1; p=reject; pct=50; t=y; といった形になります。この変更に関する詳細は、tがpctに取って代わる理由について述べた以前のノートをご覧ください。

psd（パブリックサフィックスドメイン）

このタグは、受信側がDNSツリー探索中に組織ドメインを特定するのに役立ちます。一般的なドメイン所有者のほとんどは、単にこのタグを省略すれば問題ありません。このタグが関連するのは、サブドメインで意図的に組織ドメインの境界を宣言したい組織（その場合はpsd=nを設定）と、.bankや.govなどのパブリックサフィックスドメインの運営者（psd=yを設定）という2つの状況に限られます。なお、RFC 7489を依然として実行している受信側は、このタグを完全に無視するため、適切なレコード設計の代わりにはならないことに留意してください。

3つのタグを削除しました：pct、rf、ri

RFC 9989 では、3 つのタグが廃止されます。これらの廃止によって既存のレコードに不具合が生じることはありませんが、各タグの機能や対応策について理解しておく価値はあります。詳細は以下の専用セクションをご覧ください。

メーリングリストおよび転送に関するより明確な指針

間接的なメールの送信経路では、依然としてSPFとDKIMの整合性が損なわれており、新しい仕様ではこの点が率直に認められています。また、メーリングリストのトラフィックが頻繁に発生する環境では、過度に厳格な「p=reject」ポリシーを避けるよう推奨しており、これは現実の世界における電子メールの実際の挙動を反映したものです。

より明確に定義された適合性

新しい文書では、送信者と受信者の双方にとって「DMARCへの完全な参加」が何を意味するかが明確に規定されており、これにより、長年にわたり問題となってきた実装のばらつきが軽減される見込みです。

URIのサイズ制限に関する報告が削除されました

見落としがちな小さな変更点として、RFC 9989 により、レポート URI でレポートの最大サイズを指定する機能が削除されました。rua=mailto:[email protected]!10m のようなサイズ指定のサフィックスを使用していたレコードは、もはや意味をなさなくなり、受信者は RUA または RUF アドレスに付随するサイズ制限をすべて無視する必要があります。レポート URI にこの構文が含まれている場合は、サイズ制限の部分を削除しても問題ありません。

削除されたタグについて

現在使用しているレコードで「pct」、「rf」、または「ri」が使用されている場合、それぞれの機能の詳細と、今後どのように対応すべきかを以下に説明します。

pct

このタグは、ポリシーを段階的に展開し、選択した割合のメールに適用できるように設計されました。実際には、受信者間で実装に一貫性がなく、予期せぬ結果が生じていたため、より明確な「t」タグに置き換えられました。もしまだ「pct」に依存している場合は、今後はこれだけに頼らないようにしてください。移行期間中は、pctとt=yを併用するのが賢明です。そうすることで、旧式の受信機とRFC 9989準拠の受信機の双方が、ポリシー適用に向けて段階的に移行していることを理解できるようになります。

rf（報告書形式）

このタグは障害報告の形式を指定するものでしたが、有効な値は「afrf」のみであったため、実際にはこのタグは不要でした。このタグが含まれているレコードからは、安心して削除しても問題ありません。

ri（報告間隔）

このタグは、集計レポートの送信間隔（秒単位）を定義するものでした。ほとんどの受信側はこれを無視し、単にデフォルトで毎日レポートを送信していましたが、RFC 9989 では、受信側に少なくとも 1 日 1 回は集計レポートを送信することを義務付けることで、この点を正式に規定しました。このタグを残しておいても問題はありませんが、その重要性はますます薄れており、これに依存すべきではありません。

DMARCレコード（RFC 9989）を更新するには？

RFC 9989 の公開によって、既存の環境に支障が生じることはありません。レコードは引き続き同じ場所（_dmarc.yourdomain.com のDNS TXT レコード）に存在し、バージョンタグも v=DMARC1 のままです。

では、なぜ更新する必要があるのでしょうか？それは、RFC 9989 が、10年にわたる実運用を経て、電子メールが実際にどのように機能するかを反映しているからです。また、その変更点の中には、後で気づくよりも、今すぐ記録に盛り込んでおく価値のあるものがいくつかあるからです。

ドメイン所有者がすべきことは次のとおりです

ドメイン所有者は、以下のチェックリストに従って、レコードを動的に更新することができます：

rf および ri タグを削除してください。どちらも非推奨となっており、削除しても問題ありません。
Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
メインのポリシーを変更せずに、存在しないサブドメインからのなりすましをブロックしたい場合は、np=reject を追加することを検討してください。
rua または ruf レコードにレポート URI のサイズ制限を示す接尾辞が含まれている場合は、それを削除してください。
組織ドメインの境界を意図的に宣言する必要がある場合や、パブリックサフィックスドメインを運用している場合を除き、psd は除外してください。
メールを送信するすべてのドメインおよびサブドメインについて、明示的なDMARCレコードを公開し、RFC 9989およびRFC 7489に準拠した受信者間でDNSツリーウォークに関する曖昧さが生じないようにしてください。

変更点の詳細や記録の準備方法については、DMARCbisの解説ガイドをご覧ください。

RFC 9989 に基づく最新形式のレコードは、次のようになります。

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

ここになにがないかに注目してください。pct がありません。安全に導入するには、t=y を追加し、集計レポートが蓄積されるのを待ってから、完全な適用を開始する準備が整った時点でこれを削除してください。

また、このレコードには、RFC 9989で規定されている有効なタグのうち、「t」と「psd」の2つが含まれていないことにお気づきになるでしょう。これは意図的なもので、どちらも標準的なものではなく、状況に応じて使用されるものだからです。

「t」タグは一時的なテストモードを表します。これは、公開したポリシーよりも1段階低いポリシーを適用するよう受信側に指示するものであるため、ポリシーの適用を段階的に進めていく期間にのみ追加します。一方、「psd」タグは、ドメインをパブリックサフィックスとして宣言するためのフラグです。パブリックサフィックスオペレーターは「psd=y」を設定する必要がありますが、通常のドメイン所有者にとってはデフォルトの「u」で十分ですので、このタグは単に省略すれば問題ありません。

DMARCプラットフォームの準備が整っているか確認してください

市場に出回っているすべてのツールが、まだ新しい標準規格に対応しているわけではありません。このギャップは重大な問題です。もしお使いのプラットフォームが新しいタグを読み取れなかったり、更新された形式のレポートを処理できなかったりすれば、プロトコルが進化しているまさにそのタイミングで、可視性を失うことになります。

PowerDMARCはすでに新しい仕様に準拠しており、以下の機能をサポートしています：

RFC 9989、9990、9991 準拠のレコード生成
新しい「np」、「psd」、「t」タグの解析
RFC 9990 に基づく集計レポートの取り込みと報告
DNSツリー探索に基づく組織ドメインの処理
新しい適合性規則を反映した処理動作の更新

現在の設定が新しい基準に適合しているかどうかを確認したい場合は、当社の無料DMARCチェッカーでチェックし、改善が必要な点を確認してください。

まとめ

更新されたRFCは、新しいプロトコルではありません。これは従来のDMARCそのものであり、より分かりやすく書き直され、標準化プロセスに移行したものです。10年以上にわたる実環境での運用を経て、この仕様は、転送やメーリングリストといった複雑な部分も含め、電子メールが実際にどのように機能するかを反映したものとなっています。

ドメインのセキュリティを担当するすべての方にとって、RFC 9989、9990、および9991の公開は、レコードの監査を行い、新しいタグやDNSツリーウォーク手法に対応できるようツールの準備を整える良いきっかけとなるでしょう。

について
最新記事

Ahona Rudra

ドメインとメールセキュリティのエキスパートPowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

人事部門のメールおよび給与計算のセキュリティ：グローバルチームのためのベストプラクティス - 2026年6月22日
Microsoft Entra でリスクの高い AI エージェントをブロックする方法 - 2026年6月15日
Office 365 フィッシング対策ポリシー：設定方法 - 2026年6月3日