DMARC Explained: Policies, Reports, and Setup

DMARC is the layer that ties SPF and DKIM together: it tells receiving servers what to do when a message claiming to be from your domain fails both checks, and it asks those servers to send you reports about every source mailing as you. Without it, SPF and DKIM each pass or fail in isolation and nobody is instructed to act on the result. If you want the full picture of how the three protocols fit, start with Email authentication explained.

The standard is defined in RFC 7489, which describes Domain-based Message Authentication, Reporting, and Conformance. Three ideas matter most, and they map cleanly onto the name. There is a policy (what receivers should do with failures), there is alignment (the rule that decides whether a pass actually counts for your visible domain), and there is reporting (the feedback loop that shows you who is sending). The pillar guide, Email authentication explained, walks through the prerequisites if you have not set up SPF or DKIM yet.

The _dmarc TXT record

You publish DMARC as a single TXT record at the hostname _dmarc under your domain. A starter record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Each semicolon-separated piece is a tag. The table below covers the ones you will actually use.

Tag	Meaning
v	Protocol version; must be DMARC1 and must come first
p	Policy for the organizational domain: none, quarantine, or reject
sp	Policy for subdomains; falls back to p if omitted
rua	Address for aggregate reports (the daily XML summaries)
ruf	Address for forensic or failure reports (per-message detail)
pct	Percentage of failing mail the policy applies to (1 to 100)
adkim	DKIM alignment mode: r relaxed (default) or s strict
aspf	SPF alignment mode: r relaxed (default) or s strict
fo	Forensic reporting options that control when ruf reports fire

Why alignment is the whole game

A message can pass SPF and still fail DMARC. That surprises people, so it is worth being precise. SPF, defined in RFC 7208, authenticates the envelope sender (the bounce address), not the From header your recipient reads. DKIM, defined in RFC 6376, signs the message with a domain named in the signature. DMARC only treats either result as a success if the authenticated domain aligns with the From domain.

Relaxed alignment, the default, accepts any subdomain of the same organizational domain. So a DKIM signature from mail.yourdomain.example aligns with a From address at yourdomain.example. Strict alignment requires the two to be identical, character for character. Most senders want relaxed; strict only makes sense when you control every signing host and want to lock things down hard. Because DMARC passes if either SPF or DKIM aligns, DKIM tends to be the more durable of the two, since it survives forwarding that breaks SPF.

Aggregate reports versus forensic reports

The rua and ruf tags drive two very different feedback streams.

Aggregate reports (rua) arrive roughly once a day as XML files from each receiving provider. They do not contain message content. Instead they summarize how many messages came from each sending IP, whether SPF and DKIM passed, and whether alignment held. This is where you discover the legitimate third-party services you forgot about (your CRM, your invoicing tool, your help desk) and the spoofers you never knew about. Read these before changing anything.

Forensic reports (ruf) are per-message and can include headers or redacted content from individual failures. They are useful for debugging a specific problem, but many providers do not send them at all because of privacy concerns, and the ones that do can flood you. Most teams run on aggregate reports alone.

A safe rollout you will not regret

Resist the urge to publish p=reject on day one. You will block mail you depend on before you have any idea where it comes from. The sane path is staged:

1. none publishes the record and starts the reports flowing while changing nothing about delivery. Sit here until the reports look clean, usually a couple of weeks.
2. quarantine tells receivers to treat failures as suspicious, typically routing them to spam. Use pct to ramp gradually, for example p=quarantine; pct=25.
3. reject instructs receivers to refuse failing mail outright. Move here only once aggregate reports show your real senders passing consistently.

The sibling guide DMARC policies: none, quarantine, reject goes deep on each value and the progression between them. If your DKIM setup is shaky, fix that first with DKIM explained, since a strong DKIM signature is what keeps DMARC passing through mailing lists and forwarders.

Want to see your current DMARC, SPF, and DKIM records side by side? Check any domain's published records free at domainintel.app and see exactly where you stand before you tighten the policy.