What Is DMARC? The Policy Layer on Top of SPF and DKIM

DMARC is a DNS TXT record, published at _dmarc under a domain, that states how the domain owner wants receivers to treat mail whose From domain fails authentication, and where to send reports about it. A message passes DMARC when SPF or DKIM passes and the passing domain aligns with the domain in the From header. The current standard is RFC 9989, published in May 2026.

DMARC runs no signature check or IP check of its own. It takes the verdicts produced by SPF and DKIM, adds the alignment test, and gives the domain owner two things neither protocol provides: a published request for how failing mail should be handled, and a reporting channel back from receivers. The SPF, DKIM and DMARC overview explains how the three fit together. This page covers DMARC alone.

Which specification defines DMARC today?

RFC 9989. In the words of the dmarc.org announcement: "On May 20th, 2026 the IETF's RFC Editor published three documents that update the DMARC protocol, making the changes and enhancements previously referred to as "DMARCbis" official, and moving the updated DMARC protocol to the IETF's Standards Track." RFC 9989 is the core protocol, RFC 9990 covers aggregate reporting, and RFC 9991 covers failure reporting.

The predecessor, RFC 7489, was published in March 2015 as an Informational document, not a standard. RFC 9989 obsoletes it, along with RFC 9091, the experimental specification for public suffix domains. Much of the guidance in circulation, including some provider help pages, was written against RFC 7489. Where the two differ, this page says so.

Where does a DMARC record live?

At a TXT record named by prepending the label _dmarc to the Author Domain, which is the domain in the message's From header. For mail from example.com, a minimal record looks like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

If the Author Domain has no record, RFC 9989 continues the search in a fixed order: the Author Domain, then its Organizational Domain, then its public suffix domain (PSD). A message from news.example.com with no record at _dmarc.news.example.com falls back to the policy at _dmarc.example.com. RFC 7489 adds a strict failure rule: if the lookup returns multiple DMARC records, or none, "policy discovery terminates and DMARC processing is not applied to this message." It also states that unknown tags must be ignored.

One change in the record itself matters for anyone writing a parser. Under RFC 7489, p was required. Under RFC 9989 it is RECOMMENDED, and a syntactically valid record without it "is treated as if it included "p=none"".

What tags can a DMARC record contain?

These are the tags defined by RFC 9989. RFC 7489 requires v=DMARC1 to be the first tag.

The fo values come from RFC 7489: 0 reports when all mechanisms fail to produce an aligned pass, 1 when any mechanism fails, d on a DKIM failure, s on an SPF failure. RFC 9989 makes 0 and 1 mutually exclusive. RFC 7489 says fo is ignored unless ruf is also present.

How does DMARC alignment work?

A DMARC pass needs one authentication mechanism to pass and the domain it authenticated to match the From domain. Either SPF or DKIM is enough. Both are not required.

RFC 9989 defines two modes. Relaxed alignment requires the Author Domain and the authenticated domain to share the same Organizational Domain. Strict alignment requires them to be identical. The RFC's own examples, for a From domain of news.example.com:

So a message from news.example.com signed with a DKIM key whose d= domain is foo.example.com passes DMARC under the default adkim=r and fails under adkim=s. RFC 9989 is plain about which mode most domains need: "In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs."

Two details catch implementers. For SPF, "DMARC relies solely on SPF validation of the MAIL FROM identity." There is no fallback to the HELO identity. For DKIM, a message carrying several signatures passes "if any DKIM-Authenticated Identifier aligns with the Author Domain." A third-party signature from an email service provider does no harm as long as one aligned signature is also present.

What do p=none, p=quarantine and p=reject mean?

RFC 9989 phrases each policy as a statement of the domain owner's view of failing mail:

• none: "The Domain Owner offers no expression of preference."
• quarantine: "The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern."
• reject: "The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid."

