What is DMARC? Policy, alignment, and reports

DMARC — Domain-based Message Authentication, Reporting, and Conformance — is a DNS record that ties SPF and DKIM to the From: address people actually see, and tells receiving servers what to do with mail that fails: deliver it anyway (p=none), treat it as suspect (p=quarantine), or refuse it (p=reject). It also asks receivers to send you reports about the mail they saw — which is how you find out what is really sending as your domain.

DMARC was originally specified in RFC 7489 and is now a full internet standard under DMARCbis, RFC 9989 (what changed is covered in our DMARCbis guide). Existing records work unchanged under both.

The problem DMARC solves

Here is the uncomfortable fact about SPF and DKIM on their own: neither one checks the From: address a human reads.

SPF checks the envelope sender — an address used during mail delivery that recipients never see. DKIM proves a message came from whatever domain appears in its signature's d= tag — which can be any domain the sending service controls. So a message can pass SPF (on the sending service's bounce domain) and pass DKIM (signed with the sending service's domain) while displaying [email protected] in the From: header. Both checks pass; the mail is still a forgery of your domain.

DMARC closes this gap with one rule: an authentication pass only counts if the domain that passed matches the From: domain. That rule is called alignment, and it is the heart of the whole mechanism.

Alignment: the concept most guides get wrong

A message passes DMARC when at least one of these is true:

1. SPF passes, aligned — SPF passes, and the envelope-sender domain that passed matches the From: domain.
2. DKIM passes, aligned — a DKIM signature verifies, and its d= domain matches the From: domain.

One aligned pass is enough; DMARC does not require both. And an unaligned pass counts for nothing, no matter how valid it is.

A concrete example. Your ESP sends a campaign with From: [email protected]:

Check	Domain that passed	Aligned with example.com?
SPF	bounce.esp-example.com (the ESP's bounce domain)	No
DKIM	d=esp-example.com (the ESP's default signing)	No

SPF pass, DKIM pass — DMARC fail. Now flip the ESP's "custom signing domain" setting so it signs with d=example.com:

Check	Domain that passed	Aligned?
SPF	bounce.esp-example.com	No
DKIM	d=example.com	Yes

Same infrastructure, one setting changed — DMARC pass. Most real-world DMARC work is exactly this: not adding records, but making the passes you already have align.

Relaxed vs strict

By default alignment is relaxed: the domains must share the same organizational domain, so mail.example.com aligns with example.com. Strict alignment (adkim=s / aspf=s) demands an exact match. Relaxed is the right default for almost everyone; strict is a hardening step for domains that need it and know their mail flows precisely.

The record and the three policies

A DMARC record is a TXT record at the host _dmarc, and a starting record looks like this:

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

The p= tag is the policy — your instruction to receivers for mail that fails alignment:

Policy	What receivers actually do with failing mail
p=none	Deliver it normally. No enforcement at all — but reports still flow, which is the point. Monitoring mode.
p=quarantine	Treat it as suspicious — in practice, the spam folder rather than the inbox.
p=reject	Refuse it during delivery. The forgery never reaches a mailbox; the sender gets a bounce.

Two honest caveats. First, p=none protects nothing — a domain that stays there indefinitely has visibility, not security. Second, policies are requests: the vast majority of large receivers honor them, but receivers retain discretion at the margins (a quarantine may occasionally be delivered, a reject occasionally quarantined).

The other tags, briefly

• rua= — where to send aggregate reports (next section). If you publish only one optional tag, publish this one.
• sp= — a separate policy for subdomains. Without it, subdomains inherit p=.
• pct= — asked receivers to apply the policy to only a percentage of failing mail, e.g. pct=25. Useful for staged rollouts under RFC 7489, but inconsistently implemented — and DMARCbis removes it (its replacement is the t=y testing mode; see the DMARCbis guide).
• adkim= / aspf= — alignment mode, r (relaxed, the default) or s (strict), per mechanism.
• ruf= — an address for per-message failure reports. Few receivers send them, largely for privacy reasons; do not build a rollout on them.

Paste your record into the DMARC record checker to see every tag parsed and validated.

Aggregate reports: the rua= tag

Add rua=mailto:... and participating receivers — Google, Microsoft, Yahoo, and many others — will send that address a report, typically once a day, covering the mail they received claiming to be your domain. The reports are XML files (the format is standardized in RFC 9990), and each one lists, per sending IP: how many messages arrived, whether SPF and DKIM passed and aligned, and what the receiver did with the mail.

Aggregate reports contain counts and infrastructure data, not message contents — no subject lines, no bodies, no recipient addresses. What they give you is the complete outside view of your domain's mail: every server sending as you, legitimate or not, as seen by the receivers themselves. Raw XML is genuinely unpleasant to read at any volume, which is what DMARC monitoring exists to solve — but the data itself is the ground truth for every enforcement decision you will make.

Why jumping straight to p=reject is dangerous

The temptation is real: forgeries are hitting your customers today, and p=reject would stop them today. The problem is that p=reject stops everything that fails alignment — and until you have looked at the reports, you do not know what that includes.

Every organization has senders nobody remembers: the invoicing tool, the HR platform, the support desk, a scanner in an office somewhere. If they are not aligned when enforcement lands, their mail starts silently disappearing — and because DMARC failures generate no error the sender ever sees, you find out from angry colleagues, not from a log. Worse, these failures are invisible before enforcement too: at p=none everything is delivered, so nothing looks broken.

The rule: never tighten policy ahead of your evidence. The reports tell you when every legitimate source is aligned. Until they do, p=reject is a bet placed blind.

The staged path to enforcement

The safe rollout is a ladder, each rung held until the data supports the next:

1. p=none + rua= — turn on the reports. Fix what they surface: senders missing from SPF, DKIM signing that is valid but unaligned, services that need a custom signing domain.
2. p=quarantine with a low pct (for example pct=25) — enforcement touches a fraction of failing mail; a mistake sends some mail to spam folders, not into the void. Under DMARCbis, t=y on the target policy plays this staging role instead.
3. p=quarantine — full quarantine, once the partial step ran clean.
4. p=reject — the end state, once reports show every legitimate source aligned and unknown traffic is effectively zero.

How long each rung takes depends on volume and how many senders you run — weeks, typically, not days. What "the data supports it" means concretely — alignment rates per source, unknown-volume thresholds, a full observation window — is covered in the monitoring guide.

Getting started

If your domain has no DMARC record yet, the first step is the safest one on the ladder: p=none with a rua= address, which enforces nothing and starts the data flowing. The DMARC record generator builds that starting record, and the DMARC record checker validates one you already have. To see DMARC in context — alongside the SPF and DKIM it depends on — run a scan of your domain and start from what it finds.