DMARCのquarantine・reject移行ガイド：正規メールを失わずにp=noneから強化する手順

1. p=none、quarantine、rejectは受信側に何を求めるのか

_dmarc.example.comに置くDMARCレコードのpタグは、FromドメインがDMARCに失敗したメール、つまりFromドメインとアライメントの取れたドメインでSPFもDKIMも成功しなかったメールを、受信側にどう扱ってほしいかを示します。これは命令ではなく要望です。2026年5月に公開され、RFC 7489に代わった現行のDMARC標準であるRFC 9989も、最終的な判断は各受信側のローカルポリシーに委ねています。

移行を考えるうえで大事な点が二つあります。一つ目は、p=noneだけでは何も守れないことです。レポートが届くだけで、それもレコードにruaのアドレスがある場合に限られます。二つ目は、受信側によって適用の仕方が違うことです。RFC 9989はポリシーがrejectだという理由だけで拒否しないよう受信側に求めており、代わりに隔離する受信側もあります。同じ変更でも、メールボックス事業者ごとに結果が異なり得るということです。スイッチを一度切り替えるのではなく、小さく元に戻せる手順の連続として計画してください。

大手のメールボックス事業者は大量送信者にDMARCレコードを求めていますが、p=noneでも受け入れています。各社の要件とレコードの各タグの意味はSPF・DMARCの確認方法の解説にまとめています。

2. DMARC集約レポート（rua）の読み方

安全な移行を可能にするのは集約レポートです。レコードにrua=mailto:dmarc-reports@example.comのようなレポート送付先を加えると、レポートを送る受信側から圧縮されたXMLファイルが届くようになります。多くはUTCの1日分で、Fromに自社ドメインを使ってメールを送ったIPアドレスごとに、その結果が並んでいます。形式はRFC 9990で定められています。receiver.example!example.com!1791590400!1791676800.xml.gzのようなファイル名は、報告した受信側、自社ドメイン、そして対象期間の開始と終了（Unix時刻）を表します。

ファイル内の各<record>は、送信元と結果ごとにメールをまとめたものです。特に重要な項目は次のとおりです。

最後の行とpolicy_evaluatedの違いを理解することが、いちばん役に立ちます。ニュースレター配信サービスがauth_resultsでmailer.example.netのDKIM passを示していても、そのドメインはexample.comとアライメントが取れていないため、DMARCとしては失敗します。DMARCの結論を表すのはpolicy_evaluatedだけです。

レポートは1日分ではなく数週間分を読んでください。月次の請求書、四半期ごとのニュースレター、年1回の更新案内は、それぞれ自分の周期で送られてきます。量が増えると生のXMLを読むのは大変なので、送信元、アライメント、処理結果ごとに日単位で集計できるパーサーやレポートツールを使うと確認が現実的になります。すべての受信側が集約レポートを送るわけではないため、静かな1週間だったからといって自社ドメインで何も起きていないとは限りません。ruaの送付先が別の組織ドメインにある場合、そのドメインはexample.com._report._dmarc.reports.example.netのような、v=DMARC1で始まる許可レコードを公開する必要があります。ないと受信側はその送付先を無視します（RFC 9990の4節）。

3. 適用前に正規の送信元をすべて洗い出す

適用を安全に進められるのは、Fromに自社ドメインを入れて送るすべてのシステムを把握しているときだけです。リストは二つの方向から作ります。組織が使っているものと、レポートに現れるものです。よくある送信元は次のとおりです。

• 社員が毎日使うメールサービス。
• マーケティングとニュースレター。誰かがまだログインしている古い配信ツールも含みます。
• アプリケーションのトランザクションメール：登録確認、パスワード再設定、領収書など。
• 業務ツール：CRM、請求・決済、問い合わせ管理、人事・採用、日程調整、電子署名。
• Webサイトのフォームやプラグイン：noreply@example.comとして送るもの。
• 機器やスクリプト：複合機のスキャン送信、監視アラート、定期ジョブ、社内のリレーサーバー。

次に、レポートに出てくる送信元を一つずつリストの項目に対応づけます。IPアドレスの逆引き（dig +short -x 192.0.2.10）で事業者が分かることが多く、その事業者のドキュメントに対応するSPFのincludeとDKIMの設定方法が載っています。結果は次のような表にまとめておきます。

この作業の目的は最後の行にあります。把握している送信元がすべて成功するようになれば、なお失敗するのは主に詐称メールか設定ミスのメールで、まさにそれを止めるのが適用の役目です。たまにしか送らない送信元ほど見落とされやすいので、静かな1か月を信じる前に、経理、人事、サポートの担当者に使っているツールを確認してください。

