DMARC

From Learn, the They Sent It email marketing encyclopedia · First edition · Updated October 29, 2026

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that a domain owner publishes to say three things: which messages count as really coming from the domain, what receivers should do with messages that fail, and where to send reports about both. It works on top of SPF and DKIM, and its contribution is alignment: a message only passes DMARC when a domain that SPF or DKIM has verified matches the domain in the From address the reader sees.^[1]

Since May 2026 DMARC is defined by RFC 9989, the first version on the IETF Standards Track. It replaces RFC 7489, the 2015 informational document most guides still cite, and RFC 9091. The new version removes the pct, rf and ri tags, adds np, t and psd, and stops using the Public Suffix List.^[1][2] On October 29, 2026, 17.6% of the brands we follow that publish DMARC still had at least one of the removed tags in their record.^[13]

How DMARC works

Email has two sender addresses. The envelope sender (also called the Return-Path or MAIL FROM) is used by servers and is where bounces go. The From address is what the reader sees. SPF checks the envelope sender: is this server allowed to send for that domain?^[6] DKIM checks a signature added by the sender: was this message signed by the domain in the signature's d= field, and has it been changed since?^[7] Neither one, alone, says anything about the From address. A spammer can pass SPF for their own domain while showing yours in From.

DMARC closes that gap. A receiving server:

Reads the domain in the From address and looks up its DMARC record.
Checks SPF and DKIM as usual.
Checks alignment: does the SPF-verified envelope domain, or the DKIM-verified d= domain, match the From domain? Under relaxed alignment (the default) a match within the same organizational domain counts, so mail.brand.com aligns with brand.com. Under strict alignment the domains must be identical.
The message passes DMARC if at least one aligned SPF or DKIM result passes. RFC 9989 still recommends that domain owners aim for both.^[1]
If it fails, the receiver applies the domain's policy (or its own judgment) and records the result for the domain's reports.

In practice: for marketing email the aligned identity is almost always DKIM. Most email platforms send with their own envelope domain, so SPF passes for the platform but does not align with your From domain. Setting up a custom DKIM signing domain (Klaviyo calls it a branded sending domain; Mailchimp, HubSpot and others have equivalents) is what makes your marketing mail pass DMARC.

The DMARC record

A DMARC record is a TXT record at _dmarc. plus the domain. A typical record for a brand moving toward enforcement:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

The tags defined by RFC 9989:^[1]

Tag	What it does	If left out
`v`	Version. Must be first and must be DMARC1.	Required
`p`	Policy for the domain: none, quarantine or reject.	none if missing
`sp`	Policy for subdomains that exist.	Same as p
`np`	Policy for subdomains that do not exist (new in RFC 9989, from RFC 9091).	sp, then p
`adkim`	DKIM alignment: r (relaxed, same organizational domain) or s (strict, exact match).	r
`aspf`	SPF alignment: r or s.	r
`rua`	Where to send aggregate reports (mailto: addresses).	No reports
`ruf`	Where to send failure reports for individual messages.	No reports
`fo`	When to send failure reports: 0, 1, d or s. Ignored without ruf.	0
`t`	Test mode (new). y asks receivers to apply one level less than the policy, for example quarantine instead of reject.	n
`psd`	Whether the domain is a public suffix such as a top-level domain: y, n or u (new). Brands leave it out.	u

Receivers must ignore tags they do not know, so an old record with pct still works. But a receiver following RFC 9989 no longer acts on pct, ri or rf.

Policies: none, quarantine, reject

p=none asks receivers to take no special action. RFC 9989 calls this monitoring mode when reports are being collected: you see who sends as your domain without affecting delivery.
p=quarantine asks receivers to treat failing mail as suspicious, usually the spam folder.
p=reject asks receivers to refuse failing mail during the SMTP conversation.

Quarantine and reject are what the standard calls enforcement. Receivers are not obliged to follow the policy; it is a request, and large mailbox providers combine it with their own filtering.^[1]

What changed in RFC 9989 (2026)

RFC 9989 was published in May 2026, with two companion documents for reporting.^[1][4][5] The changes that matter to a sender:

It is now an internet standard. RFC 7489 was an informational document from the Independent Submissions Editor. RFC 9989 is IETF Standards Track (Proposed Standard).
pct is removed. The percentage tag let you apply a policy to only part of your failing mail while moving to enforcement. Its job is taken by t=y (test mode), which asks receivers to apply one level less than the stated policy.
ri and rf are removed (report interval and failure report format), along with the option to set a maximum report size in a report address.
np is added for subdomains that do not exist, so random123.example.com can be refused even while your real subdomains are still at a softer policy. It comes from RFC 9091, which RFC 9989 replaces.
psd is added to mark public suffix domains (for example a top-level domain operator). Brands do not need it.
The Public Suffix List is gone. Receivers find the organizational domain and its policy by walking up the DNS tree instead. Receivers still using the list may reach different answers for unusual domains.
Reporting moved out. Aggregate reports are now RFC 9990 and failure reports RFC 9991.
New advice on reject. Domains whose people post to mailing lists (general-purpose mailbox domains) should not publish p=reject, and anyone moving to reject should run p=none and then p=quarantine for about a month each, using the reports to compare.

What to do with an existing record: nothing breaks. If you used pct to phase in a policy, replace it with t=y while testing, then remove both. Delete ri and rf. Consider adding np=reject to stop forged mail from made-up subdomains.

