What is DMARC? From p=none to p=reject

DMARC is the enforcement layer of email authentication. Here is the record, the reports, and a project plan with exit criteria for each stage.

DMARC is a single DNS TXT record that tells mailbox providers what to do with mail that claims your domain but fails authentication, and it is the only one of the three core email authentication protocols that enforces anything. SPF and DKIM produce pass/fail results; without DMARC, receivers treat those results as suggestions. With it, you publish the verdict in advance: deliver anyway, quarantine, or reject.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489, published 2015) is one leg of the trio we cover across our deliverability handbook. If SPF and DKIM are new to you, start with how the three records work as one system; this article assumes both are set up and goes deep on the enforcement layer.

What the record looks like

DMARC lives at the _dmarc label of your domain:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; sp=quarantine; adkim=r; aspf=r"

The tags that matter, in practice order:

Tag	Meaning	Notes
`v`	Version	Always `DMARC1`, must be first
`p`	Policy for the domain	`none`, `quarantine`, or `reject`
`rua`	Where aggregate reports go	A mailbox you actually monitor
`sp`	Policy for subdomains	Defaults to `p` if omitted
`pct`	Percent of failing mail the policy applies to	Staging tool; `pct=25` quarantines a quarter
`adkim` / `aspf`	Alignment mode	`r` (relaxed, subdomains count) or `s` (strict); relaxed is the default and the right choice for most senders
`ruf`	Failure (forensic) reports	Most large receivers no longer send these; do not build a plan around them

A minimal starting record is just three tags: v=DMARC1; p=none; rua=mailto:you@yourdomain.com.

What DMARC actually checks

DMARC passes a message when at least one of two things is true: SPF passed and the Return-Path domain aligns with the From domain, or DKIM passed and the signature's d= domain aligns with the From domain. Alignment is the whole point. It welds the hidden authentication identities to the address your reader sees, which is the address phishers forge.

One aligned pass is enough. A message that fails SPF outright (every forwarded message does) still passes DMARC on an intact DKIM signature. That redundancy is deliberate, and it is why you set up both before you enforce anything.

The DMARC policy levels, honestly

p=none is monitoring mode. Failing mail is delivered as if DMARC did not exist, but receivers send you reports. This is where everyone starts, and where a great many domains quietly stay forever. A permanent p=none protects nobody; it just watches.

p=quarantine sends failing mail to spam. Real consequences, but recoverable: a misconfigured legitimate sender lands in spam folders instead of vanishing, and someone eventually tells you.

p=reject refuses failing mail at the door. This is the goal state and the only policy that actually stops your domain being spoofed, because quarantined phishing can still be fished out of a spam folder by a curious reader. The cost: your mistakes become invisible. Rejected mail does not bounce to anyone you control, it is simply gone. We saw this from the receiving side in June 2026, when Gmail enforced sender policies against mail we were forwarding and silently refused 73% of it. No error reached us. Silence is exactly what rejection looks like, which is why you do not publish p=reject on hope.

Quarantine vs reject, in one rule

Quarantine while humans can still catch your mistakes; reject once the reports prove there are no mistakes left to catch. If your reports have been clean for a month, quarantine is just reject with extra steps and a worse spoofing story.

The road to p=reject: a project plan with exit criteria

The failure mode with DMARC is not technical, it is organizational: someone flips p=reject in an afternoon and the CRM, the invoicing tool, and the CEO's newsletter all stop delivering. Run it as four phases and do not leave a phase until its exit criteria hold.

Phase	Record	Exit criteria
1. Observe	`p=none` + `rua`	Two to four weeks of reports collected; every sending source in them identified as yours, a forwarder, or abuse
2. Authenticate	`p=none`	Every legitimate source passes SPF or DKIM with alignment in the reports; new vendors have a checklist item for authentication
3. Quarantine	`p=quarantine`, staged with `pct` if volume is high	Two to four consecutive clean weeks: no legitimate mail in spam, no missing-mail complaints from customers or staff
4. Reject	`p=reject`	Ongoing: reports reviewed monthly and whenever a new sending tool is added

Phase 2 is where the actual work lives. The reports will surface senders you forgot existed: the support desk, the survey tool, the office printer that emails scans. Each one either gets authenticated, replaced, or consciously cut off. Budget four to ten weeks for the whole run at a small company, longer if procurement owns your DNS.

Reading a DMARC report (rua)

Aggregate reports are XML files, usually zipped, mailed to your rua address by each receiver roughly daily. Gmail, Yahoo, and Microsoft all send them. A report contains no message content: it is rows of source IPs with counts and results. The heart of one looks like this:

<record>
  <row>
    <source_ip>203.0.113.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
    <spf><domain>bounce.mailer.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Read this one carefully, because it shows the distinction that confuses everyone. Under auth_results, SPF shows pass: the sending server was authorized for bounce.mailer.net, its Return-Path domain. Under policy_evaluated, SPF shows fail: that passing domain does not align with example.com, the From domain, so it counts for nothing. DKIM passed with an aligned domain, so the message passed DMARC. This is an ESP sending on your behalf with DKIM set up correctly and SPF alignment absent, which is normal and fine.

Read two or three reports raw so the structure sticks. Then stop. At any real volume you will receive dozens of files a day from different receivers, and the job is aggregation across weeks, not file reading. Use a parser: Postmark runs a free weekly digest service (still free as of mid-2026) that turns the XML into a readable email, and paid dashboards from the DMARC vendors add history and source labeling. There is no prize for hand-parsing XML.

What you are looking for in the aggregate: sources with volume that you cannot name, legitimate sources failing alignment, and, once you enforce, any disposition of quarantine or reject applied to mail that was actually yours.

What p=reject requires of you

Prerequisites, all of them, before the final flip:

DKIM signing on every legitimate sending source, with 2048-bit keys where your providers support them.
SPF covering every source, kept under the 10-lookup limit so it does not permerror into uselessness.
A subdomain decision: sp= inherits your policy to subdomains, so either authenticate mail from subdomains too or set their policy explicitly.
A monitored rua mailbox and a calendar habit of reading the digest, because vendors change IPs and colleagues add tools without telling you.
Four or more clean weeks at quarantine.

Publish p=none with a rua address this week; it is one TXT record and it costs you nothing. Then work the phase table. A domain that reaches p=reject with clean reports has done more for its deliverability than any warm-up trick, and it has made itself worthless to every phisher who tries to borrow its name.