DMARCbisがサブドメインなりすましへの新たな防御を追加
DMARCbisがRFC 9989として正式になりました。新しいnp=タグは、sp=タグでは閉じられなかったサブドメインなりすましの穴をふさぎ、np=rejectが安全な既定値です。
2015年以来初めてとなるDMARC標準の全面改定、DMARCbisが正式なものになりました。2026年5月19日に3つの新しいRFC(9989、9990、9991)として公開され、RFC 7489を置き換えるとともに、DMARCをIETFの標準化トラックへと移しました。今回の変更の大半は直ちに対応を要するものではありませんが、対応する価値のある追加が1つあります。旧標準が放置していたサブドメインなりすましの穴をふさぐ、np=という新しいタグです。
DMARCは、認証チェックに失敗したメールを受信側サーバーがどう扱うべきかを指示する標準です。すでにp=quarantineまたはp=rejectで運用しているなら、DMARCbisが承認されても、これまでに公開してきたレコードが壊れることはありません。pctタグの廃止やPublic Suffix Listからの脱却といった目立たない変更については、DMARCbisが何を意味するのかを平易な言葉で解説したガイドでまとめています。本記事で扱うのは、今日対応する価値のある1つの追加です。
リンクをクリックすると、目的のセクションまで移動できます。
DMARCbisで正式になったこと
DMARCbisは単一の文書ではありません。3つの別々のRFCとして公開され、それぞれが標準の一部分を担います。
- RFC 9989はコアプロトコルを規定します。ポリシーをどう公開するか、アラインメントをどう評価するか、受信側がDMARCレコードをどう処理するかです。
- RFC 9990は集計レポートのフォーマット、つまりドメインが毎日受け取るXMLのサマリーを規定します。
- RFC 9991は失敗レポート(メッセージごとのフォレンジックレポート)を規定します。
これら3つのRFCがまとめてRFC 7489、すなわちこれまでDMARCを規定してきた2015年の仕様を置き換えます。同時に標準のステータスも引き上げられており、ここは正確に押さえておく価値があります。RFC 7489はInformational(情報提供)に分類されていました。つまりDMARCを文書化してはいたものの、IETFの標準化トラックとしての承認は伴っていませんでした。DMARCbisはProposed Standard(標準化提案)として公開されています。これは、承認済みの標準化トラック文書にIETFが与える成熟度レベルの名称です。「Proposed(提案)」という語が付いているものの、これは下書きや作業中のものではなく、完成した正式な標準です。そして、広く使われている多くのインターネットプロトコルがついぞ先へ進まなかった、標準化トラックの最初の段でもあります。実務上、これは新たな義務というより成熟を示すものです。Informational文書では疑問が生じていた調達やコンプライアンスの場面で、標準により確かな足場を与えますが、すでに機能しているレコードに手を入れることを今すぐ求めるものではありません。
sp=タグでは足りないところ
DMARCでは、メインドメインに1つのポリシー(p=タグ)を、サブドメインには別のポリシー(sp=タグ)を設定できます。ただし問題は、sp=がDNSに存在するサブドメインしか制御しない点です。一度も作成されていないサブドメインについては何も語りません。
攻撃者が突くのはこの穴です。詐欺師はaccounting.yourbrand.comやpayroll.yourbrand.comから、つまり自分では一度も設定しておらず、DNSレコードもまったく持たないアドレスからメールを送れます。こうしたサブドメインはDNSの世界でNXDOMAIN(そのような名前は存在しない)と呼ばれる応答を返すため、一部の受信側はこれまで、レコードがないことをポリシーがないことと同一視して、メッセージを通してしまっていました。
大半のドメインはここを無防備なままにしています。DMARCeyeの2026年第1四半期業界レポートでは、フルに強制執行している(p=reject)ドメインのなかでさえ、65.15%がいかなるサブドメインポリシーも宣言していません。p=noneでは86.67%にのぼります。ドメインはトップレベルでは固く守られていても、1つ左のラベルでは攻撃者に開いた扉を渡したままになり得るのです。
サブドメインポリシーの全内訳は、2026年第1四半期データセットの残りとあわせてレポートに収録されています。
np=タグは何をするのか
np=タグは、存在しないサブドメイン、つまりDNSレコードを返さないあらゆるサブドメインに特化したDMARCポリシーを設定します。これはsp=に欠けていたもう半分です。
np=を公開しておくと、でっち上げのサブドメインから来たメールを評価する受信側は、明確な順序に従います。まずnp=ポリシーがあるかを確認します。設定されていなければsp=にフォールバックします。それも無ければ、メインのp=ポリシーにフォールバックします。この新しいタグは、これまで偽装サブドメインのメールがすり抜ける余地となっていた曖昧さを取り除きます。
大半のドメインにとって、適切な値はnp=rejectです。存在しないサブドメインは正当なメールを一切送らないため、そこから来たと称するメールをすべて拒否しても失うものは何もなく、なりすましの一群まるごとに対して扉を閉ざせます。すでにv=DMARC1; p=reject;となっているレコードは、1つ追加してv=DMARC1; p=reject; np=reject;になります。同じ理屈は、既存のサブドメインにはsp=を通じて当てはまり、どちらをどう設定すべきかはsp=サブドメインポリシータグのガイドで順を追って説明しています。
ただしnp=が役立つのは、受信側がそれを尊重するようになってからです。生まれたばかりのタグであるため、対応はまだメールボックスプロバイダー全体に広がっている途上です。そのため、今これを公開することは、即効の修正というよりも将来に向けた前方互換性のある備えです。
ドメインを入力すると、すでに設定されているsp=やnp=タグを含め、今日あなたが公開しているDMARCレコードを確認できます。
DMARCbisの承認で他に何が変わったか
今回の改定を締めくくる変更が他に2つありますが、どちらも今日あなたに多くを求めるものではありません。
pctタグは廃止されました。これはポリシーをメールの一定割合ずつ適用できるようにする狙いのものでしたが、受信側の実装にばらつきがありました。DMARCeyeの2026年第1四半期データセットでは、p=quarantineドメインの94.11%とp=rejectドメインの93.51%が、すでにこれを無視して初日からフル強度で強制執行していました。DMARCbisはこれを、よりシンプルなt=(テスト)フラグに置き換えます。段階的ロールアウトという調光つまみがなぜ機能しなかったのかの詳しい経緯は、DMARCbisが何を意味するのかのガイドにあります。
DMARCはまた、組織のドメイン境界がどこにあるかを割り出すためにPublic Suffix Listに依存するのをやめました。これからはDNSを直接たどります。単一ドメインの所有者は違いに気づかないでしょう。大規模なサブドメイン群を運用している場合は、レコードが想定どおりに解決されるかを確認しておくべきです。
今、何をすべきか
np=がどれだけ重要かは、あなたが何を運用しているかによって変わります。
単一のドメインを運用している、または小規模事業を営んでいる場合:np=rejectの追加は1行で済む変更で、デメリットはありません。しかも、これまで作成したサブドメインをすべて覚えていなくても、なりすましの経路を1つ閉ざせます。自社のDNSを自分で管理していない場合は、管理している人の仕事になります。多くの場合、ドメインを購入した先のドメインレジストラ(GoDaddyやNamecheapなど)、Webホスティング事業者、またはメールを設定したITの委託先や代理店です。公開してほしいレコードv=DMARC1; p=reject; np=reject;を伝え、ドメインに追加または更新してもらうよう依頼してください。
ECストアやマーケティング用ドメインを運用している場合:偽装サブドメインはセキュリティの問題であると同時にブランドの信頼の問題でもあります。よくできたbilling.yourbrand.comは、まさにあなた自身に見える姿で顧客の受信トレイに届くからです。np=rejectはアクティブなモニタリングと組み合わせ、何かを締め付ける前に、どの送信元が自社ドメインを使って送信しているかを把握できるようにしてください。DMARCeyeの無料プランは1ドメインを対象にレポート解析をフルカバーしますので、始めるには十分です。
代理店またはMSPの場合:np=rejectは、管理しているすべてのクライアントドメインに展開できる、手早く正当性を説明しやすい一手です。DMARCeyeは各クライアントアカウントを独立してスコープ管理するため、チームは単一のコンソールからポートフォリオ全体のサブドメインのポスチャを追跡でき、各クライアントは自社のデータのみを参照します。
エンタープライズのメールインフラを運用している場合:np=はサブドメインガバナンスの一部として扱ってください。どの事業部門がどのサブドメインを保有しているかを棚卸しし、正当に送信するものにはsp=を設定し、それ以外のすべてにはnp=rejectを設定します。次回のDMARCレビューにこの変更を組み込むときに進めるとよいでしょう。
まとめ
DMARCbisが正式な標準になったからといって、すでに機能しているDMARCレコードに変更を強いられることはありません。それがしたのは、大半のドメインがいまだ開いたままにしている穴、すなわち偽装され一度も作成されていないサブドメインに対する修正を、正式に位置づけたことです。np=タグがその新しいレバーであり、np=rejectが大半のドメインにとって安全な既定値です。自分にそれが必要かどうかを知る唯一の方法は、自社ドメインが今日公開している内容を見ることです。
その可視化こそ、DMARCeyeが作られた目的です。ドメインが受け取るDMARCレポートを解析し、どの送信元があなたの名前で送信しているか、そしてポリシーのどこに穴があるかを、平易な言葉で示します。