Google's admin documentation translates these into receiver actions. none means take no action, deliver the message, and log it in a daily report. quarantine means mark it as spam and send it to the spam folder. reject means reject the message, in which case the receiving server usually sends a bounce.

The policy is a request, not a command. RFC 9989 Section 7.4 goes further than RFC 7489 did: receivers must not reject incoming messages solely because of a p=reject policy, and "In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were "p=quarantine" rather than "p=reject"." That is the specification's text. It is not a description of how any particular mailbox provider behaves today.

The same section places obligations on senders. Domains used for general-purpose email, whose users post to mailing lists, SHOULD NOT publish p=reject. Domains that do publish it "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages."

How do you roll out a DMARC policy?

In stages, watching reports between each one. The sources agree on the order and disagree on the pace.

1. Get SPF and DKIM right first. Google advises setting up DKIM and SPF at least 48 hours before DMARC.
2. Publish p=none with a rua address. M3AAWG's guidance is that every record, even at p=none, should carry rua, because without reports "the domain owner cannot know whether or not it is safe to move from p=none to stricter policies". Google suggests one week at this stage. RFC 9989 suggests at least a month.
3. Move to p=quarantine. RFC 9989 recommends an equally long period at quarantine, comparing message dispositions, before going further.
4. Move to p=reject. Microsoft's advice: "once your legitimate sources are aligned, p=reject is the most effective at thwarting domain spoofing. We advise moving gradually (none → quarantine → reject) to avoid unintended mail loss."

Under RFC 7489, the tool for easing between stages was pct, the percentage of failing mail the policy applies to. Google's rollout page still uses it: start quarantine at a small percentage (it suggests 10% for a small organization, 1% for a large one) and raise it to 100. Its example record is v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com.

RFC 9989 removes pct. Its reasoning: "Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default)". The replacement is t. With t=y, a quarantine policy is applied as none and a reject policy is applied as quarantine. t=y and t=n are meant to be analogous to pct=0 and pct=100. The tag has no effect on reporting, and no effect at p=none.

Readers will meet pct in the wild for some time, in records and in provider documentation. Treat it as legacy. No source consulted for this page establishes whether the major receivers have implemented t yet.

M3AAWG states the end goal directly: "Policy statements should be "p=reject" where possible, "p=quarantine" otherwise." It treats p=none, sp=none and partial pct values as transitional states to leave as quickly as possible.

What changed from RFC 7489?

• Status. RFC 7489 was Informational. RFC 9989, 9990 and 9991 are Standards Track.
• Tags removed: pct, rf (failure report format) and ri (requested aggregate report interval, 86,400 seconds by default under RFC 7489).
• Tags added: np for non-existent subdomains, psd brought in from the now-obsoleted RFC 9091, and t for test mode.
• Organizational Domain lookup. RFC 7489 relied on a Public Suffix List. RFC 9989 replaces it with a DNS Tree Walk, capped so that "Author Domains with more than eight labels do not result in more than eight DNS queries."
• p no longer required. A record without it is read as p=none.
• SPF identity. MAIL FROM only, with no HELO fallback.
• Report size limits. The size-limit notation in rua URIs is gone.
• p=reject guidance. General-purpose mail domains SHOULD NOT publish it.

The lookup change carries a transition risk. Receivers still using a Public Suffix List and receivers using the Tree Walk can reach different Organizational Domains for the same address. RFC 9989 names the way out: "This issue is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email."

What are DMARC aggregate and failure reports?

Aggregate reports are the useful ones. RFC 9990 defines them as XML documents with the root element feedback, each covering a single DMARC policy domain. A reporting period typically spans one UTC day, starting at 0000 UTC. Each report lists the sending source IPs with message counts, the disposition applied, and the SPF and DKIM results, for passing mail as well as failing mail. Attachments are gzip-compressed or plain text/xml. Compared with RFC 7489, the report identifier has more structure, the DKIM selector is now required, and PSD information is included.

