【RFC 9989 ほか】DMARC の仕様が改訂されました

calendar 2026-05-25 RFC DMARC  
共有する:

目次

はじめに

なりすましメールを減らすための技術仕様である DMARC が先日改訂されました！

いろいろ変更された部分がありますので、変更内容を紹介しつつ、今後何をするのが良さそうかまとめてみます。

※誤りがあるかもしれませんが、その点はご容赦ください。
※社内ブログ向けに書いたものですが、もったいないので一部改変して自ブログにも投稿しています。

そもそも DMARC とは

冒頭に書いた通り、DMARC はなりすましメールを減らすための技術仕様です。 メールソフトやメールサービスの画面に表示される差出人のメールアドレス (From ヘッダ) のドメイン部分のなりすましをある程度防ぐためのものです。

全然広まらなくて軽く諦めていた技術なのですが、2023年12月に Google が DMARC に対応していないメールを Gmail では受信できなくなるようにするといったことを発表して以降、急激に広まりました。

DMARC が広まった経緯や対応が必要なのは主にメールの送信者側であるということから、DMARC は相手にメールをブロックされないようにする技術と勘違いしている人も居るかもしれませんが、実際はそうではありません。

DMARC は、なりすましメールかどうかをメールの受信者が機械的に判定できるようにする技術です。 送信者が受信者であるステークホルダーを守るための技術である、と理解するのが適切であり、社会的に責任のある組織が率先的に対応しないといけないものです。

変わったこと

DMARC の仕様文書で変わったことをいくつか紹介します。

Proposed Standard になった！

これまでの DMARC は2015年3月に公開された RFC 7489 で定められていました。 RFC 7489 は IETF における標準化のプロセスを経たものではなく、独立した個人によって提出・公開された文書であり、いわゆる標準ではない "Informational" ステータスのものでした。

それが今回ようやく IETF のワーキンググループでの議論を経た文書として公開され、"Proposed Standard" ステータスになりました！ インターネット標準ではないものの、ほぼ標準と言っても過言ではない状態になったということです。

これで DMARC を安心してこれまで以上に推進できますね。

組織ドメインの決め方が変わった

DMARC では、メールの差出人 (From ヘッダ) のドメイン部をもとに、そのドメインの組織ドメイン (Organizational Domain) と呼ばれるものを決定し、ポリシーの適用や評価を行います。

組織ドメインとは端的に言うと、レジストラ等から取得して利用できるドメインと理解すれば概ね間違いはないです。

これまでの DMARC では、この組織ドメインを決める際に、Public Suffix List を使うものとされていました。 このリストには "jp", "co.jp", "com" などのように、レジストラ等から取得できるドメインの上位のドメインが列挙されているものであり、それらドメインの1つ下の階層のものが組織ドメインであるという具合でした。 経験的にそうするのが良いとされていたものの、実際に DMARC が展開される中でいくつか問題が発覚したことや、Mozilla のコミュニティでメンテナンスされているリスト が広く利用されていることから、今回の改訂でより適切な方法が定められました。

新しい DMARC では DNS Tree Walk という方法により、外部のリストを参照しなくても DNS だけで組織ドメインを特定できるようになりました。 この方法の中では、2021年7月に公開された DMARC の拡張仕様である RFC 9091 の中で登場した Public Suffix Domain という概念が取り込まれています。 そのドメインは Public Suffix List に記載されているドメインとほぼ同じではありますが、ドメイン管理者が自ドメインが Public Suffix Domain であるかどうかを DNS 上で宣言できるため、DNS だけで完結できるようになったということです。

詳細は RFC 9989 の "4.10. DNS Tree Walk" を精読ください。

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

DMARC レコードでは np, psd, t という3種類のタグが追加され、逆に pct, rf, ri が削除されました。 np と psd タグは DMARC 拡張仕様の RFC 9091 で定義されたものであり、今回の新しい DMARC に取り込まれました。

組織ドメインの決め方が変わったことで、"jp" や "go.jp" ドメインなど Public Suffix Domain に設置した DMARC レコードにも効果が生じるようになりました。 これにより、Public Suffix Domain には v=DMARC1; p=reject; sp=none; np=reject; psd=y のような DMARC レコードが設置されるようになるはずです。

np は存在しないドメインに適用するポリシーを決めるためのもので、psd はそのドメインが Public Suffix Domain であるかどうかを宣言するためのものです。 これまでの DMARC では、存在しない組織ドメイン (例えば "hoge.go.jp" など) には DMARC ポリシーを適用する方法がなかったため、なりすまし放題な状況でした。 RFC 9091 にてこの点が改善されたのですが、今回の改訂で正式に対応できるようになったということです。

"go.jp" や "lg.jp" など厳格に運用されているドメイン配下の存在しないドメインを名乗るメールが受信者に届いてしまうのは問題ですので、JPRS や政府方面の人たちがそのうち対応することでしょう。

なお、理由があって none ポリシーで運用している組織においても、存在しないサブドメインになりすまされることを防ぐために、np タグに reject または quarantine ポリシーを設定するという使い方もできるかと思います。

DMARC の展開方法が記載された

これまでの DMARC の RFC では技術仕様が定義されていたものの、DMARC を展開するにあたって具体的に何をどのようなステップで実施すべきか、ほとんど記載されていませんでした。 今でこそたくさんの情報がインターネット上に出回っているので、少し調べて考えれば何をすべきかわかりますが、5年ぐらい前 (※もう少し前かも) はわかる人にはわかるという状況だったように記憶しています。

