「記録はあるのに守られていない」状態から、正規メールを止めずに拒否ポリシーへ移行する手順です。
最終更新: 2026年6月
DMARC を p=none で公開しただけでは、なりすましメールは拒否されません。p=none は「認証結果の記録（レポート）を集めるだけ」の監視モードだからです。多くのドメインがここで止まってしまい、設定した安心感だけがあって実際には守られていない、という状態に陥っています。守るには quarantine、最終的には reject まで引き上げる必要があります。
注意が必要なのは、自社のメールには見落としがちな送信元が多いという点です。基幹のメールだけでなく、メルマガ配信サービス、CRM、問い合わせフォーム、請求・予約システムなど、複数のツールがあなたのドメインを名乗ってメールを送っています。これらの認証設定が整わないまま p=reject にすると、正規のメールまで拒否されて届かなくなります。だからこそ、段階を踏んで移行します。
まず p=none で公開し、DMARC の集計レポート（rua）を受け取ります。これにより「実際に誰が・どのサービスがあなたのドメインを名乗って送っているか」を把握できます。正規・不正の両方が見えるのがポイントです。
レポートで見えた正規の送信サービスについて、SPF と DKIM が正しく合格し、かつ差出人ドメインと整合（アライメント）が取れている状態を整えます。ここが移行のいちばんの作業量です。
正規メールが合格する見込みが立ったら、p=quarantine に上げます。最初は pct（適用率）を低めに設定して一部のメールだけに適用し、問題がなければ徐々に100%へ引き上げると、影響を抑えながら移行できます。
quarantine で正規メールに問題が出ないことを確認できたら、p=reject に上げます。これでなりすましメールは受信側で拒否され、最も保護された状態になります。
移行作業で最も多い事故が、SPF の DNS ルックアップ上限超過です。SPF は1回の検証で参照できる DNS が10回までと決まっており、これを超えると SPF 全体が無効（permerror）になります。送信サービスを表す include は内部で複数回参照することが多く、ツールを数個追加しただけで上限に達します。「設定したのに、ある日ツールを1つ足したらメールが届かなくなった」という形で表面化するのが典型です。移行前後で、SPF が上限内に収まっているか必ず確認してください。
ステップ1で集まる DMARC の集計レポートは、人が読む文章ではなく、圧縮された XML データが毎日届くものです。そのままでは「誰が正規で、誰がなりすましか」を読み解くのは困難で、ここで移行が止まってしまうケースが少なくありません。レポートを可視化し、正規の送信元を整理しながら安全にポリシーを上げていく工程こそ、移行の本質的な難所です。
Stuck at p=none? Here's how to reach a reject policy without disrupting legitimate mail delivery.
Last updated: June 2026
Publishing DMARC with p=none does not block spoofed mail. p=none is monitoring mode — it collects data but takes no action. Many domains get stuck here, creating a false sense of security: the DMARC record exists, but spoofed mail still reaches recipients. To actually protect your domain, you need to reach quarantine and ultimately reject.
The problem is that more services send mail as your domain than most people realize. Beyond your primary mail server, newsletter platforms, CRMs, contact forms, invoicing systems, and booking tools may all be sending on your behalf. If their authentication isn't correctly configured and you flip to p=reject, legitimate mail from those services will be rejected and won't arrive. This is why migration must be done in stages.
Start with p=none and configure an aggregate report address (rua). This reveals every service sending mail as your domain — both legitimate sources and potential spoofing attempts.
For each legitimate sending service identified in the reports, ensure SPF and DKIM both pass and that the From header domain aligns with the authenticated domain. This is the most labor-intensive step.
Once your legitimate senders are passing, move to p=quarantine. Start with a low pct (percentage) value to apply the policy to only a fraction of mail, then increase toward 100% as you confirm no legitimate mail is affected.
Once quarantine is running at 100% with no impact on legitimate mail, move to p=reject. Spoofed mail will be rejected by receivers. Your domain is now fully protected.
The most common migration accident is exceeding SPF's DNS lookup limit. RFC 7208 allows at most 10 DNS lookups per SPF check. Each include (a sending service) often consumes multiple lookups internally, so adding a handful of senders is enough to exceed the limit. When you do, SPF becomes permerror — the entire SPF record is invalidated and even legitimate mail can stop arriving. The classic failure mode: "Everything was fine until I added one more service." Always verify your lookup count before and after any changes.
The DMARC aggregate reports you collect in Step 1 are compressed XML files delivered daily — not human-readable text. Figuring out which sources are legitimate and which are spoofed requires tooling to parse and visualize them. This is where most migrations stall. Getting past this wall — identifying all your real senders and cleaning up their authentication — is the core challenge of the migration.
Check whether your domain is stuck at p=none and whether your SPF is within the lookup limit. Free, no sign-up required.