DMARC from p=none to p=reject without breaking mail

DMARC from p=none to p=reject without breaking mail

By James Bayliss · Updated · Reviewed

In this guide
  1. What DMARC does
  2. The record, tag by tag
  3. The rollout plan
  4. Subdomains and lookalikes
  5. Common mistakes
  6. Check your record
  7. Sources

What DMARC does

DMARC ties authentication to the address people actually see. A message passes DMARC when either:

  • SPF passes and the envelope (Return-Path) domain aligns with the From: domain, or
  • DKIM passes and the signing domain (d=) aligns with the From: domain.

If neither is true, the receiver applies your published policy: none (deliver as normal), quarantine (treat as suspicious, usually the spam folder) or reject (refuse it). The policy lives in a TXT record at _dmarc.<your-domain>.

DMARC was originally published as RFC 7489. In May 2026 it was replaced by RFC 9989 (the "DMARCbis" update), with reporting split into RFCs 9990 and 9991. The record still starts with v=DMARC1, and existing records keep working. The changes that affect a rollout are covered below.

The record, tag by tag

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"
TagPurposeNotes
v=DMARC1VersionRequired, first
p=Policy for the domainnone, quarantine, reject
sp=Policy for existing subdomainsDefaults to p
np=Policy for non-existent subdomainsNew in RFC 9989; defaults to sp, then p
rua=Where aggregate (daily XML) reports goEssential
ruf=Where failure reports goFew receivers send them, for privacy reasons
adkim=, aspf=Alignment mode: r relaxed (default) or s strictLeave at relaxed unless you have a reason
t=yTest mode (RFC 9989): asks receivers to apply one level less than the policyReplaces most uses of pct
pct=Percentage to apply the policy toRemoved in RFC 9989; older receivers may still honour it

If the reports should go to a mailbox at a different domain, that domain must publish a record authorising it, for example example.com._report._dmarc.reports-vendor.example. Report services set this up for you.

The rollout plan

Stage 1: Monitor (2 to 6 weeks)

Publish p=none with rua=. Nothing changes for delivery, but you start receiving aggregate reports from Gmail, Yahoo, Microsoft and others, listing every IP that sent mail claiming your domain, and whether it passed SPF, DKIM and alignment.

Raw reports are XML and arrive daily per receiver. Use a report-processing service or an open-source parser; reading them by hand doesn't scale beyond a tiny domain.

Note that Gmail, Yahoo and Microsoft already require at least p=none from bulk senders. See the sender requirements guide.

Stage 2: Fix every legitimate source

Sort report sources into three groups:

  1. Passing and aligned. Your main mail platform should be here once SPF and DKIM are set up.
  2. Legitimate but failing. Typical cases are a marketing tool signing with its own domain, a help desk sending through its default return-path, and a copier relaying through an unauthenticated server. For each one, configure custom-domain DKIM (preferred) or a custom return-path covered by SPF.
  3. Not yours. Spoofing, or forwarding. This is exactly what enforcement will stop.

Repeat until group 2 is empty for at least two weeks of reports. Pay attention to senders that only send monthly or quarterly, such as invoicing runs and annual reminders.

Stage 3: Quarantine

Change to p=quarantine. If your receivers support RFC 9989, t=y lets you test first: receivers apply one level less than your policy (quarantine becomes none). Keep watching reports. Anything legitimate that still fails will now land in spam, and users tend to notice within days.

Stay here for 2 to 4 weeks.

Stage 4: Reject

Change to p=reject. Spoofed mail using your exact domain is now refused by receivers that honour DMARC. Keep rua= forever: reports are how you'll learn when a new tool is added without authentication.

Subdomains and lookalikes

  • Existing subdomains inherit p unless you set sp. Setting sp=none while p=reject leaves every subdomain open to spoofing; avoid it unless a subdomain genuinely can't comply yet.
  • Non-existent subdomains, such as payroll.example.com when nothing exists there, are a favourite for phishing. RFC 9989's np=reject covers them explicitly.
  • Lookalike domains (examp1e.com) are outside DMARC's reach. They need monitoring and registration, not DNS records.

Common mistakes

  • Jumping straight to p=reject. The first sign of a missed sender is often a lost invoice or password-reset email.
  • No rua=. Without reports, you're enforcing blind.
  • Two DMARC records. Receivers then ignore DMARC entirely.
  • Relying on SPF alone. SPF breaks when mail is forwarded; aligned DKIM survives. Make sure every source signs.
  • Publishing at the wrong name. The record goes at _dmarc.example.com, not at example.com.
  • Forgetting parked domains. Domains that send no mail should publish v=DMARC1; p=reject; together with v=spf1 -all.

From the field: DMARC is the policy you present that you want the recipient to follow if SPF (authorized server) or DKIM (authorized message) fail their checks. If you have it set to reject and no mail is going through, it is better to drop to quarantine than none. With quarantine, you still have protection for your domain's reputation still in place while you troubleshoot.

Check your record

The Email Record Lookup parses your DMARC record and flags a missing rua, monitoring-only policies, exempt subdomains and duplicate records. To see why a particular message failed, compare its Return-Path and DKIM d= with the From: domain; the alignment guide walks through it.

Sources

Check it now

Email Record Lookup Is this domain's email set up correctly: MX, DMARC, DKIM and SPF?

Related guides