今回の DMARC の改訂により、RFC の中で DMARC の展開方法が記載されるようになりました。 RFC 9989 の "5. DMARC Participation" にて、ドメイン所有者 (≒メール送信者)、Public Suffix Operator (≒JPRSなどのレジストリ)、メール受信者のそれぞれが何をすべきか記載されています。

DMARC を既に展開した人たちにとってはもはや新しい情報はほとんどありませんが、改めて読むと有益な情報もあったりします。 特に "5.1.8. A Note on Large, Complex Organizations and Decentralized DNS Management" の内容は、後述の通り非常に有益な組織もいるはずです。

レポートに関する仕様が別 RFC に分割された

DMARC の "R" は Reporting であり、DMARC の運用に不可欠なレポートの仕様についても RFC にて定義されています。

これまでの DMARC では RFC 7489 の中で全て定義されていましたが、新しい DMARC ではレポートの仕様は RFC 9990 と RFC 9991 に分割されました。 内容自体は多少変更があった程度なので、ここでは詳しく述べないことにします。

新しい DMARC で何をすると良いか

既に DMARC 対応を進めて、quarantine や reject ポリシーで運用できている普通の組織では、新たに実施すべきことはほぼありません。 そのまま運用していれば問題ないはずです。

一方で、none ポリシーの組織では実施すべきことがあったり、一部の顧客には情報をインプットして対応を促すのが良いことがあったりしますので、それらについて記載します。

none ポリシーの組織に np タグを追加する

前述の通り、理由があって none ポリシーで運用しているようであれば、np タグに reject または quarantine ポリシーを設置するのが良いです。 サブドメインを使って適当にメールを送信しているようなことさえなければ、特に弊害もなくポリシーを強化できます。

理由なく none ポリシーで運用しているのであれば、まずは DMARC 対応を頑張りましょう。

ブランド TLD に DMARC レコードを設置する

企業名やブランド名のトップレベルドメインを持っている組織もいくつかあります。 日本で目立つところを挙げると、NTT、KDDI、ソフトバンク、トヨタ、ホンダ、ソニー、NECなどなどです。

ブランド TLD は本来は組織ドメインであるものの、これまでの DMARC の技術仕様 (Public Suffix List の内容) では組織ドメインとして扱われていませんでした。 そのため、前述のように存在しないサブドメインのなりすましを防ぐことができない状況でした。

しかし新しい DMARC によって対策ができるようになったため、ブランド TLD に適切な DMARC レコードを設置すべきです。

複数組織での組織ドメインの共有方法を改善する

三菱UFJフィナンシャル・グループのドメインの使い方が目に付いたので、内情は全く知りませんが例として挙げます。

三菱UFJフィナンシャル・グループの組織ドメインは "mufg.jp" ですが、子会社の銀行は "bk.mufg.jp"、証券会社は "sc.mufg.jp"、カード会社は "cr.mufg.jp" のように、1つの組織ドメインを複数の会社で共有しているようです。 各社は異なる会社なのでそれぞれ独自に DMARC の運用が必要のはずですが、これまでの DMARC では組織ドメインが同じものとして扱われているため、少し歪な運用が必要のはずです。

例えば、ネットバンキングを使ったら差出人のドメイン部が "direct-11.bk.mufg.jp" である通知メールが来たのですが、このドメインに DMARC レコードが詳しく設定されています。 一方で、"bk.mufg.jp" には無害でほぼ意味がない内容だけが設定されています。

通知メールで利用されるメールアドレスのドメイン部は他にも多数存在するであろうことを考えると、本来は "bk.mufg.jp" の DMARC レコードに設定を記載して、"direct-11.bk.mufg.jp" のようなドメインには DMARC レコードを設置しないという運用がシンプルです。 しかし、これまでの仕様では "direct-11.bk.mufg.jp" ドメインに DMARC レコードが存在しないと "mufg.jp" ドメインの DMARC レコードが適用されるため、各社ごとの運用を行うにはメールの送信で利用する全てのドメインに DMARC レコードを設置する必要がありました。

新しい DMARC ではどのドメインを組織ドメインとして扱うようにするか、組織側がコントロールできるようになったため、上記の歪な運用は解消できます。 具体的には、各社のサブドメインの DMARC レコードにて psd=n を記載すれば、DMARC の処理の中ではそのサブドメインが組織ドメインとして扱われるようになります。 つまり、各社が1つのサブドメインに DMARC レコードを設置すれば、その下の多数のサブドメインには DMARC レコードを設置しなくても良くなるということです。

大きなメリットがあるわけではないですが、将来の問題を防止するためにもこういった小さな改善を行うことは良いことだと思います。

あとがき

DMARC やその他送信ドメイン認証技術は安全なインターネットを実現するために本当に必要なものなので、多くの組織が積極的に適切に対応していくことを強く望んでいます。 自組織が対応してもメリットをほとんど感じないかもしれませんが、そういう考え方は捨てて、ステークホルダーを守るためにやるのだという考えを持って対応しましょう。

自分が手を出せる範囲は対応できるのですが、そうでない範囲は口しか出せないため、いろいろともどかしい気持ちはありますが……。