4. SPFとDKIMのアライメント：緩和（relaxed）か厳格（strict）か

DMARCが成功するのは、SPFかDKIMが成功し、かつその対象ドメインがFromドメインとアライメントが取れているときです。アライメントの取れた成功が一つあれば十分です。SPFで確認されるのはエンベロープ送信者のドメイン（RFC 7208）、DKIMでは有効な署名のd=の値（RFC 6376）です。どこまで一致を求めるかはaspfとadkimタグで決めます。

• 緩和（r、既定値）：二つのドメインが同じ組織ドメインに属していればよく、bounce.example.comもnews.example.comもexample.comとアライメントが取れます。
• 厳格（s）：ドメインが完全に一致する必要があります。

RFC 9989は、RFC 7489が頼っていたパブリックサフィックスリストではなく、DNSツリーウォーク（DNS Tree Walk）で組織ドメインを決めます。完全なドメイン名から上位に向かって_dmarcレコードを問い合わせる方式です。

RFC 9989によれば、ほぼすべてのドメイン所有者にとって緩和アライメントで十分です。厳格アライメントは、事業者ごとにバウンス用サブドメインを用意するというよくある構成を壊してしまいます。明確な理由がない限り既定値のままにしてください。理由の例としては、サブドメインを外部の委託先に任せている場合があります。緩和アライメントのままだと、vendor.example.comで認証されたメールがexample.comとして通ってしまうからです。どちらを選ぶにしても、すべての送信元でDKIMをアライメントの取れた認証方式にしてください。転送ではSPFが失敗します。転送するサーバーが自社のレコードに載っていないためです。一方、DKIM署名はメールが書き換えられない限り、通常は転送後も有効です。

5. 段階的な導入：pctは廃止、t=yを使う

以前の解説ではpctで段階的に進める方法が紹介されていました。p=quarantine; pct=10から始めて25、50、100と上げ、失敗したメールのうちポリシーを適用する割合を増やしていくやり方です。RFC 7489では、抽出から外れたメールには一段階弱いポリシーが適用されました。RFC 9989はこのタグを削除しました。付録A.6によると、0と100以外の値はほとんど正確に適用されておらず、そのずれも実装ごとに大きく異なっていたためです。

この削除には落とし穴があります。RFC 9989は、知らないタグを無視するよう受信側に求めています。そのため新しい標準に従う受信側は、p=quarantine; pct=25を単なるp=quarantineとして読み、失敗したメールすべてに適用します。中間のpct値で影響を抑えることは、もう当てにできません。

代わりに導入されたのがテストフラグtです。t=yを付けると、公開したポリシーより一段階弱い扱いを受信側に求めます。p=quarantine; t=yはnoneのように、p=reject; t=yはquarantineのように扱われます。レポートはこれまでどおり届き、受信側はこの違いを理由policy_test_modeとして記録できます。RFC 9989はt=yとt=nを、それぞれpct=0とpct=100に相当するものとしています。

移行期間中は、RFC 7489しか実装しておらずtを無視する受信側もあれば、pctを無視する新しい受信側もあります。旧ルールのpct=0と新ルールのt=yは同じ扱いを求めるものなので、テスト中は両方を公開しておけます。

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

数週間レポートを確認したら、両方のタグを外してp=quarantineを完全に適用します。rejectの前にも同じ手順を繰り返します。p=reject; t=y; pct=0は隔離を求める指定で、二つのタグを外すと拒否が有効になります。

割合ではなくメールの種類ごとに段階を分ける方法もあります。news.example.comのようなサブドメインは独自のDMARCレコードを持てるので、メインのドメインより先に、または後から適用に進めることができます。RFC 9989自身の導入例でも、まずサブドメインでt=y付きのp=quarantineを試してから強化しています。

6. サブドメインのポリシー：spとnp

example.comのDMARCレコードは、独自の_dmarcレコードを持たないサブドメインにも適用されます。次の二つのタグで、サブドメインのポリシーをpと変えられます。

動きを予測しやすくするためのルールがいくつかあります。spが意味を持つのは組織ドメインのレコードだけで、独自のレコードを公開しているサブドメインには、そのレコードのpが適用されます。pがまだnoneのうちにnp=rejectを設定するのは、リスクの低い最初の一歩です。billing-support.example.comのような架空の名前を使った詐称メールは拒否され、npに対応していない受信側は単にspかpを使います。これを頼りにする前に、実際にメールを送っているサブドメインには少なくとも一つDNSレコードがあり、実在するものとして扱われることを確認してください。また、SPFは継承されない点にも注意が必要です。エンベロープ送信者として使う名前には、DMARCのポリシーにかかわらず、それぞれSPFレコードが必要です。

