多くのDMARC導入プロジェクトで本当に問題になるのは、レコードの書き方ではなく、p=noneにどれだけ留まり、移行する前に何が満たされていなければならないかです。いつまでも待っているとドメインはなりすましに無防備なままで、早すぎる移行は自社の請求書を迷惑メールに送ってしまいます。このガイドでは、ステージごとの移行条件、サブドメインの扱い方、よくある問題、そしてロールバックの方法を紹介します。ここで挙げる基準値は当社のアドバイスであり、標準規格の一部ではありません。そのことは明記しています。
結論#
p=noneには、少なくとも1回分の送信サイクル留まります。通常は2〜4週間で、明細書など月次や四半期ごとのメールがある場合はそれより長くなります。把握しているすべての正規の送信元が、アライメントしたSPFまたはDKIMのチェックを通じてDMARCに成功したら、quarantineに移行します。quarantineでさらに一定期間、想定外のことが起きなければ、rejectに移行します。段階的な導入をpct=で計画してはいけません。現行のDMARC標準であるRFC 9989は、このタグを削除しました。RFC 9989は2026年5月に公開され、最初のDMARC仕様であるRFC 7489を廃止しています。レコード自体の基本はDMARC設定ガイドにあり、この記事では繰り返しません。
各ステージと、そこから抜けるタイミング#
以下の各ステージには、移行のためのテストがあります。表の数字はすべて当社が提案する目安です。実際に現実的な値は、送信量や送信元の構成によって変わります。
| ステージ | レコード | 移行テスト（当社のアドバイス） | 一般的な期間 |
|---|---|---|---|
| 1. 観察 | p=noneとrua= | レポートが1サイクル分をカバーし、実際に量を送るすべての送信元に担当者が決まっている | 2〜4週間 |
| 2. 修正 | p=none | 把握している正規の送信元がすべて、アライメントしたチェックを通じて2週間連続で成功している | 数日〜数か月 |
| 3. サブドメイン | 送信しない、または十分に把握しているサブドメインから先に適用する | それらのサブドメインで、正規のメールの失敗が2週間ない | 1〜2週間 |
| 4. Quarantine | p=quarantine | 2〜4週間、新たに失敗する正規の送信元がなく、メールが届かないという社員や顧客からの苦情もない | 2〜4週間 |
| 5. Reject | p=reject | 終わりではありません。レポートを読み続け、新しい送信元は利用開始前に確認します | 恒久 |
ステージが完了するのは、原因不明の失敗が小さく、取るに足らないものになったときです。たとえば、転送サービス、メーリングリスト、自社のものではないと特定できる送信元からの数通です。実際に量を送っている送信元がまだ特定できていないなら、ステージ2は終わっていません。特定するための手順は、DMARCレポートの読み方で説明しています。
スケジュール例#
表を具体的にするために、ESP、CRM、請求ツールを使っている企業の、現実的な一例を示します。あくまで例であり、約束ではありません。
- 1〜4週目：
p=noneを公開し、レポートを集め、すべての送信元を担当者とともに一覧にします。月末にしか送信しないものも含めます。 - 5〜8週目： 送信量の多いものから順に、送信元ごとにアライメントを修正します。最後にまとめてではなく、変更のたびにレポートを再確認します。
- 9週目： 使っていないドメインや送信しないドメインに適用します。
- 10〜13週目： メインのドメインを
quarantineに移し、毎週、新たに失敗する送信元がないかを確認します。 - 14週目以降： 直近1か月が落ち着いていれば
rejectに移行し、新しい送信元は利用開始前に認証を設定する、という常設のルールを加えます。
修正が遅れている送信元があれば、スケジュールはそれを待ちます。日付は計画で、移行テストがルールです。
pctの扱い#
pct=10、25、50、100のように段階を踏む古いアドバイスを見たことがあるなら、それは失敗したメールの一部にだけ厳しいポリシーを適用する方法でした。RFC 9989はこのタグを削除しています。その理由として、値が0か100でない限り、このタグは通常正確に適用されなかったことを挙げています。代わりにtタグが追加され、yは「テスト中」、n（デフォルト）は通常の扱いを表します。
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
t=yの場合、対応する受信側は、失敗したメッセージをポリシーの指定より1段階緩く扱うことになっています。quarantineはnoneに、rejectはquarantineになります。p=noneには影響しません。正直な注意点が2つあります。1つ目は、新しいタグへの対応が広まるには時間がかかるため、それに頼って身を守ろうとしないこと。2つ目は、パーセンテージによる段階導入は、この変更の前から、信頼できる安全網ではなかったことです。
リスクを抑える、より安全な方法は、パーセンテージではなく範囲で段階を分けることです。サブドメインと送信しないドメインから先に適用し、次にメインのドメイン、そしてrejectの前に数週間quarantineに留まります。現在のレコードにpct=が残っていても、急いで削除する必要はありませんが、それに依存する新しい段階導入は追加しないでください。
サブドメインと、何も送信しないドメイン#
最も手軽な成果は、メールを一切送らないドメインから得られます。使っていないドメインや廃止したブランドは、なりすましの格好の標的で、壊してしまう正規の送信元もありません。強制力のあるポリシーをすぐに公開し、何も許可しないSPFレコードも公開します。
parked.example.com. TXT "v=spf1 -all"
_dmarc.parked.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
parked.example.com._report._dmarc.example.com. TXT "v=DMARC1;"
3行目が承認レコードです。rua=のアドレスが、ポリシーが保護しているドメインとは別のドメインにあるため、受信側は、その別のドメインが<protected-domain>._report._dmarc.<report-domain>という名前のTXTレコードを公開している場合にだけ、レポートを送ります。これを省略するか、rua=のアドレスを使っていないドメイン自身に置くと、そのドメインのレポートは届きません。確認方法はレポートが届かない場合のガイドで説明しています。
送信を行うドメインのサブドメインには、サブドメインが独自のレコードを公開していない限り、親のポリシーが適用されます。sp=タグは、レコードを持たないサブドメインに別のポリシーを設定します。RFC 9989は、DNSに存在しないサブドメイン向けにnpタグも定義しており、でっち上げられたホスト名への対策に役立ちます。親にsp=rejectを設定するつもりなら、先に、送信を行う各サブドメインが成功していることを確認するか、サブドメインに独自のレコードを持たせてください。そもそもメールの種類ごとに専用のサブドメインを使うほうがよい理由は、送信用サブドメインのガイドで説明しています。
ポリシーを適用したときによく壊れるもの#
ポリシー適用に関するインシデントのほぼすべては、次のどれかに行き着きます。ポリシーを変更した後ではなく、ステージ1と2のうちに探してください。
- 誰も覚えていなかった送信元。 月に1回送信する、請求ツール、アンケートプラットフォーム、採用管理システムなどです。1サイクル分のレポートがあれば、その大半は見つかります。ステージ1を省略できないのはそのためです。
- テストではアライメントしていたのに、本番ではしていない。 サービスが、あるIPプールからの送信では成功し、別のIPプールでは失敗することがあります。各送信元は、実際の量を長期間にわたって見て判断してください。
- 転送サービスとメーリングリスト。 転送はSPFを壊し、メッセージを編集するリストはDKIMを壊します。完全に防ぐことはできません。小さな失敗率が残ることを想定し、それを許容できると事前に決めておきます。RFC 9989は、これについて明確です。
p=rejectを公開するドメインは、SPFだけに頼ってはならず、メールにDKIM署名をしなければなりません。また、ユーザーがメーリングリストに投稿するドメインは、そもそもp=rejectを公開すべきではありません。そのようなドメインには、結果を比較する前に、少なくとも1か月はp=none、続いて同じ期間はp=quarantineに置くことを勧めています。上で挙げた短めの期間は、主にシステムメールを送るドメインに合ったものです。社員が公開リストに投稿する場合は、長くしてください。 - ポリシー適用後に追加された新しいツール。 マーケティングチームが火曜日にあるプラットフォームに登録すると、そのメールが届かなくなり始めます。これはプロセスの問題です。新しい送信元は、使い始める前に認証を設定する、と取り決めてください。
- strictのアライメントが残っている。
adkim=sやaspf=sは、問題なく動いていたrelaxedの設定を、失敗に変えてしまいます。それぞれの原因は、アライメントのトラブルシューティングガイドで順に説明しています。
実際の数字で移行を見守る#
ステージ2から4の間に必要なのは、1つの画面です。送信元ごとに、そのメールのうちDMARCに成功した割合はどれだけか、今週新しく現れた送信元はどれか、を見られることです。QualisendのDMARCレポートは、それをドメインごとに7日、30日、90日の期間で表示します。また、SPFとDKIMの両方に失敗したメッセージが1日に10件以上あったドメイン、または失敗メッセージが5件以上の新しい送信元が現れたときは、その翌日にメールでお知らせします。「rejectへの準備ができた」というスコアはないため、判断はご自身で行います。正規の各送信元が100%に達し、その状態が続くことを確認してください。また、集計データは1〜2日遅れで、レポートを送る受信側しかカバーしないため、静かな週があっても、何も失敗しなかったという証拠にはなりません。
Qualisendのドメイン診断の監視では、ドメインの問題の一覧でp=noneが警告として表示され、pctが100未満の場合にも警告されます。複数のドメインを管理していて、まだ移行していないものを確認したいときに役立ちます。
ロールバック#
移行する前に、戻る方法を計画しておきましょう。次の3つの習慣で、ロールバックはすばやくできます。
- 以前のレコードの内容を変更メモに残す。 そうすれば、元に戻す作業はコピー＆ペーストで済みます。
- ポリシーを変更する1日ほど前に、
_dmarcレコードのTTLを数分に下げ、安定したら元に戻す。 受信側はDNSをキャッシュするため、TTLが長いと、自分のロールバックも遅くなります。 - 全部ではなく、1段階だけ戻す。
rejectで正規の送信元が失敗し始めたら、修正する間はquarantineに戻します。その間に拒否されたメッセージは、通常は送信者に返送され、受信側から回復することはできません。そのため、最初の適用期間は短くし、見守ることをおすすめします。
ポリシー適用と他の要件との関係#
組織ドメインでquarantineまたはrejectに到達することは、BIMIのロゴを使うための前提条件でもあります。標準が求める内容は、BIMIガイドにまとめています。それによって、GoogleとYahooの要件にあるその他の基本事項が不要になるわけではありません。認証がレピュテーションとどう結びつくかの全体像は、到達性ガイドにあります。
よくある質問
01p=noneには、どのくらい留まるべきですか？
少なくとも1回分の送信サイクルで、通常は2〜4週間です。明細書など月次や四半期ごとのメールがある場合は、それより長くなります。これは標準規格のルールではなく、当社のアドバイスです。本当のテストは日数ではなく、意味のある量を送るすべての送信元が特定され、担当者が決まり、アライメントしたSPFまたはDKIMのチェックを通じてDMARCに成功しているかどうかです。
02p=rejectに到達する必要がありますか？
Google、Yahoo、Microsoftの大量送信者向けのルールを満たすために必要ではありません。これらのルールが求めるのは、p=noneでもかまわない、公開されたDMARCポリシーです。rejectは、ドメインのなりすましを実際に止めるもので、BIMIなどの機能にはquarantineまたはrejectが必要です。レポートが裏付けるペースで進め、メールを一切送らないドメインには、すぐにポリシーを適用してください。
03pctを使って段階的に移行することはまだできますか？
2026年5月に公開され、RFC 7489を廃止したRFC 9989は、pctタグを削除しています。その理由として、通常は0か100でしか正確に適用されなかったことを挙げています。代わりに、テスト用のtタグが追加されました。受信側によって動作が異なるため、パーセンテージに頼る計画は立てないでください。代わりに、範囲で段階を分けます。メールを送らないドメイン、サブドメイン、メインのドメインの順で、quarantineで数週間過ごしてください。
04ポリシーを適用した後に、正規の送信元が失敗したらどうすればよいですか？
ポリシーを外すのではなく、rejectからquarantineのように1段階戻し、その送信元のDKIMまたはreturn-pathのアライメントを修正します。以前のレコードの内容をメモに残し、変更前にTTLを下げておけば、元に戻す作業がすぐに反映されます。その間に拒否されたメールは通常、送信者に返送されるため、最初の適用期間は短くし、見守ってください。
適用したDMARCポリシーは、そのメールが自分のものであることを証明しますが、質の悪いリストを良くすることはできません。無料プランの料金ページには、リストに対してフル検証を実行できる100クレジットが含まれています。守られたドメインでも、受信トレイに届くには健全なリストが必要です。
