DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a TXT record at _dmarc.yourdomain.com. It tells receiving servers what to do with mail that shows your domain in the From header but fails both aligned SPF and aligned DKIM: deliver, spam folder, or reject. It also asks for reports. RFC 7489 defined it in 2015.
Here is a real one, read from DNS on 19 October 2026:
_dmarc.google.com. TXT "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
Translated: this is a DMARC record, reject mail that fails, and send daily summaries to that mailbox. The rest of this page explains how a receiver gets from a message to that decision.
The problem DMARC solves
SMTP lets any server put any address in the From header. SPF and DKIM were built to authenticate mail, but neither one checks the address a person sees.
- SPF (RFC 7208) checks the envelope sender, the hidden
MAIL FROMaddress used for bounces. A phisher can pass SPF forbounce.attacker.netwhile the From header saysceo@yourbank.com. - DKIM (RFC 6376) checks a signature from whichever domain is named in
d=. The attacker can sign asd=attacker.netand pass.
DMARC adds the missing link. It requires the domain that passed SPF or DKIM to match the domain in the visible From header. That match is called alignment.
How a receiver evaluates DMARC
When a message arrives, a receiver that supports DMARC runs roughly these steps (RFC 7489 section 6.6):
- Take the domain from the From header, say
news.example.com. - Look up
_dmarc.news.example.com. If there is nothing, look up_dmarc.example.com, the organisational domain. - Run SPF on the envelope sender and DKIM on each signature.
- Check alignment: did SPF pass for a domain that matches the From domain? Did any DKIM signature pass with a
d=that matches? - If at least one aligned pass exists, DMARC passes. If neither, DMARC fails and the receiver applies the policy (
p=for the domain,sp=for subdomains). - Record the result for the aggregate report it sends later to the
ruaaddress.
One aligned pass is enough. You do not need both SPF and DKIM to align, which matters because SPF breaks on forwarding and DKIM breaks when a mailing list edits the message. Having both gives you a second chance.
Alignment: relaxed, strict and the organisational domain
Alignment compares the From domain with the authenticated domain. DMARC has two modes, set by adkim for DKIM and aspf for SPF. Both default to relaxed.
- Relaxed (
r): the two domains share the same organisational domain.mail.example.comaligns withexample.com. - Strict (
s): the two domains are identical.
| From header | Authenticated domain | Relaxed | Strict |
|---|---|---|---|
example.com |
DKIM d=example.com |
Aligned | Aligned |
example.com |
DKIM d=mail.example.com |
Aligned | Not aligned |
news.example.com |
SPF bounce.example.com |
Aligned | Not aligned |
example.com |
DKIM d=esp-mailer.net |
Not aligned | Not aligned |
The organisational domain is roughly the domain you registered. RFC 7489 finds it with a public suffix list: for news.example.co.uk it is example.co.uk, because co.uk is a public suffix. RFC 9989 replaces the list with a "DNS Tree Walk" that queries _dmarc at each level up the name, capped at eight queries, and lets a domain mark itself with psd=n or psd=y.
The last row of the table is the common failure. Many email platforms send with their own bounce domain and sign with their own d= until you set up a custom domain. SPF and DKIM both pass, and DMARC still fails. The fix is per sender: publish the platform's DKIM key under your domain, and use a custom return-path where the platform offers one.
The three policies
| Policy | What you ask for | Typical receiver behaviour |
|---|---|---|
p=none |
No action | Mail delivered as normal; you get reports |
p=quarantine |
Treat failing mail as suspicious | Spam or junk folder |
p=reject |
Reject failing mail | Refused during the SMTP session |
The policy is a request. Receivers decide. Microsoft's DMARC documentation says of quarantine that a message "might be quarantined as spam, delivered to the Junk Email folder, or delivered to the Inbox with an identifier added". It also notes that outbound Microsoft 365 mail failing DMARC at a destination is routed through its high-risk delivery pool when your policy is quarantine or reject.
Two more tags shape the policy. sp sets the policy for subdomains and defaults to p. np, added by RFC 9989, sets the policy for subdomains that do not exist in DNS, which is where phishers like to invent names such as secure-login.example.com.
DMARC reports: rua and ruf
Reporting is the part that makes DMARC usable.
Aggregate reports (rua) are XML files, usually gzipped, sent once a day by each receiver that saw your mail. Each row gives a source IP, a message count, the SPF and DKIM results and domains, and what the receiver did. They contain no message content. This is how you find the CRM, the billing system and the forgotten printer that send as your domain. The format now has its own standard, RFC 9990. You can open the files in the DMARC report analyzer, which parses them in your browser.
Failure reports (ruf) describe single failing messages and can include headers or content. RFC 9991 covers them. Because they can carry personal data, most teams work from aggregate data and treat failure reports as an extra.
If the report address is on another organisation's domain, that domain has to publish an authorisation record at yourdomain._report._dmarc.theirdomain. The record syntax guide shows how to check one.
A real record, tag by tag
Cloudflare's record, read on 19 October 2026:
v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; pct=100;
rua=mailto:a1c47f179bc04efd8ee4dcd4d85dfc65@dmarc-reports.cloudflare.net,mailto:rua@cloudflare.com
v=DMARC1marks it as DMARC. It must come first.p=rejectasks receivers to refuse failing mail fromcloudflare.com.sp=rejectapplies the same to every subdomain. Without it, subdomains would inheritpanyway; writing it out makes the intent explicit.adkim=r; aspf=rsets relaxed alignment, which is the default.pct=100applies the policy to all failing mail, also the default.rua=lists two report addresses. The first is oncloudflare.net, a different organisational domain, so receivers checkcloudflare.com._report._dmarc.dmarc-reports.cloudflare.net. It returnsv=DMARC1;, so both addresses get reports.
Cloudflare's SPF record ends in -all and lists Google, Mailchimp, Mandrill, Zendesk and Salesforce includes. Each of those senders also needs aligned DKIM or a custom bounce domain for DMARC to pass.
How many domains use DMARC
In our scan of the Tranco top 1,000 domains on 19 October 2026, 722 of 1,000 domains published a DMARC record. 435 were at p=reject and 168 at p=quarantine.
The list includes CDNs and API hosts that never send mail, so we also looked at the 688 domains with an MX record. Of those, 346 (50.3%) were at reject, 508 (73.8%) at quarantine or reject, 101 (14.7%) at p=none, and 79 (11.5%) had no record. gmail.com and outlook.com were both at p=none with sp=quarantine, while google.com and microsoft.com were at p=reject.
Who requires DMARC
Google's email sender guidelines require SPF, DKIM and DMARC for senders of more than 5,000 messages a day to Gmail accounts, effective 1 February 2024, and state that the policy "can be set to none". The From domain must also align with the SPF or DKIM domain. Yahoo's and Microsoft's rules are covered in Google, Yahoo and Microsoft sender requirements.
What DMARC does not do
- It does not stop lookalike domains.
examp1e.comhas its own DNS and can pass its own DMARC. - It does not check display names.
"Example Support" <help@random-mail.net>is out of scope. - It does not encrypt anything or judge content.
- It can break legitimate indirect mail. Forwarding breaks SPF, and mailing lists that add footers break DKIM. ARC (Authenticated Received Chain) lets some receivers trust an intermediary's earlier results; Microsoft 365 lets admins name trusted ARC sealers.
For the attacks that do get through, see how email spoofing attacks work.
DMARCbis: now RFC 9989
The IETF's revision of DMARC, worked on for years as draft-ietf-dmarc-dmarcbis, is finished. The Datatracker page for the draft now redirects to the RFC and shows RFC 9989, "RFC - Proposed Standard (May 2026)", which obsoletes RFC 7489 and RFC 9091. The authors are T. Herr and J. Levine. RFC 7489 had been an Informational document from the Independent Submissions stream; RFC 9989 is IETF Standards Track.
What changed for domain owners:
- Organisational domain discovery uses the DNS Tree Walk instead of a public suffix list.
pct,rfandriare removed. A newt=ytag signals testing, and receivers apply one level below the stated policy.np(non-existent subdomains) andpsdare now core tags.- A record with no
ptag is treated asp=none. - Aggregate and failure reporting moved to RFC 9990 and RFC 9991.
Existing records keep working. Unknown tags must be ignored, so pct=100 does no harm, and receivers still on RFC 7489 ignore t and np.
Where to start
Look up your current record with the DMARC checker. If it is missing, publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (the generator will build it), confirm SPF and DKIM for every sender with the SPF checker and DKIM checker, and then follow the 5-step DMARC rollout to reach p=reject. DMARC+ reads the reports for you during that rollout, with a client portal that lists each sending source by IP, country and provider, and a 14-day trial.