7. p=noneからp=rejectまでの現実的なスケジュール

どのドメインにも当てはまるスケジュールはありません。RFC 9989も、適用の準備が整うまでに何か月分ものレポートが必要になることがあると注意しています。利用者がメーリングリストに投稿するドメインについては、少なくとも1か月をp=noneで、同じくらいの期間をp=quarantineで過ごして結果を比べることを勧め、それでもそうしたドメインはrejectを公開すべきではないとしています。送信サービスが数個ある組織なら、たとえば次のように計画できます。

変更の前には、_dmarcのTXTレコードのTTLを、変更前のTTLの期間以上前もって300秒程度まで下げておきます。こうしておけば、元に戻すときもすぐにリゾルバーへ反映されます。変更は週の前半に行い、サポート担当に何に注意すべきかを伝え、公開した値を日付とともに記録しておきましょう。RFC 9989は、p=rejectを公開するドメインに対し、SPFだけに頼らず有効なDKIM署名をメールに付けることを求めています。rejectだけが正解というわけでもありません。社員がメーリングリストで使うドメインなら、しっかり監視したquarantineのほうが適している場合があります。一方、請求書や通知だけを送るドメインはrejectの有力な候補です。

8. 正規メールが失敗したとき：原因の特定、修正、切り戻し

いずれ、レポートや同僚からの連絡で正規のメールが失敗していると分かる日が来ます。集約レポートで該当する行を探すか、影響を受けたメールの全ヘッダーをもらってAuthentication-Resultsヘッダーを読み、次のパターンと照らし合わせてください。

失敗の規模が大きい場合や、領収書やパスワード再設定のような売上に関わるメールに影響している場合は、まず切り戻してから調べます。t=yとpct=0を加えるか、以前のポリシーに戻してください。TTLを短くしてあれば、変更は数分で大半のリゾルバーに届きます。5xxの拒否は恒久的なものなので、すでに拒否されたメールが後から配信されることはありません。影響を受けたチームに、どのメールを送り直すべきか伝えてください。そのうえで送信元を直し、数日分のレポートで成功を確かめてから、もう一度先へ進みます。ARC（RFC 8617）で認証結果を引き継ぐ転送サービスやメーリングリストは助けになりますが、RFC 9989はこの種の仕組みがまだ広くは使われていないと指摘しています。すべての送信元でDKIMを使うことが、今も確実な対処です。

9. 公開されているDMARCレコードの確認方法

DNSの管理画面の表示ではなく、実際に公開されている内容を確認します。

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

最初の2行はリゾルバーが返す内容を表示します。最後の行は権威DNSサーバーに直接問い合わせるので、キャッシュされた応答の期限が切れる前でも変更を確認できます。次の点を確かめてください。

• _dmarcにあるv=DMARC1で始まるTXTレコードがちょうど1つであること。2つあると受信側は両方を破棄し、DMARCレコードがないのと同じ扱いになります。
• v=DMARC1が最初のタグで、pの値がnone、quarantine、rejectのいずれかであること。
• ruaのメールボックスが存在し、別のドメインにある場合は_report._dmarcレコードで許可されていること。
• タグがセミコロンで区切られ、文書から貼り付けた全角の引用符や余計な文字が混ざっていないこと。

続いて、各サービスから自分で管理しているメールボックスにメールを送り、Authentication-Resultsヘッダーを読みます。Fromドメインとともにdmarc=passとあれば、それが受信側の判定で、最終的に意味を持つのはこの結果です。

外部から手早く確認したいときは、無料のSPF・DMARCレコードのチェッカーが、入力したホスト名そのものの_dmarcレコードを読みます。親ドメインにはさかのぼりません。レコードがない場合（ホストにMXレコードがあれば中）とp=none（監視モードとして低）を指摘し、quarantineとrejectではシグナルを出しません。レポートは読まず、sp、np、t、pct、rua、アライメントも評価しません。同じメールDNSのチェックはSPF、MTA-STS、CAAも読み、無料の公開準備スナップショットが行う8項目のパッシブなチェックの一つです。スナップショットは登録不要で、スコアと各チェックの結果を返します。継続的な見直しについてはDNSとメールの安全性の解説をご覧ください。