IETFは2026年5月、DMARCの新仕様となる「RFC 9989」を公開した。RFC 9989はStandards TrackのProposed Standardとして位置付けられ、従来のRFC 7489およびRFC 9091を置き換える仕様となる。

DMARCは、SPFやDKIMによる認証結果と、メールのFromヘッダーに表示されるAuthor Domainとの整合性を確認し、認証に失敗したメールをどのように扱うべきかをドメイン所有者が受信側に伝える仕組みである。企業にとっては、なりすましメール対策の中核を担う技術だが、RFC 9989では単なる仕様追加にとどまらず、運用上の曖昧さを減らすための整理が進められている。

本稿では、RFC 9989で追加・削除されたDMARCタグ、ポリシー探索の考え方、送信側と受信側が注意すべき運用ポイントを整理する。

DMARCレコードで追加・削除されたタグ

RFC 9989では、DMARC Policy Recordに関するタグの扱いが見直された。追加された主なタグは「np」「psd」「t」の3つである。一方、従来仕様に含まれていた「pct」「ri」「rf」はhistoric扱いとなり、実質的に廃止された。

「np」は、存在しないサブドメインに対するポリシーを指定するためのタグだ。従来の「sp」は既存のサブドメインに対する方針を示すものだったが、RFC 9989では存在しないサブドメインを悪用したなりすましに対しても、明確にポリシーを指定できるようになった。たとえば親ドメインで「p=none」「sp=quarantine」「np=reject」と設定した場合、存在するサブドメインには「sp」、存在しないサブドメインには「np」の方針が適用される。

「psd」は、Public Suffix Domainを示すためのタグである。RFC 9989では、DMARCレコードの探索にDNS Tree Walkの考え方が取り入れられ、Author Domainに有効なDMARCレコードがない場合、中間ドメインを飛ばさずに一段階ずつ上位をたどる動作に変わる。そしてpsd=yまたはpsd=nが見つかった時点で探索を終了する。これにより、.bankのようなTLDレベルでの業界横断ポリシー設定が可能になる。これにより、従来あいまいだった「組織ドメインをどこまでと見るか」「中間ドメインを辿るのか」という問題が整理される。 「t」はテストモードを表すタグである。値に「y」を指定すると、DMARCポリシーをそのまま適用するのではなく、1段階緩い扱いを求める。たとえば「p=reject; t=y」の場合は「quarantine」相当、「p=quarantine; t=y」の場合は「none」相当として扱うことが期待される。これは、従来「pct=0」が担っていた一部の役割を、より明確な形で置き換えるものだ。

「pct」廃止が示す、段階的導入の難しさ

従来のDMARCには「pct」タグがあり、0から100までの値でポリシー適用率を指定できることになっていた。しかし実際の運用では、0と100以外の値が正確に扱われないケースが多く、実装間のばらつきもあった。このためRFC 9989では「pct」をhistoric扱いとし、テスト用途は「t」タグに整理された。

これは、DMARCの厳格化を「少しずつ適用率を上げる」だけで進めるのが難しいことを示している。企業がDMARCを強化する際には、単にDNSレコードの値を変更するのではなく、送信元システムの棚卸し、DKIM署名の整合性確認、集計レポートの分析を組み合わせて進める必要がある。

導入手順は「p=none」から始めるのが基本

RFC 9989では、ドメイン所有者がDMARCに参加するための手順も整理されている。送信側は、DMARC Policy Recordを公開し、Author Domainと整合するSPFまたはDKIMの認証識別子を生成し、集計レポートを受け取り、認証上の不備を修正することが求められる。

特に重要なのは、いきなり「p=reject」に進むべきではないという点だ。RFC 9989では、SPF、DKIM、集計レポート受信用メールボックスを準備した上で、まず「p=none」と「rua」を指定してMonitoring Modeに入ることが推奨されている。これは、社内外のメール送信経路を洗い出し、想定外の送信元や第三者サービスによる送信を確認するためである。

