DMARC RFC ガイド：改訂された規格がもたらす影響
IETFのDMARCワーキンググループにおける開発を経て、DMARCbisが正式に策定されました。そこで今回は、新しいRFC（Requests for Comments）である9989、9990、および9991がどのように策定されたか、またこれらが皆様のDMARCレコードにどのような影響を与えるかについてご説明いたします。
IETFは、RFC 9989、RFC 9990、およびRFC 9991という3つの新しいDMARC仕様を公開し、これによりRFC 7489は廃止となりました。
今回の更新は画期的なものではなく、ドメイン所有者が機能を維持するためにDMARCレコードを更新する必要もありませんが、これらの変更は、この制御機能の明確性、セキュリティ、および相互運用性を向上させるための取り組みです。
DMARC仕様にはどのような変更があったのでしょうか？
以前はDMARCに関するRFCが1つだけでしたが、現在は3つの別々のRFCが存在しており、これらについては以下で解説します。
DMARC (RFC 9989)
DMARCの基礎となる仕様であるRFC 9989では、新しいタグが導入され、他のタグは非推奨となり、有効なDMARCポリシーレコードをより正確に特定するために、パブリックサフィックスリスト（PSL）がDNSツリー探索アルゴリズムに置き換えられています。
廃止された DMARC タグ
DMARC仕様から削除されたタグには、pct、rf、riが含まれます。pctタグはt（テストモード）タグに置き換えられ、すべて（100%）かゼロ（0%）かのシナリオが実現されるようになりました。rf（集計レポート形式）およびri（集計レポートの間隔）タグは、それぞれ実装されることが少なく、受信側で無視されていたため削除されました。 これらのタグを削除した目的は、DMARCの導入を簡素化および効率化することにあります。
新しいDMARCタグ
以下に、新しいDMARCレコードのタグとその仕組みについて説明します。
t (テストモード)–pctタグに代わるもので、以下のバイナリ値を持ちます：
- t=n は、公開されたDMARCポリシーを適用するデフォルト値であり、pct=100という値と同等です。
- t=y これは、p、sp、および/またはnpタグで公開されたDMARCポリシーを適用しないことを示し、pct=0の値と同様に機能します。
tタグはいつ使うか
t=yと設定する（併せて p=quarantine または p=reject）に設定して、強制適用を安全にテストします。受信側は強制措置を適用しないため、メールへの影響はありませんが、レポートには依然としてどの送信元が基準を満たさないかが表示されます。メーリングリストが自身のドメインで再送信するなど、仲介者が書き換えたメールはデータから除外されるため、強制適用を行う前に準拠が必要となる送信元のみが残ります。
np (存在しないサブドメイン向けポリシー)–pタグやspタグと同じポリシー値を持つnpタグを使用すると、存在しないサブドメインにポリシーを適用することができます。このタグの利点は、存在しないサブドメインに対して強制ポリシーを設定することで、犯罪者が親ドメインを基にした偽のサブドメインから詐欺メールを送信するのを防ぐことができる点にあります。
「np」タグはいつ使うべきか
pおよびsp を none のままに保ちつつ、存在しないサブドメインからのメールに対して強制適用を行うには、np=quarantineまたはnp=rejectを設定します。よくある攻撃手法として、独自のポリシーが存在しないサブドメイン（例：abc123.example.com）のアドレスを偽装するものが挙げられます。npタグを使用することで、その他のメールに対して強制適用を行わずに、こうした悪用をブロックすることができます。
psd（パブリックサフィックスドメイン）– パブリックサフィックスドメイン（PSD）を明確化および定義するために使用されます。このタグは、送信元ドメインのルートドメインを定義するために使用され、以下の値をとります：
- psd=y は、そのドメインが PSD であることを示します。ポリシー検出中に、このタグの値がyであるレコードが見つかった場合、この情報に基づいて組織ドメインおよび DMARC ポリシードメインが決定されます。
- psd=n は、DMARC ポリシーレコードが PSD ではなく、組織ドメインおよびそのサブドメインに対して公開されていることを示します。
- psd=u はデフォルト値であり、DMARC ポリシーレコードが PSD ではないドメインに対して公開されていることを示します。このドメインは、それ自体およびそのサブドメインにとって組織ドメインである場合もあれば、そうでない場合もあります。この場合、DNS ツリーウォークによって組織ドメインが決定されます。DNS ツリーウォークとは、DNS を辿ってドメイン名を IP アドレスに関連付けるプロセスです。
psdタグはいつ使うべきか
ドメイン所有者にとって最も一般的な設定は「psd=n」です。以前は、組織ドメイン（Organizational Domain）が固定されており、DMARC仕様によって自動的に決定されていたため、所有者が制御することはできませんでした。psd=nタグとその値を使用することで、ドメイン所有者は同じドメイン空間内で複数の組織ドメインを定義できるようになります。これは、メール送信元をセグメント化し、異なるレベルでポリシーを個別に管理するのに役立ちます。たとえば、a.b.example.comでpsd=n を設定すると、それが組織ドメインとなります。そのサブドメインはこのレコードを継承しますが、b.example.comやc.example.com は代わりにexample.com のレコードを継承することになります。
DMARC 集計レポート (RFC 9990)
DMARCワーキンググループは、当初のDMARC RFCから集計レポートの規定を削除し、専用のRFCを作成しました。RFC 9990では、従来オプションだったDKIMがレポートにおいて必須となりました。これにより、DKIMキーに関する洞察の獲得や、キーローテーションに関するトラブルシューティングが容易になります。さらに、このRFCではXML形式が最新化され、レポートの統一性が向上し、関連ツールでの処理が容易になったほか、新しいDMARC仕様からのデータ項目も取り入れられています。
障害報告 (RFC 9991)
RFC 9991の公開に伴い、標準化された不正利用報告フォーマット（ARF）が定められ、受信者には、エラーやDKIM/SPF認証結果などの特定のフィールドを報告に含めることが義務付けられました。また、本規格では、個人識別情報（PII）の漏洩という長年の問題にも言及しており、RUF報告の拡散を防ぐため、情報の黒塗り処理や転送時のセキュリティに重点を置くとともに、第三者による検証ガイドラインも導入しています。
新しいRFCを受けて、ドメイン所有者が取るべき対応
まず第一に、DMARC仕様の変更によって、現在のDMARC設定が機能しなくなることはありません。RFC 9989はRFC 7489と互換性がありますが、新しい標準に準拠することで、ドメインのセキュリティをベストプラクティスに沿ったものにすることができます。
最新のDMARC RFCが公開された後も、既存のv=DMARC1レコードは引き続き有効であり、電子メールセキュリティの業界標準としての地位を維持しています。ただし、DMARCレコードを確認し、改訂されたDMARC仕様に準拠しているかどうかを確認することをお勧めします：
- 不要になったpct（パーセンテージ）、rf（レポート形式）、およびri（レポート間隔）タグを削除してください。
- 必要に応じて、新しいタグ「np」（存在しないポリシー）、「psd」（パブリックサフィックスドメイン）、および「t」（テストモード）を追加してください。
以下は、新しいタグがDMARCレコードにどのように表示されるかの例です：
v=DMARC1; p=reject; np=quarantine; psd=y; t=y; rua=mailto:[email protected]インターネット標準の変更にはよくあることですが、プロバイダーによる採用には時間がかかります。新しいタグが期待通りの結果を出さない場合、そのプロバイダーではまだ実装されていない可能性が高いです。対応は段階的に展開され、すべてのプロバイダーで同時に実施されるわけではありません。
—アッシュ・モリン、dmarcian プロフェッショナル・サービス部門ディレクター
dmarcianがお手伝いします
フィッシングやスプーフィング対策において、DMARCの効果的な導入と維持管理は極めて重要です。当社は、お客様が最初から適切に導入・運用できるよう、必要なリソースと専門知識を提供しています。
当社は、あらゆる規模の組織を支援しています：
- 推測や業務の混乱を排除し、正しい方法でDMARCを導入。
- 御社に代わって送信しているすべてのソースを把握し、メールエコシステム全体の完全な可視化を実現。
- 進化し続けるメールセキュリティポリシーの一歩先を行く。
さらに詳しく議論を続けたい方は、ぜひ dmarcian Forum へお越しください。