Setting up DMARC

List everything that sends as your domain: your email platform, your store's order emails, help desk, CRM, invoicing, and your own staff mailboxes.
Make each one pass and align: SPF for the services that use your domain in the envelope sender, and a DKIM key on your domain for each platform. Watch SPF's limit of ten DNS lookups.
Publish p=none with a rua address and read the aggregate reports for at least a month. A DMARC report service makes them readable.
Fix every legitimate source that fails, then move to p=quarantine (with t=y first if you want a softer step), and later to p=reject if your domain is not a general-purpose mailbox domain.
Keep watching the reports. New tools added by a marketing or sales team are the usual cause of new failures.

Reports

Aggregate reports (rua, RFC 9990) are daily XML summaries from each receiver: how many messages claimed your domain, from which IP addresses, and how each did on SPF, DKIM and DMARC. They contain no message content and are the main tool for moving to enforcement.^[4] Failure reports (ruf, RFC 9991) describe individual failing messages. Few large mailbox providers send them, for privacy reasons.^[5]

Forwarding and mailing lists

Forwarding changes the server that delivers a message, so SPF fails; mailing lists often change the subject or body, so DKIM fails. A message that passed DMARC at the first hop can fail at the second. Under p=reject that mail is lost, which is why RFC 9989 tells general-purpose mailbox domains not to use reject. Many lists now rewrite the From address to their own domain. ARC (Authenticated Received Chain) lets a forwarder record the authentication results it saw so the final receiver can choose to trust them.^[8] ARC is still widely used, but in April 2026 the IETF began moving it to Historic status, which means it should not be newly adopted between unrelated systems; its ideas are being folded into DKIM2, an IETF draft that is not yet ready to deploy.^[9] For a brand's marketing domain, which people do not post to lists from, this is rarely a problem.

Gmail, Yahoo and Microsoft requirements

Gmail, from February 1, 2024: anyone sending more than 5,000 messages a day to Gmail accounts must publish DMARC (p=none is enough), and the From domain must align with SPF or DKIM. All senders need SPF or DKIM. Bulk senders also need one-click unsubscribe and a spam rate below 0.3%.^[10]
Yahoo introduced matching requirements for bulk senders at the same time.^[11]
Outlook.com (Hotmail, Live): from May 5, 2025, domains sending more than 5,000 emails a day must pass SPF and DKIM and publish DMARC of at least p=none aligned with one of them. Non-compliant mail goes to Junk, with rejection (error 550 5.7.515) announced for a later date.^[12]

None of the three requires enforcement. But a record at p=none satisfies them only if alignment actually passes, and BIMI (brand logos in the inbox) needs quarantine or reject.

What brands publish

We looked up the DMARC record of every brand with a page on They Sent It on October 29, 2026: 41,210 domains, almost all online shops that send marketing email.^[13]

DMARC policy published, 41,210 brand domains, October 29, 2026
p=none (monitoring)	63.0%
p=quarantine	14.1%
p=reject	8.4%
No DMARC record	13.0%
More than one record (invalid)	1.4%

Most brands publish DMARC but do not enforce it. Nearly two in three sit at p=none; fewer than one in four (22.5%) use quarantine or reject.
Only 40.5% ask for aggregate reports, so many p=none records are not monitoring anything.
17.6% of records still use tags RFC 9989 removed: pct in 14.5% of all domains, ri in 4.4%, rf in 2.0%. Only 15 brands publish the new np tag and 55 the new t tag.
1.4% publish two or more DMARC records, which makes DMARC fail to apply at all.
2.5% publish a BIMI record.

By the brand's email platform
Platform	Brands	p=none	Enforcing	p=reject	No record
Klaviyo	33,720	65.0%	21.5%	7.9%	11.8%
Mailchimp	4,205	61.1%	17.9%	6.9%	20.3%
HubSpot	2,460	40.7%	41.9%	15.9%	17.3%
ActiveCampaign	388	63.9%	22.4%	7.2%	11.3%

Method: one DNS lookup per domain through public resolvers; 16 of 41,226 lookups failed and are left out. A brand's platform is the one we record from its emails. "Enforcing" is quarantine or reject. These are the records brands publish, not how receivers treat their mail.

Common mistakes

Staying at p=none for years with no rua address, so nobody reads the results.
Publishing two records, often one from an old provider and one from a new one. Receivers then ignore DMARC for the domain.
Moving to reject before every sender aligns, which silently drops invoices, receipts or help desk replies.
Relying on SPF alone with a platform that uses its own envelope domain: SPF passes but does not align.
Forgetting subdomains: without sp or np, made-up subdomains inherit only what p says.
Breaking the record's syntax: a missing semicolon or a v=DMARC1 that is not first.

History

2012: the DMARC specification is published by an industry group of mailbox providers and senders, building on earlier work on SPF and DKIM.
2015: RFC 7489 documents DMARC as an informational RFC.^[2]
2021: RFC 9091 adds an experimental extension for public suffix domains.^[3]
2024: Gmail and Yahoo require DMARC from bulk senders.^[10]
2025: Outlook.com does the same for senders over 5,000 a day.^[12]
May 2026: RFC 9989 makes DMARC an IETF standard, with reporting in RFC 9990 and 9991.^[1]

References

First edition, October 29, 2026, by Conner Baker. Corrections are made in place and noted here. October 29, 2026: added that ARC is being moved to Historic status. Found an error? Tell us.