What Is DMARC? Alignment, Policies and the 2026 RFCs
Summary
DMARC is a DNS TXT record that tells receiving servers what to do with mail that claims your domain but fails authentication, and where to send reports. It passes only when SPF or DKIM validates and the validated domain aligns with the visible From domain. Start at p=none with a rua address, fix unaligned senders, then move to quarantine and reject. The 2026 RFC 9989 revision replaces pct with t and adds np and psd.
What is DMARC? It is a DNS record that tells receiving mail servers what to do when a message claims your domain in the From header but fails authentication, and where to send reports about it. DMARC does not authenticate anything by itself. It checks that SPF or DKIM passed and that the domain they validated matches the domain the reader sees.
That match is called alignment, and it is the part most teams get wrong. A message can pass SPF, pass DKIM, and still fail DMARC.
DMARC is a policy layer on top of SPF and DKIM
SPF lists which IPs may send for a domain. DKIM signs the message so a receiver can verify it was not altered and that the signing domain approved it. Neither one looks at the From address a human reads.
DMARC closes that gap. It asks one question: does the domain in the visible From header align with the domain that passed SPF or DKIM? If yes, the message passes. If no, the receiver applies your policy.
The record lives at _dmarc.yourdomain.com as a TXT record. A minimal, valid one looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Three tags do the real work. p is the policy, rua is where aggregate reports go, and adkim / aspf set how strict alignment is. Everything else is optional.
Alignment is where good setups fail
SPF authenticates the envelope sender, the Return-Path domain. DKIM authenticates the domain in the d= tag of the signature. DMARC needs at least one of those to match the From domain, either exactly (strict) or at the organizational-domain level (relaxed, the default).
Here is the failure we see most often in traces. A team sends through a third-party provider, the provider signs with its own domain (d=provider-mail.net) and uses its own bounce domain. SPF passes, DKIM passes, and DMARC fails because neither domain matches example.com.
The fix is a custom sending domain: a DKIM key published under your domain, and ideally a custom return-path on a subdomain. Every serious provider supports it. Few enable it by default.
The three policies: none, quarantine, reject
The p tag has three values, and they are not a ladder you climb on a schedule.
p=none: the receiver delivers normally and sends you reports. Use it for the first 2 to 4 weeks, while you inventory senders.p=quarantine: the receiver routes failures to spam or junk. Use it once reports show all legitimate sources aligned.p=reject: the receiver refuses failures at the SMTP stage. Use it once quarantine has run clean for a full sending cycle.
p=none is monitoring, not protection. A domain sitting at none for two years has a compliance checkbox and no spoofing defence. Skip the temptation to leave it there because "nothing broke".
p=reject is the destination for any domain that only sends mail you control. Domains with heavy mailing-list traffic or legacy forwarders need more care, because forwarding often breaks SPF and can break DKIM if the intermediary edits the body.
Why the Gmail and Yahoo rules made this urgent
Since February 2024, Google's sender guidelines require anyone sending more than 5,000 messages per day to Gmail accounts to publish a DMARC record, with SPF and DKIM in place. The policy can be none. Google also asks bulk senders to keep the user-reported spam rate in Postmaster Tools below 0.30%, and recommends staying under 0.10%.
Yahoo's Sender Hub states the same core requirement: a valid DMARC policy of at least p=none, with the From domain aligned to either the SPF or DKIM domain. Relaxed alignment is acceptable.
Note what is and is not in those rules. The requirement is a published record and passing alignment, not enforcement. That is a floor. It is not a finish line.
Aggregate reports are the product, the policy is the switch
The rua address receives daily XML reports from every receiver that honours DMARC. Each report lists source IPs, message counts, the SPF and DKIM results, and whether alignment held. This is how you find the forgotten sender: the old CRM export, the billing tool a contractor wired up in 2022, the marketing form on a subdomain nobody owns.
Raw XML is unreadable at volume. Route rua to a mailbox a parser can ingest, or to a hosted DMARC reporting service, and look at the data grouped by source. What you want to see is every legitimate source showing 100% aligned, and everything else clearly unknown.
A practical rollout runs in this order:
Publish
p=nonewith aruaaddress.Collect two to four weeks of reports. Build the sender inventory.
Fix each legitimate unaligned source with a custom DKIM domain or return-path.
Move to
p=quarantine. Watch for support tickets about missing mail.Move to
p=rejectwhen quarantine shows no legitimate failures.
Ship each step separately. Changing the policy and adding a new sending provider in the same week makes any regression impossible to attribute.
DMARCbis changes the tags, not your record
In 2026 the IETF published RFC 9989, RFC 9990, and RFC 9991, which obsolete RFC 7489. RFC 9989 is the core DMARC spec. Aggregate reporting and failure reporting moved into their own documents.
The practical changes for a record owner are small:
pct,rf, andriare removed.t(testing mode) replacespctas an all-or-nothing switch:t=yreports without enforcing.npsets a policy for non-existent subdomains, which blocks spoofing of addresses likeabc123.example.com.psdmarks public suffix domains, and a DNS tree walk replaces the old Public Suffix List lookup.
Existing v=DMARC1 records stay valid. Nothing breaks if you change nothing today. Provider support for the new tags will roll out unevenly, so a new tag that seems to do nothing usually means the receiver has not implemented it yet.
The np tag is the one worth adopting early. Setting np=reject while p is still none shuts the fake-subdomain abuse path without committing the rest of your mail to enforcement.
Subdomains, and why the default inherits
A DMARC record on the organizational domain applies to subdomains too, unless you override it with sp. That inheritance is useful and also a trap.
If marketing sends from news.example.com through a separate provider, it inherits the parent policy. Move the parent to p=reject before that provider has aligned DKIM and the newsletter goes to the floor. Publish a separate _dmarc.news.example.com record when a subdomain has its own sender fleet and its own rollout pace.
A cleaner architecture separates streams by subdomain from the start. Transactional mail on one, lifecycle on another, human mail on the root. Each gets its own DKIM keys, its own reputation, and its own DMARC record.
Read the Authentication-Results header before you guess
When a message fails, the receiving server records why. In Gmail, "Show original" exposes the Authentication-Results header, and it tells you more than any dashboard.
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounce.provider-mail.net;
dkim=pass header.d=provider-mail.net;
dmarc=fail (p=NONE) header.from=example.comRead it left to right. SPF passed for bounce.provider-mail.net. DKIM passed for provider-mail.net. DMARC failed because the From header says example.com and neither passing domain matches it.
The (p=NONE) note shows the policy the receiver saw. At none this message was delivered anyway. At reject it would have bounced with a 5.7.x error, and the sender would have found out from a customer.
Two checks catch most of these cases. Confirm the header.d value in the DKIM result is your domain. Then confirm the smtp.mailfrom domain is your domain or a subdomain of it.
SPF has a lookup limit that DMARC exposes
SPF allows ten DNS lookups per evaluation. Every include: for a provider spends some of them, and nested includes spend more. Cross ten and SPF returns a permanent error, which counts as a fail.
Teams with five or six sending tools hit this without noticing, because SPF failures were invisible before DMARC reporting. Once rua reports arrive, the pattern is obvious: one source suddenly failing SPF across all receivers on the day someone added another include:.
This is one more reason to rely on DKIM alignment as the primary path. DKIM survives most forwarding, has no lookup budget, and is tied to the message rather than the connecting IP. Keep SPF valid, but do not build your DMARC pass on it alone.
What DMARC will not do
DMARC prevents exact-domain spoofing. It does not stop lookalike domains (examp1e.com), it does not judge content, and it does not fix a bad sender reputation. A perfectly aligned domain that sends to purchased lists still lands in spam.
It also does not replace monitoring. Alignment can break silently: a DNS change removes a DKIM selector, a provider rotates keys, a new tool starts sending without your knowledge. Reports are how you find out before your users do.
Treat the DMARC record like any other piece of production config. It belongs in version control, changes go through review, and the rua mailbox needs an owner.
Before you publish the record
Run through this once. It takes under an hour for a single domain.
List every system that sends mail as your domain: product, billing, support desk, CRM, marketing, calendar invites.
Confirm each one signs DKIM with your domain, not the vendor's.
Set a custom return-path where the provider allows it.
Choose a
ruadestination someone will read.Start at
p=none, and put the date you plan to review it on the calendar.Check spam rate in Google Postmaster Tools weekly during the rollout.
Where to go from here
If you have never looked at your reports, publish p=none with a rua address today and read what comes back in two weeks. The first report almost always names at least one sender nobody remembered. The next concrete step is deciding which of those you keep.