Sending reports to a domain other than the one that published the policy needs permission. The report destination's domain publishes a TXT record starting with v=DMARC1 at a name that combines both domains, such as blue.example.com._report._dmarc.red.example.net for reports about blue.example.com sent to red.example.net. Without it, receivers do not send there. RFC 7489 gives the reason: otherwise a bad actor could "publish a DMARC policy record that requests that reports be sent to a victim address".

Failure reports, requested with ruf, describe individual messages, and that is their problem. RFC 9991 notes that "many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports, which provide statistical visibility without exposing sensitive content." M3AAWG is blunter: "It is generally accepted that, given privacy concerns and the need for redaction of what might be personally identifiable information (PII), DMARC failure reports are neither sent by most receivers nor terribly useful to most domain owners." Microsoft's FAQ for Outlook.com states: "We don't have plans to send RUF." Publishing ruf is optional, and an empty failure-report inbox is normal.

Why does DMARC break mailing lists?

Because lists re-send mail they did not write. A list server that edits the subject or appends a footer invalidates the author's DKIM signature, and SPF then authenticates the list's server rather than the author's domain. Neither result aligns with the From domain. RFC 9989 adds a knock-on effect: rejecting list traffic "can cause the Mail Receiver's users to have their subscriptions to that mailing list canceled by the list software's automated handling of such rejections". Forwarding causes a related failure, since SPF breaks when the sending IP changes, while DKIM generally survives unless the message is modified.

List software works around this. RFC 7960 lists the options: rewrite the From header to the list address, wrap the original in a message/rfc822 part sent from the list, leave the message unmodified so DKIM stays valid, or refuse posts from domains with a policy stricter than none. GNU Mailman 3 implements From munging and wrapping, applied to mail from domains publishing quarantine or reject.

ARC (Authenticated Received Chain, RFC 8617) is the protocol-level answer. It records the authentication results at each hop so a downstream receiver can see how the message was assessed before an intermediary changed it. RFC 8617 is Experimental. M3AAWG recommends that intermediaries implement it, and Microsoft says ARC "preserves the original authentication checks, preventing legitimate forwarded mail from being wrongfully flagged."

Which mailbox providers require DMARC?

Gmail, Yahoo and Outlook.com all require it from high-volume senders. None requires an enforcing policy.

• Gmail, from February 1, 2024. Senders of more than 5,000 messages a day to Gmail accounts must publish DMARC, and "Your DMARC enforcement policy can be set to none." The From domain must align with the SPF or DKIM domain. Unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error", a code distinct from the generic 550 5.7.1 policy rejection.
• Yahoo, from February 2024. Bulk senders must "Publish a valid DMARC policy with at least p=none - DMARC must pass", with an aligned From domain. Yahoo said enforcement would be rolled out gradually as it monitored compliance through the first half of the year.
• Outlook.com, from May 5, 2025. Domains sending 5,000 or more messages a day to Microsoft consumer email services need SPF, DKIM and DMARC, with DMARC at "At least p=none and align with either SPF or DKIM (preferably both)." Microsoft documents two consequences for non-compliant mail: routing to Junk, and rejection with 550 5.7.515. Its announcement contains both, and the sources for this page do not settle which applies today. The SMTP error codes reference covers how to read the rejection format.

How many domains publish DMARC?

The only recent measurements come from DMARC vendors, and their samples differ, so the figures should not be compared directly.

EasyDMARC's adoption report (March 2026) covers the top 1.8 million domains. It found 52.1% with a valid DMARC record in early 2026, up from 29.1% in 2023 and 47.7% in 2025. 29.2% were at p=none and 22.9% at quarantine or reject. Only 8.9% combined p=reject with aggregate reporting. Among the Fortune 500, 95% had valid records.

Valimail's 2026 report (February 2026) puts DMARC record adoption at 78% of domains and enforcement at 42%, up from 35% over 2025. The press release does not state the sample. Both reports show the same shape: far more domains publish a record than enforce one.