DMARC Rollout Playbook: p=none to p=reject

Why teams get stuck at p=none

Publishing a DMARC record is easy. Getting to an enforcing policy — p=quarantine or p=reject — is where projects stall, sometimes for years. The fear is rational: tighten the policy too early and you start junking your own invoices, newsletters, or helpdesk replies.

The way through is not courage, it is evidence. You move forward only when your reports show that every legitimate source is authenticated and aligned. Done right, the day you flip to reject is a non-event.

Before you start

Three things separate a rollout that takes a month from one that drags for a year:

• A reporting address someone actually watches. Aggregate (rua=) reports are useless landing in an unmonitored inbox. Point them somewhere a person — or a tool — reads regularly.
• An inventory of your senders. Before you read a single report, list every system that sends mail as your domain: marketing platform, CRM, helpdesk, billing, payroll, internal apps. The reports will surface the ones you forgot, but starting from a list cuts Stage 2 down sharply.
• Access to your DNS. Every stage is a DNS change. If your records sit with a separate team or registrar, line that access up now so you are not blocked mid-rollout.

None of this is heavy lifting — it is the groundwork that keeps the project from stalling.

The four stages

Stage 1 — Monitor with p=none

Start in monitoring mode and turn on aggregate reporting:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none takes no action on failing mail, but receivers still send you daily reports. Leave this running until you have a complete picture of every system sending as your domain — typically two to four weeks. You will almost always discover senders you forgot about: a CRM, a ticketing tool, a payroll provider, a marketing platform.

Stage 2 — Authenticate every legitimate source

For each sender the reports reveal, fix authentication so it passes and aligns:

• Add the source to your SPF record (watch the 10-DNS-lookup limit — flatten or consolidate if you are close).
• Enable DKIM signing on the platform and publish its public key in DNS.
• Make sure the aligned domain matches your visible From: address.

This is the longest stage and the one that actually buys you protection. Do not rush it. The goal: every legitimate stream shows PASS in your aggregate reports, and the only failures left are genuinely unauthorized.

Stage 3 — Quarantine, tested first with t=y

Publish the quarantine policy in test mode first:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@yourdomain.com

With t=y, receivers treat the policy as one level lower, so failing mail is still delivered while your reports show what quarantine would catch. When the reports are clean, remove t=y. We recommend holding each policy for at least a month; RFC 9989 gives the same advice to domains whose users post to mailing lists.

The older approach, a pct=25, 50, 75, 100 ramp, came from RFC 7489. RFC 9989 removed pct= because receivers applied values other than 0 and 100 inconsistently.

Stage 4 — Reject

Once quarantine has run without surprises, test reject the same way (p=reject; t=y, which receivers treat as quarantine), then remove t=y:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@yourdomain.com

At reject, receivers refuse mail that fails DMARC, including messages that forge your exact domain. np=reject covers subdomains that do not exist, the names attackers invent.

One caution from RFC 9989 (section 7.4): p=reject can disrupt mailing lists and forwarders, and the RFC advises that domains whose users post to mailing lists should not publish it. Domains that do publish p=reject must DKIM-sign their mail rather than rely on SPF alone.

Things that trip people up

• The SPF 10-lookup limit. Every include: chains more lookups. Exceed ten and SPF returns permerror, which fails DMARC. Audit and flatten.
• Forwarded mail breaks SPF. Mailing lists and forwarders rewrite the path, so SPF fails, while DKIM usually survives unless the list modifies the message. This is exactly why you need both, and why DKIM alignment matters most.
• Subdomains. Existing subdomains inherit p= unless you set sp=. Subdomains that do not exist fall back to sp=, then p=, unless you set np=.
• Third-party platforms. Each one needs its own DKIM setup and SPF entry. The reports tell you which are misconfigured.

Make the reports readable

The biggest reason rollouts stall is not policy — it is that aggregate reports arrive as compressed XML, one file per receiver per day, from dozens of sources. Nobody can eyeball that. Teams publish p=none, the XML piles up unread, and the project quietly dies at Stage 1.

You have two options. Parse the XML yourself — a real engineering effort once you account for schema quirks, mapping sending IPs to organizations, and tracking trends over time — or point rua= at a service that turns it into a dashboard: who is sending as you, what is passing, and what will break when you tighten the policy. That visibility is the entire point of DMARC monitoring; it is what lets you advance on evidence instead of hope.

How to know when you are ready to advance

Do not advance on a calendar — advance on data. Before each step, your aggregate reports should show:

1. Every known legitimate source passing and aligned.
2. No unexplained PASS sources you cannot account for (could be a forgotten system — or an attacker you are about to start blocking).
3. A stable, well-understood sending footprint.

If you cannot yet read those reports confidently, start with Reading DMARC aggregate reports. And if you are doing this to meet Google and Yahoo's requirements, remember p=none satisfies the rule — but only reject actually protects your brand. Use the DMARC record generator to build a correctly formatted record for each stage.

After reject: keep watching

Reaching p=reject is the milestone, not the finish line. Your sending footprint keeps changing — a new marketing tool here, a migrated mail platform there — and each addition needs SPF and DKIM in place before it goes live, or it gets rejected along with the spoofers. Keep the aggregate reports flowing and keep reading them; a quiet report is a healthy one.

Most teams also publish a BIMI record at this point. Once you are enforcing at reject, you have met the precondition to display your logo in supporting inboxes — both a visible trust signal for recipients and a small payoff for the work. Enforcement is a posture you maintain, not a box you tick once. But the hard part — getting there without breaking mail — is behind you the moment your reports go quiet.