What Is DMARC? Email Authentication Explained

Quick definition

DMARC is an email authentication protocol that lets a domain owner publish a policy in DNS telling receiving mail servers what to do with messages that claim to come from the domain but fail authentication, and where to send reports about the results.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on two older email checks, SPF and DKIM. On their own, those checks can tell a receiving server that a message came from an authorized server or carries a valid signature from some domain. Neither one, by itself, proves that the domain your customer sees in the From: line actually sent the message. DMARC closes that gap.

How DMARC works

When a mail server receives a message, it looks at the domain in the visible From: address, which the current standard calls the Author Domain, and fetches that domain's DMARC policy record, a TXT record published in DNS at _dmarc.example.com. If there is no record at that exact name, for example because the mail comes from shop.example.com, the receiver walks up the domain tree and checks _dmarc at each parent name instead, using no more than eight DNS queries in total. Then it looks at two checks:

SPF checks whether the server that delivered the message is authorized to send for the envelope sender domain, the "MAIL FROM" address used behind the scenes during delivery. When that address is empty, as it is on bounce messages, SPF checks the name the sending server announced in its HELO greeting instead.
DKIM checks a cryptographic signature added by the sending system against a public key published in the signing domain's DNS.

A message passes DMARC when at least one of those checks passes and the domain it verified is aligned with the From: domain. Under relaxed alignment, the default, the two domains only need to share the same Organizational Domain, so mail.example.com aligns with example.com. Under strict alignment they must match exactly.

The Organizational Domain is the highest-level domain run by the same owner, usually the registered name such as example.com. Receivers used to work it out from a published list of public suffixes. The current standard replaces that list with the same DNS Tree Walk, reading the DMARC records found on the way up.

The policy: none, quarantine or reject

The record's p= tag, which the current standard calls the Domain Owner Assessment Policy, tells receivers what the domain owner wants done with messages that fail:

p=none asks for no special action. It is used to collect reports before enforcing anything.
p=quarantine asks receivers to treat failing mail as suspicious, which in practice usually means the spam folder.
p=reject asks receivers to refuse failing mail during delivery.

The policy is a request. Each receiving system decides how to apply it.

Reports

The rua= tag lists an address for aggregate reports. Participating receivers periodically send machine-readable summaries showing which servers sent mail using your domain and whether that mail passed. These reports are how a business finds forgotten senders, such as a billing system or newsletter service, before it tightens the policy.

The current standard

DMARC was first documented in 2015 in RFC 7489, an informational document. In May 2026 the IETF replaced it with three Standards Track documents: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Records still begin with v=DMARC1 and still use the p= and rua= tags.

A few tags changed. The pct tag, which applied a policy to a percentage of mail, was removed; a t=y testing flag now asks receivers to apply one level less than the published policy instead. The rf and ri tags were removed, and np (policy for subdomains that do not exist) and psd (public suffix flag) were added.

Limitations

DMARC protects the exact domain in the From: line. It does not stop look-alike domains, such as a misspelling of your business name, and it does not guarantee inbox placement. Mailbox providers also weigh things like sender reputation, complaint rates and message content, so a message can pass DMARC and still be filtered as spam.

A practical example

A regional HVAC company sends invoices from its billing software, appointment reminders from a scheduling service, and everyday mail from its office email. Customers start reporting fake "past due" emails that appear to come from the company's domain.

The company publishes a DMARC record with p=none and a reporting address. Within a few weeks the reports show every service sending as the company, including the scheduling service, which turns out not to be signing its messages with DKIM for the company's domain. Once that service is set up correctly and every legitimate source passes, the company moves to p=quarantine and later to p=reject. Spoofed invoices that fail authentication are now quarantined or refused by receivers that honor the policy.

Why it matters

Your domain is part of your brand. Without DMARC, anyone can put your domain in the From: line and receivers have no published instruction from you about how to treat it. DMARC gives them that instruction and gives you visibility into who is sending as you.

It is also increasingly expected. Google's sender guidelines, in effect since February 2024, require anyone sending more than 5,000 messages a day to Gmail accounts to set up both SPF and DKIM, publish a DMARC record (a p=none policy is acceptable) and, for direct mail, have the From: domain aligned with either the SPF or the DKIM domain. All senders, whatever their volume, must set up at least SPF or DKIM.

Common mistakes

Jumping straight to p=reject. Without reviewing reports first, legitimate mail from a forgotten service can be rejected.
Staying at p=none indefinitely. A monitoring-only policy gives visibility but asks receivers to take no action against spoofed mail.
Sending reports to a mailbox nobody reads. Aggregate reports are machine-readable XML and are much easier to use through a reporting tool.
Passing SPF or DKIM without alignment. A third-party service may pass SPF using its own domain. That does not help DMARC unless the verified domain aligns with your From: domain.
Breaking SPF with too many lookups. An SPF check may use no more than 10 terms that cause DNS lookups: the include, a, mx, ptr and exists mechanisms and the redirect modifier. ip4, ip6 and all do not count. Lookups inside nested includes count toward the same limit, so each new sending service adds to it, and going over makes SPF return a permanent error (permerror) instead of a pass. Checkers should also stop after two lookups that find no record (void lookups).
Relying on SPF alone. When a message is forwarded, a different server delivers it, so SPF often fails. A DKIM signature usually survives forwarding if the message is not changed, which is why DKIM matters for DMARC.

SPF vs. DKIM vs. DMARC

The three standards work together, and DMARC depends on the other two.

	SPF	DKIM	DMARC
What it checks	Whether the sending server is authorized for the envelope sender domain	Whether the message signature verifies with the signing domain's public key	Whether SPF or DKIM passed for a domain aligned with the visible From: address
Where it is published	TXT record on the envelope sender (MAIL FROM) domain	TXT record under the signing domain's `_domainkey` name	TXT record at `_dmarc` on the From: domain, or on a parent domain found by the DNS Tree Walk
Usually survives forwarding	Often not	Yes, if the message is not modified	Depends on DKIM surviving
Tells receivers what to do on failure	No	No	Yes: none, quarantine or reject
Sends reports	No	No	Yes, to the rua address

Frequently asked questions

Does DMARC stop all phishing?

No. DMARC protects the exact domain in the From: line. Attackers can still use look-alike domains, free email accounts or display names that mimic your business, so staff and customer awareness still matter.

Will DMARC get my email into the inbox?

Not by itself. Authentication helps receivers trust that mail really comes from you, but inbox placement also depends on sender reputation, complaint rates, list quality and content.

Do I need SPF and DKIM before setting up DMARC?

DMARC needs at least one of them to pass with an aligned domain. In practice, set up both, because SPF often fails on forwarded mail while DKIM usually survives.

What does a DMARC record look like?

A simple monitoring record, published as a TXT record at _dmarc.example.com, looks like v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. The policy is then raised to quarantine or reject once the reports show all legitimate mail passing.

Sources

RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor (IETF) (accessed November 9, 2026)
RFC 9990: DMARC Aggregate Reporting, RFC Editor (IETF) (accessed November 9, 2026)
RFC 9991: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting, RFC Editor (IETF) (accessed November 9, 2026)
RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), obsoleted, RFC Editor (IETF) (accessed November 9, 2026)
RFC 7208: Sender Policy Framework (SPF), RFC Editor (IETF) (accessed November 9, 2026)
RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, RFC Editor (IETF) (accessed November 9, 2026)
Email sender guidelines, Google Workspace Admin Help (accessed November 9, 2026)

What Is DMARC? Domain-based Message Authentication, Reporting, and Conformance Explained