DMARC Rollout: From p=none to quarantine to reject, Safely

Publishing a DMARC record is easy. Moving it to p=reject without blocking your own invoices, newsletters and CRM mail is the hard part, and it is mostly an inventory exercise: find every system that sends as your domain, make each one pass SPF or DKIM with alignment, and only then tighten the policy. This guide is the staged plan. If you need the basics of SPF, DKIM and DMARC first, read the complete authentication guide.

What the policy values actually do

DMARC is a TXT record at _dmarc.<domain>. The p= tag tells receivers what to do with mail that fails DMARC:

A message passes DMARC when either SPF or DKIM passes and the passing domain aligns with the domain in the visible From: header. Alignment is where most rollouts stall. SPF aligns when the envelope sender (return-path) domain matches the From domain; DKIM aligns when the d= domain in the signature matches. Under the default relaxed mode, a subdomain and its organizational domain count as a match (bounce.example.com aligns with example.com). Under strict mode (aspf=s, adkim=s) they must be identical.

Receivers treat your policy as a request, not a command, and local rules and forwarding handling can still override it. Still, Gmail, Yahoo and others act on it often enough that p=reject meaningfully stops direct spoofing.

Stage 0: Before you publish anything

Make a list of every system that sends mail with your domain in the From address:

• Your mailbox platform (see the Google Workspace or Microsoft 365 records)
• Website and application mail (password resets, receipts)
• Newsletter and marketing tools
• CRM, helpdesk, billing, HR and survey tools
• Printers, scanners, monitoring systems and cron jobs that email via an SMTP relay

Ask each team. Reports will find the rest, but the list tells you what you expect to see.

Stage 1: Publish p=none with reporting

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

• rua= is where aggregate reports (daily XML summaries) are sent. This is the tag you actually need.
• ruf= requests per-message failure reports. Many large receivers do not send them, for privacy reasons, so do not depend on it.
• fo=1 asks for failure reports when any mechanism fails, if a receiver sends them at all.

If the report mailbox is on a different domain from the one being protected, the receiving domain must publish an authorization record, or compliant receivers will not deliver reports there:

example.com._report._dmarc.reports.example.net.  IN  TXT  "v=DMARC1"

Aggregate reports are compressed XML. Raw XML is unpleasant to read at any volume, so most people point rua at a report-processing service or a script that summarizes by sending source IP, volume, SPF/DKIM result and alignment. Whichever you choose, check what it does with the data. Reports reveal your sending infrastructure.

Generate a valid record with the SPF & DMARC Generator and confirm it parses with the Email DNS Checker.

Stage 2: Read the reports and fix alignment

For each source IP or sending service in the reports, sort into one of three buckets:

1. Legitimate and passing aligned. Nothing to do.
2. Legitimate but failing. Fix it (below).
3. Unknown or hostile. Leave it failing. That is the point of DMARC.

Common reasons a legitimate sender fails:

• SPF passes but is unaligned. The service uses its own return-path domain, so SPF passes for their domain, not yours. Fix by enabling the service's custom return-path/bounce domain (often a CNAME on bounce.example.com) or, more reliably, by turning on DKIM.
• DKIM not set up. Many tools sign with their own domain by default. Publish the DKIM records the tool gives you so that d=example.com. Detail in the DKIM setup guide.
• SPF record broken. Over ten lookups gives a permerror; see fixing too many DNS lookups. Use the SPF Record Checker.
• Forwarding. Forwarders break SPF because their IP is not in your record. DKIM usually survives forwarding, which is why DKIM alignment is the robust path. Mailing lists that alter the body or subject can break DKIM too; ARC may help receivers trust those messages, but it is the receiver's call.

Prefer DKIM alignment for every sender, with SPF as a backup. Fix one sender at a time, then re-read the next week's reports.

Stage 3: Quarantine, ramped with pct

When the legitimate sources pass consistently, move to enforcement gradually using pct, the percentage of failing mail the policy applies to:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

A sensible ramp is 10, then 25, 50, and 100, waiting several days at each step and reading reports in between. Mail that falls outside the pct sample is handled at the next-lower policy (quarantine falls back to none).

Two caveats. First, receivers differ in how faithfully they sample, so treat pct as a seatbelt rather than a precise dial. Second, the newer DMARC specification work replaces pct with a simpler testing flag, so check current standards if you are reading this later and your tooling flags the tag. For now, pct is widely understood.

Watch for real-world signals during this stage: a spike in "my mail went to spam" reports from colleagues or customers, bounces mentioning DMARC (see bounce codes explained), and new failing sources in reports.

Stage 4: Reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Moving through quarantine at 100% first, for a couple of weeks, is a more forgiving path than jumping straight to reject. Once at p=reject, keep the rua tag. A new SaaS tool added by a colleague next year will fail quietly, and the reports are how you find out.

Subdomain policy with sp=

By default, a subdomain without its own DMARC record inherits the parent's p= policy. The sp= tag lets you set a different policy for subdomains:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

Typical patterns:

• Parent p=reject, sp=reject: strongest, and stops attackers inventing billing.example.com.
• Parent p=reject, sp=none: a temporary compromise if subdomains host unfinished senders. Plan to remove it.
• A subdomain with its own record: publish _dmarc.news.example.com to give a marketing subdomain a looser policy while the apex stays strict.

Domains that send no email at all should say so: an SPF of v=spf1 -all, a null MX (see MX records explained), and a DMARC p=reject. Parked domains are a favorite for spoofing.

Alignment modes: adkim and aspf

"v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc-reports@example.com"

r (relaxed) is the default and what you want almost always. Strict mode breaks setups where one subdomain sends on behalf of another, in exchange for little extra protection. Use it only with a clear reason.

Why bother: external pressure

Google and Yahoo introduced requirements in 2024 for bulk senders, including having at least a DMARC record in place, and other providers have signalled similar expectations. Check the providers' current sender guidelines for exact thresholds. Separately, BIMI logos in inboxes require enforcement (see BIMI explained).

Rollout checklist

1. Inventory every sender.
2. Publish p=none with rua.
3. Collect two to four weeks of reports.
4. Get DKIM aligned for every legitimate sender.
5. Move to p=quarantine; pct=10, then ramp to 100.
6. Move to p=reject.
7. Decide on sp= and protect non-sending domains.
8. Keep reports flowing forever.

Next steps

• Draft your record with the SPF & DMARC Generator.
• Validate what is live with the Email DNS Checker and the SPF Record Checker.
• Send a real test message through the Email Deliverability Test and read the authentication results.
• Learn how to add signing in DKIM setup and troubleshooting.

FAQ

How long should I stay at p=none?

Long enough to see every recurring sender, which is usually two to four weeks and longer if you send quarterly or annual mail. There is no penalty for taking more time, only for rushing.

Will p=reject stop all spoofing of my domain?

It stops exact-domain spoofing at receivers that honor it. It does not stop lookalike domains such as examp1e.com or display-name tricks.

Do I need ruf reports?

No. Aggregate reports (rua) contain what you need, and many receivers do not send failure reports at all.

My legitimate mail fails only when forwarded. Is that a problem?

It is expected: forwarding breaks SPF. If DKIM is signed and aligned, the message can still pass DMARC. This is another reason to set up DKIM everywhere.

Can I set p=reject on a domain that never sends mail?

Yes, and you should. Pair it with v=spf1 -all and a null MX so the domain cannot be used for spoofing.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.