第15回 DMARC RFC改版
～ DMARCポリシーの再確認を ～
JSSEC副会長・理事
KDDI株式会社 本間 輝彰
DMARC（Domain-Based Message Authentication, Reporting, and Conformance）のRFCがRFC 9989として2026年5月に改版されました。
本改版により、改版前のRFC 7489では、CategoryがInformationalであったものから、Standards Trackに変更されたことで、より強固かつ正式な位置づけを得ることを意味すると言えます。
また、RFC 9989では、Categoryが Experimentalで発行されていたRFC 9091も取り込んでいます。さらに、DMARCレポートとDMARCエラーレポートの仕様が、それぞれRFC 9990、9991として切り出されたのも大きな変化です。
さらに、RFC 9091を取り込んだことで追加されたタグ、仕様が変更されたタグ、廃止されたタグなどがあります。
これら背景を踏まえ、改版されたDMARCの仕様について解説するとともに、注意点や課題点をまとめている。DMARCを導入している企業も、改版されたRFC 9989の仕様を踏まえて、再度DMARC設定の確認をすることが推奨され、正しい設定での運用がなされることを期待される。
運用の明確化
DMARCは、送信側でドメイン詐称時のポリシーを宣言することが可能となっています。一方で、受信側では、送信側のポリシーに対するふるまいは明確には規定されていませんでした。しかし、RFC 9989では、送信側のポリシーは尊重するものの、必ずしも送信側のポリシーに従う必要はなく、受信側で総合的に判断して処理することとなっています。
実際のメールサービスでも、DMARCポリシーが“quarantine”であっても認証が失敗した際には受信拒否している事例もあり、より現実に沿った仕様の変更と考えます。
| 1. Introduction
― 抜粋 ― A DMARC pass for a message indicates only that the use of the Author Domain has been validated for that message as authorized by the Domain Owner. Such authorization does not carry an explicit or implicit value assertion about that message or about the Domain Owner, and so a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable. For a mail-receiving organization participating in DMARC, a message that passes DMARC validation is part of a message stream reliably associated with the Author Domain. Therefore, reputation assessment of that stream by the mail-receiving organization can assume the use of that Author Domain is authorized by the Domain Owner.
On the other hand, a message that fails this validation is not necessarily associated with the Author Domain and so should not affect the Author Domain's reputation. The phrase "not necessarily associated" was purposely chosen here, as it is important to understand that some messages making authorized use of the Author Domain can still fail DMARC validation checks. [RFC7960] and Section 7 of this document both discuss reasons why such failures may happen. Because of this, a mail-receiving organization that performs DMARC validation can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so. DMARC is commonly used as one input to more complex filtering decisions, and so the mail-receiving organization might choose different actions entirely. |
また、複数のヘッダFromドメインの扱いについても、明確になっている。メールフォーマットの仕様を規定しているRFC 5322（Internet Message Format）では、ヘッダFromの数は最小で1、最大で1と定義されており、複数のヘッダFromは違反となっている。一方、1つのヘッダFromに対して、複数のFromアドレスをカンマ区切りで複数記載することは可能となっている。
RFC 7489では、Extract Author Domainの中で、どちらのケースの“typically rejected”と通常は拒否すると言う記述にとどまっていた。複数のFromヘッダはRFC 5322違反としてエラーとして拒否することは当然の動作と考えられるが、1つのヘッダFromに対して複数のFromアドレスがある場合、RFC 5322とRFC 7489の間で矛盾があるのは事実である。RFC 9989ではこの点についても整理されており、基本的にはRFC 7489の考えを踏襲しつつ、より丁寧な説明をされている。
| 5.3.1. Extract Author Domain ― 抜粋 ―If zero or more than one domain is extracted from the RFC5322.From header field, then DMARC validation is not possible and the process terminates. In the case where more than one domain is retrieved, the Mail Receiver MAY choose to go forward with DMARC validation anyway. See Section 11.5 for further discussion.11.5. Denial of DMARC Processing AttacksThe declaration in Section 5.3.1 and elsewhere in this document that messages that do not contain precisely one RFC5322.From domain are outside the scope of this document exposes an attack vector that must be taken into consideration.Because such messages are outside the scope of this document, an attacker can craft messages with multiple RFC5322.From domains, including the spoofed domain, in an effort to bypass DMARC validation and get the fraudulent message to be displayed by the victim's Mail User Agent (MUA) with the spoofed domain successfully shown to the victim. In those cases where such messages are not rejected due to other reasons (for example, many such messages would violate the requirement described in [RFC5322] that there be precisely one From: header field), care must be taken by the Mail Receiver to recognize such messages as the threats they might be and handle them appropriately.The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. Experience has shown that most such messages are abusive and/or unwanted by their recipients, and given this fact, a Mail Receiver may make a negative disposition decision for the message prior to and instead of its being subjected to DMARC processing. However, in a case where a Mail Receiver requires that the message be subject to DMARC validation, a recommended approach as per [RFC7489] is to apply the DMARC mechanism to each domain found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. Such an approach might prove useful for a small number of Author Domains, but it is possible that applying such logic to messages with a large number of domains (where "large" is defined by each Mail Receiver) will expose the Mail Receiver to a form of denial-of-service attack. Limiting the number of Author Domains processed will avoid this risk. If not all Author Domains are processed, then the DMARC evaluation is incomplete. |
DNS Tree Walk とPublic Suffix Domain(PSD)
RFC 7489では、送信元ドメイン（ヘッダFromドメイン）に対して適用すべきDMARCポリシーを発見し、また組織ドメインを判定するために、Public Suffix List（PSL）が利用されていた。PSLは、“.com”、“.jp”、“.co.jp”、あるいは一部の共有ホスティングドメインのように、その配下に第三者がドメインを登録・利用できる境界を示すリストである。これにより、たとえば“example.co.jp” に対して、単純に末尾2ラベルを組織ドメインとみなすのではなく、“co.jp” がPublic Suffixであり、その一つ下の“example.co.jp” が組織ドメインである、という判断が可能になっていた。
しかし、PSLはDNSそのものではなく、DMARC仕様の外部で管理されるリストである。そのため、DMARCというDNSベースの認証ポリシー発見機構が、外部のリストに依存する課題があった。また、受信側実装が参照するPSLの更新頻度や内容によって、同じドメインに対する組織ドメイン判定が異なる可能性があった。さらには、インターネット上の名前空間はTLD、ccTLD、属性型ドメイン、共有ホスティング、クラウドサービスなど多様であり、静的なリストで常に正確かつ即時に境界を表現し続けることには限界があったと推測される。
こうした背景を踏まえ、RFC 9989では、PSLへの依存が廃止され、DNS Tree Walkが導入された。DNS Tree Walkでは、対象となるFromドメインからDNS階層を上位方向にたどりながら、各階層のDMARCレコードを探索する。たとえば “user@sub.a.example.com” であれば、概念的には”_dmarc.sub.a.example.com”、“_dmarc.a.example.com”、“_dmarc.example.com”のように順に確認し、発見されたDMARCレコードに基づいて適用すべきポリシーを判断する。この方式により、DMARCは外部リストではなく、DNS上に公開された情報を用いてポリシーを発見できるようになった。またDNSクエリの発行回数を8回と制限することで、過度に深いサブドメインによって多数のDNSクエリを発行させられることを防ぐ対策も入っている。
一方で、PSLへの依存をなくしても、Public Suffixに相当する境界の概念そのものが不要になったわけではない。たとえば “.com”、“.co.jp”、あるいは新しいTLDやレジストリ管理下のドメインのように、その配下に多数の独立した登録者が存在する名前空間では、通常の登録者ドメインと、レジストリやPublic Suffix Operatorが管理する上位ドメインを区別する必要がある。そこでRFC 9989では、Public Suffix Domain(PSD)という概念が明示的に定義された。なお、“psdタグ”はOPTIONALのパラメータであり、必須のパラメータではない。
PSDは、DMARCにおいてPublic Suffixに相当するドメインを扱うための概念であり、その運用主体はPublic Suffix Operator（PSO）として整理される。さらにRFC 9989では、DMARCレコードに “psd”タグが追加され、そのレコードがPublic Suffix Domain側のポリシーであるかどうかを示せるようになった。たとえば、“_dmarc.example.com”に“v=DMARC1; p=reject; psd=y” のようなレコードが存在する場合、それは通常の登録者ドメインのポリシーではなく、PSD側が示すポリシーとして扱われる。
したがって、RFC 9989におけるPSL廃止、DNS Tree Walkの導入、PSDの定義は、DMARCのポリシー発見を外部リスト依存からDNSベースの仕組みに移行し、Public Suffixに相当するものをPSDで表現するように変更したと推測される。
DNS Tree Walk
DNS Tree Walkでは、DMARCレコードの検索時の動作がより細かく定められています。
- 応答したTXTレコードの先頭が“v=（vタグ）”で始まらない場合は破棄される。
- 同一のDMARCレコード検索対象名に対して、複数のDMARCレコードが返された場合は、すべて破棄される。
特に重要なのは、複数のDMARCレコードが返る場合、すべて破棄されるという点である。JSSECが約9万のDMARCレコードを調査した結果、0.3%のDMARCレコードに複数のDMARCレコードが返るという結果になっている。もし、受信側がRFC 9989に準拠した場合、そのドメインのDMARCレコードは破棄され、DMARC非対応という扱いになることになる。したがって、もし複数のDMARCレコードが記述している場合は、早急の修正が必要となる。
psdタグ
また、psd パラメータでは、対象ドメインがPSDであるかどうかを示す。値には、当該ドメインがPSDであることを示す“ y”、PSDではないものの、自身のドメインおよびそのサブドメインに対するOrganizational Domainとして扱うことを示す “n”、PSDではないことを示す“ u” がある。なお、“u” はデフォルト値である。
この psd パラメータが規定されたことにより、以下に示すような利用が可能となっている。
example.com ドメインを所有する企業が多数のグループ企業を抱えており、各グループ企業のドメインとして example.com のサブドメインを利用しているとする。現在、DMARCは導入段階にあり、グループ企業ごとに異なるDMARCポリシーを適用したい状況である。
例えば、以下のようにDMARCレコードを設定することで、グループ全体としてはDMARCポリシーを none としつつ、各社ごとにより強いDMARCポリシーを個別に設定することが可能となる。
A社：_dmarc.a.example.com に v=DMARC1; p=reject; psd=n
B社：_dmarc.b.example.com に v=DMARC1; p=quarantine; psd=n
グループ全体：_dmarc.example.com に v=DMARC1; p=none; psd=y
pctタグの廃止とtタグの定義
RFC 9989における大きな変更点の一つに、pct タグの廃止がある。
従来は pct タグを使用することで、DMARC認証に失敗したメールのうち、指定した割合に対してのみDMARCポリシーを適用することができた。例えば、pct=10、pct=20、pct=50 のように段階的に適用率を引き上げることで、quarantine や reject への変更による影響を確認しながら、慎重にDMARCポリシーを強化する運用が可能であった。
しかし、RFC 9989では pct タグが廃止されたため、このようにポリシーの適用率を段階的に制御する方法は利用できなくなった。
JSSECが約9万ドメインのDMARCレコードを調査した結果、約25%のドメインで pct が設定されており、さらに約2%のドメインでは pct の値が100未満であった。受信側がRFC 9989に対応した場合、pct は考慮されなくなるため、これらのドメインでは、DMARCレコードに記述された p タグのポリシーがすべての対象メールに適用されることになる。
RFC 9989の大きな変更点としては、“pctタグ”の廃止もその1つである。pctタグを使うことで、DMARC認証に失敗したメッセージに対するポリシー適用率を制御可能となっており、pct=10,20,30,50,100などと変更していくことで、DMARCポリシーの変更の影響を確認しながら、導入することが可能であった。しかしながら、pctが廃止になったことで、これら手法が利用不可になっている。約9万ドメインのDMARCレコードを調査した結果では、約25%のドメインでpctを設定しており、さらに約２%のドメインがpctの値が100ではなく（※JSSEC調べ）、受信側がRFC 9989対応後にはこれらドメイン全てに記述されているDMARCポリシーが適用されることなる。
また、pctタグの廃止と併せて“tタグ”が新たに定義されている。“tタグ”は当該ドメインに対してテストモードの設定をするものとなっており、“t=y”と設定した場合、送信者は、指定した DMARC 評価ポリシーをテスト中であり、認証失敗時の適用されるポリシーが、DMARCレコードに記述されているポリシーより 1 段階下になることを期待しているものとなります。ただし、受信側のRFC 9989対応が進めば、本タグの有用性は高くなると考えられるが、どの受信サービスがRFC 9989対応か不明であり、且つ、OPTIONALであることを考えると、当面は本タグが機能しているかを確認しながら利用する方が賢明である。
その他変更点
“vタグ”はDMARCのバージョンを示し、“DMARC1”のみが許容されているが、RFC 9989では、さらに、大文字・小文字を区別し、“v”は小文字、“DMARC1” は大文字であることが必須になっている。
また、“pタグ”はDMARCポリシーを示しており、これまでは必須パラメータになっていたが、RFC 9989では“ruaタグ”が設定されている場合は、“pタグ”がない場合は、“none”と扱われるようになっている。
rua/rufについて
RFC 9989の大きな変更の1つとして、DMARC認証結果の集約レポート(ruaタグ)を送信する仕様と、DMARC認証失敗レポート（rufタグ）を送信する仕様が、それぞれRFC 9990、RFC 9991と切り出されたこともある。
これに伴い、DMARC認証結果の集約レポートの仕様も更新されている。ruaタグを設定し、受信した集約レポートを分析している場合は、既存の分析機能がRFC 9990に基づくレポート形式に対応しているか確認し、必要に応じて修正する必要がある。また、外部事業者に委託して分析を行っている場合は、該当事業者に対応済みか確認することが推奨される。
なお、DMARCの認証失敗レポート、すなわちRUFレポートには、送信者アドレスやメールヘッダー等、個人情報または機密情報に該当し得る情報が含まれる場合がある。そのため、利用にあたっては個人情報保護法制やプライバシー保護の観点から慎重な検討が必要であり、一般的には設定が推奨されないことが多い。
また、認証失敗メールが大量に発生した場合、多数の失敗レポートが送信され、レポート受信側に過大な負荷がかかるおそれがある。さらに、実際には多くのメール受信システムがRUFレポートの送信に対応していない、または送信を制限しているため、設定しても期待どおりにレポートを受領できない場合が多い。
以上の理由から、通常運用においてはRUFレポートの設定は推奨しない。
DMARCの導入状況
フィッシングメールの増加や、Gmailなどの受信側サービスによる送信者認証要件の強化を背景に、国内におけるDMARCの導入率は、Gmailが受信側要件を公表した当時と比べて大きく上昇している。
しかしながら、ドメイン詐称への対策として有効な “reject” や “quarantine” の設定率は40%弱にとどまっており、諸外国と比較して大きく後れを取っている。
サイバー犯罪の多くはメールを起点としていると言われるなか、DMARCが十分に有効なポリシーで運用されていないことは、依然として課題である。
図 1各国の株式Top企業のDMARC導入率
※ JSSEC調べ
※ 調査は各社のTopドメインでのDMARCレコード記述有無より調査
また、DMARCの普及に伴い、DMARCレコードの記述ミスも散見されるようになっている。特に多いものとしては、複数のDMARCレコードの登録、パラメータの重複、各パラメータ間の区切り文字の誤りなどが挙げられる。さらに、DMARCレコードを登録すべきドメイン名に、DMARCレコード以外の内容が記述されている例も多く見られ、特にSPFレコードと思われる記述が含まれているケースが目立つ。
また、今回の仕様変更で廃止された “pct”、“ri”、“rf” を設定しているドメインも多数存在している。特に “pct” については、約4分の1のドメインで設定されている。
したがって、今回のDMARC仕様変更を機に、DMARCレコードに記述ミスや不要・廃止済みのパラメータが含まれていないか、あらためて確認することが推奨される。
まとめ
DMARCのRFC改版に伴い、本稿では主な変更点について説明した。今回の改版では、これまで曖昧だった仕様が、実際の運用状況を踏まえて整理・見直されている。また、DMARCの位置づけが従来のInformationalからStandards Trackへ変更されたことで、より正式な標準仕様として位置づけられることとなった。
この改版を踏まえ、自社のDMARCレコードの記述に問題がないかをあらためて確認することが重要である。また、DMARCを未導入の場合や、DMARCポリシーが “none” のままとなっている場合は、段階的に “quarantine” または “reject” への移行を検討することが推奨される。