RFC 9989でDMARCはどう変わった？ — pct廃止・Tree Walkなど変更点と実務への影響

RFC 9989とは、2026年5月に公開されたDMARCの新しい標準仕様です。 2015年から使われてきた従来仕様（RFC 7489）と、PSD向け拡張（RFC 9091）を置き換えました。あわせて、集約レポートの仕様はRFC 9990、失敗レポートの仕様はRFC 9991として別文書に分離されています。

先に結論です。ほとんどの企業は、既存のDMARCレコードを変更する必要はありません。 ただしpct=タグを使っている場合と、古い解説記事を参考にする場合には注意が必要です。

変更点の一覧

重要な変更を3つだけ深掘り

1. pct=の廃止 — 「10%だけ適用」はできなくなる

従来はpct=25のように、ポリシーを一部のメールにだけ適用しながら段階移行する方法がありました。新仕様ではこの割合指定が廃止され、試験的な扱いを示す用途はt=yに整理されました。

実務への影響：pct=が書かれた既存レコードが即座に壊れるわけではありませんが、新仕様に対応した受信側では無視されていきます。「pct=10のつもりが全量に適用されていた」という事故を避けるため、pct=を使っている場合はレコードを見直してください。段階移行はこれからは「none → quarantine → reject をレポードで確認しながら進める」が唯一の王道になります（→安全な引き上げ手順）。

2. DNS Tree Walk — 組織ドメインの決め方が変わった

DMARCでは「mail.example.co.jpの組織ドメインはexample.co.jp」のような判定が随所で使われます（アライメントのrelaxed判定、サブドメインへのポリシー継承など）。従来この判定は外部の一覧表（Public Suffix List）頼みでしたが、新仕様ではDNSを上位へたどって探索するDNS Tree Walkに変わりました。

実務への影響：一般的なドメイン構成なら結果は変わりません。深い階層のサブドメインを多用している組織では、新旧の受信側で判定が異なるケースがあり得るため、主要サブドメインに明示的にDMARCレコードを置くとより確実です。

3. レポート仕様の分離

集約レポート（rua）はRFC 9990、失敗レポート（ruf）はRFC 9991に分かれました。日々の運用は変わりませんが、DMARC解析サービスを選ぶ際は新RFCへの対応を確認しておくと安心です（→レポートの読み方と解析サービスの選び方）。

自社は何をすべきか — 3分チェック

1. 自社のDMARCレコードにpct=が含まれていない → 何もしなくてOK
2. pct=100が含まれている → 実質的な意味は同じですが、この機会に削除を推奨
3. pct=100未満が含まれている → 段階移行の設計を見直し、pct=を外した上でレポート確認による移行へ切り替える（→DMARC設定のやり方）

現在のレコードは無料診断で30秒で確認できます。

よくある質問

Q. 既存のv=DMARC1; p=none; rua=...というレコードは書き換えが必要ですか？

A. 不要です。一般的な構成のレコードは新仕様でもそのまま有効です。

Q. 古い解説記事（RFC 7489ベース）はもう参考にできませんか？

A. 大枠は今も有効ですが、pct=の使い方や組織ドメイン判定の説明は現行仕様と異なります。2025年以前の記事は、その2点を差し引いて読んでください。一次情報は公式ソース集から辿れます。

Q. t=yと旧pct=0は同じですか？

A. 「ポリシーを宣言しつつ、強制はしない試験状態」という狙いは近いものです。ただし新仕様における正式な表現はt=yであり、今後はこちらに統一されていきます。

Q. GmailやOutlookの送信者要件は変わりましたか？

A. RFCの改訂と各社の送信者要件は別物です。要件の最新状況は5社の送信者要件まとめで確認してください。

関連：DMARC設定のやり方｜DMARCレポートの読み方