Quick definition
DMARC is a DNS record that lets a domain owner tell receiving mail servers what to do with messages that claim to come from the domain but fail SPF and DKIM checks, 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 and fetches that domain's DMARC record, a TXT record published in DNS at _dmarc.example.com. 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.
- 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 policy: none, quarantine or reject
The record's p= tag tells receivers what the domain owner wants done with messages that fail:
p=noneasks for no special action. It is used to collect reports before enforcing anything.p=quarantineasks receivers to treat failing mail as suspicious, which in practice usually means the spam folder.p=rejectasks 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 2026 the IETF replaced it with Standards Track documents: RFC 9989 for the core protocol and RFC 9990 for aggregate reporting, alongside RFC 9991. Records still begin with v=DMARC1 and still use the p= and rua= tags.
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 publish a DMARC record (a p=none policy is acceptable) and to have the From: domain aligned with either the SPF or the DKIM domain.
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. SPF allows no more than 10 DNS-querying mechanisms, such as
include. Each new sending service adds to the count, and going over makes SPF return an error. - 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.
How a receiving server checks DMARC
A sending server delivers a message from example.com. The receiving server (1) runs an SPF check: is the sending IP address authorized for the envelope (MAIL FROM) domain? (2) It runs a DKIM check: does the message signature verify with the public key in the signing domain's DNS? (3) It checks DMARC alignment: did SPF or DKIM pass for a domain that matches the visible From: domain? If yes, the message passes DMARC and is delivered normally, although spam filtering and reputation checks still apply. If no, the receiver applies the policy published in the domain's DMARC record: none, quarantine or reject. The SPF record, DKIM key and DMARC record are all looked up in the sending domain's DNS. Separately, the receiver periodically sends an aggregate report to the address in the domain's rua tag.
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 sending domain | TXT record under the signing domain's _domainkey name | TXT record at _dmarc on the From: domain |
| 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 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)