What is DMARC?
Definition
DMARC is an email authentication standard that lets a domain owner tie SPF and DKIM results to the visible From address, state what receivers should do with mail that fails (none, quarantine or reject), and receive reports about mail sent in the domain's name. The policy is a TXT record at the _dmarc subdomain. First specified in RFC 7489, it is now defined by RFC 9989, published in May 2026.
Also known as: Domain-based Message Authentication, Reporting and Conformance, DMARC record, DMARC policy, _dmarc, v=DMARC1
The gap DMARC closes
SPF authenticates the envelope sender's domain and DKIM authenticates the signing domain. Neither is tied to the From: address a reader actually sees. A spoofer can send mail that passes SPF and DKIM for their own domain while showing your address in From:. DMARC adds alignment: a message passes DMARC only when a passing SPF or DKIM result belongs to a domain that matches the From: domain.
- Relaxed alignment (the default) accepts the same organizational domain, so a message signed by
news.example.comaligns withFrom: [email protected]. - Strict alignment requires an exact match.
Either aligned SPF or aligned DKIM is enough. Because forwarding routinely breaks SPF, aligned DKIM tends to be the result that carries a message through.
What the record looks like
The policy is a TXT record at the _dmarc label:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"| Tag | Role |
|---|---|
p | Policy for failing mail: none (monitor only), quarantine (treat as suspicious), reject. |
sp / np | Separate policies for subdomains, and for subdomains that do not exist in DNS. |
rua | Where aggregate reports should be sent. |
adkim / aspf | Alignment mode for DKIM and SPF: r relaxed, s strict. |
t | t=y signals testing mode: the owner does not yet want the policy fully applied. |
Getting from none to reject
Publishing p=reject on day one risks bouncing legitimate mail from a forgotten invoicing tool or CRM. The usual path is gradual:
- Start with
p=noneand anruaaddress. Receivers send XML reports showing which IPs sent mail as your domain, in what volume, with which SPF and DKIM results. - Fix every legitimate source you find so it signs with your own domain and is covered by SPF.
- Once legitimate traffic aligns, move to
p=quarantine, thenp=reject.
The percentage-based pct tag from RFC 7489 is gone in the new specification, replaced by the t flag; receivers will adopt the update at different speeds, so expect both behaviours for a while. Raw reports are tedious to read, and a report-processing service helps. Failure reports via ruf also exist, but many receivers do not send them for privacy reasons.
Where the specification stands
When DMARC was published as RFC 7489 in 2015, it was an Informational document rather than an IETF standard. RFC 9989, published in May 2026, obsoletes it and puts DMARC on the Standards Track, with reporting moved to companion documents (RFC 9990 and 9991). A notable change is how the organizational domain is found: instead of consulting the Public Suffix List, receivers perform a “DNS tree walk” up the domain hierarchy. The version tag is still v=DMARC1, so existing records keep working.
What Gmail and Yahoo require
Under the rules Google and Yahoo began enforcing in February 2024, bulk senders (Google's threshold is more than 5,000 messages a day to personal Gmail accounts) must publish a DMARC record and align the From: domain with either the SPF or the DKIM domain. Both providers accept p=none for this purpose. The requirement is having the record and alignment; moving to reject is a separate decision you make to protect your domain from spoofing.