「p=none」は、受信側にメール処理の変更を求めるものではない。あくまでレポートを収集し、自社ドメインを使うメールの実態を把握するためのモードである。RFC 9989でも、「p=none」によって既存のメール処理を変更してはならないとされている。

「p=reject」は強力だが、すべての企業に適しているわけではない

DMARCの最終的な目標として「p=reject」を想定する企業は少なくない。しかしRFC 9989では、メーリングリスト、転送サービス、部署別エイリアスなどを利用する環境では、厳格なポリシーが正規メールの配送に影響を与える可能性があると指摘している。

特に、一般ユーザーが日常的にメールを送るドメインで、ユーザーがインターネット上のメーリングリストに投稿する可能性がある場合、「p=reject」を公開すべきではないとされている。公開する場合でも、少なくとも1カ月間「p=none」でレポートを確認し、その後同程度の期間「p=quarantine」で影響を比較することが求められる。

また、「p=reject」を採用するドメインでは、SPFだけに依存してDMARCを通過させてはならず、有効なDKIM署名を適用する必要がある。転送やメーリングリストを経由するとSPFが失敗しやすいため、DKIMの整合性がより重要になる。

受信側はDMARCを「唯一の判定基準」にしてはならない

RFC 9989では、受信側の判断についても慎重な姿勢が示されている。DMARCのpassは、Author Domainの利用がドメイン所有者によって認められていることを示すにすぎず、そのメール自体が安全であることや、受信箱に配送すべきであることを保証するものではない。

同様に、DMARCがfailし、送信ドメインのポリシーが「p=reject」であったとしても、それだけを理由に受信側がメールを拒否してはならない。受信側は、DMARCの結果を迷惑メール判定、送信パターン、コンテンツフィルタリングなど他の分析と組み合わせて扱う必要がある。

この点は、DMARCを「届く／届かない」を機械的に決める仕組みと誤解している運用担当者にとって重要だ。DMARCは、メールの送信元ドメインに関する信頼性を評価するための材料であり、最終的な配送判断そのものではない。

メーリングリストとARCの現実的な課題

DMARCの厳格化において、長年の課題となっているのがメーリングリストや転送メールである。RFC 9989では、メーリングリストソフトウェアの多くがFromヘッダーを書き換える回避策を採用してきたこと、こうした回避策は理想的ではないものの、実運用上は定着していることが説明されている。

一方、ARC（Authenticated Received Chain）は、転送経路上で認証結果を引き継ぐための技術として期待されてきた。しかしRFC 9989の公開時点では、ARCを含む技術的な解決策が広く普及したとは言い切れない状況とされている。

そのため当面は、送信側はDKIMを確実に整備し、受信側はDMARCの結果を他のシグナルと組み合わせ、メーリングリスト運用者はFromヘッダー書き換えなどの現実的な対応を継続するという、やや複雑な運用が続くことになる。

企業がまず確認すべきポイント

RFC 9989は、DMARCをまったく別の技術に置き換えるものではない。DMARCレコードのバージョン値も引き続き「DMARC1」であり、未知のタグは無視される設計になっている。

一方で、企業のメール運用には確実に見直しが求められる。確認すべきなのは、自社ドメインで送信されるメールの全経路、Author Domainと整合するDKIM署名、DMARC集計レポートの受信・解析体制、既存サブドメインと存在しないサブドメインに対するポリシー、そして「p=reject」を採用した場合のメーリングリストや転送サービスへの影響である。

RFC 9989のポイントは、新機能の追加よりも、DMARCを安全に運用するための判断材料がより明確になったことにある。メールなりすまし対策を強化する企業にとって、DMARCは「設定して終わり」のDNSレコードではなく、継続的に監視し、段階的に強化していくセキュリティ運用の一部になったといえる。

Hornetsecurity株式会社
Principal Messaging Engineer
平野 善隆