DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication standard that lets a domain owner publish a policy in DNS stating how receivers should treat messages that claim to come from the domain but fail authentication. In email infrastructure, it builds on SPF and DKIM and adds the missing link: alignment with the visible From address.
DMARC is specified in RFC 7489, with an updated specification in progress at the IETF. Its second purpose is reporting: receivers send aggregate data back to the domain owner, which shows who is sending mail in the domain’s name and whether that mail authenticates.
How DMARC evaluates a message
A receiving mail server applies DMARC after it has run SPF and DKIM checks. It takes the domain from the RFC5322.From header, the address the reader sees, and looks up a TXT record at _dmarc under that domain or its organizational domain.
A message passes DMARC when at least one mechanism both passes and aligns. SPF aligns when the envelope sender domain, the Return-Path, matches the From domain. DKIM aligns when the d= domain in a valid signature matches the From domain. If neither passes in alignment, the receiver applies the published policy, subject to its own local judgment.
The following table shows how the outcomes of SPF, DKIM and alignment combine into a DMARC result.
| SPF result | DKIM result | Aligned with From | DMARC result |
|---|---|---|---|
| Pass | Fail | SPF domain aligned | Pass |
| Fail | Pass | DKIM domain aligned | Pass |
| Pass | Pass | Neither domain aligned | Fail |
| Fail | Fail | Not applicable | Fail |
The third row matters most in practice: a message can pass both SPF and DKIM for a third-party domain and still fail DMARC, because neither authenticated domain matches the brand the reader sees.
DMARC record tags and policy levels
A DMARC record is a single TXT string such as v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. Each tag controls one aspect of policy, alignment or reporting.
| Tag | Values | Purpose |
|---|---|---|
| p | none, quarantine, reject | Policy for the domain |
| sp | none, quarantine, reject | Policy for subdomains |
| adkim and aspf | r (relaxed) or s (strict) | Alignment mode for DKIM and SPF |
| pct | 0 to 100, default 100 | Share of failing mail the policy applies to |
| rua | Mailbox address | Destination for aggregate reports |
| ruf | Mailbox address | Destination for failure reports, rarely honored |
Relaxed alignment accepts any subdomain of the same organizational domain, so mail.example.com aligns with example.com. Strict alignment requires an exact match. Relaxed mode is the default and suits most organizations.
The three policy levels define a gradual enforcement path, compared in the next table.
| Policy | Receiver action on failure | When to use it |
|---|---|---|
| p=none | Deliver normally, report only | Discovery of all legitimate senders |
| p=quarantine | Place in spam or junk folder | Transition once most mail aligns |
| p=reject | Refuse during the SMTP session | Full protection against direct spoofing |
DMARC compared with SPF and DKIM
SPF, DKIM and DMARC are complementary, and none replaces the others. SPF authorizes sending IP addresses, DKIM signs message content with a domain key, and DMARC ties both to the visible sender and adds a policy.
| Mechanism | What it verifies | Domain checked | Survives forwarding |
|---|---|---|---|
| SPF | Sending IP is authorized | Envelope sender (Return-Path) | Usually not |
| DKIM | Signed headers and body are unchanged | Signing domain (d=) | Usually, unless content is altered |
| DMARC | Aligned SPF or DKIM pass | Visible From domain | Depends on DKIM |
Because forwarding breaks SPF, DKIM signing is essential for reliable DMARC results. ARC (Authenticated Received Chain) lets intermediaries such as mailing lists record the authentication state they saw, which receivers may use when the original signature breaks.
Deploying DMARC step by step
A safe deployment moves from monitoring to enforcement over weeks or months, depending on how many systems send mail for the domain.
- Publish p=none with an rua address and collect aggregate reports, which arrive as XML files, usually once per day from each large receiver.
- Inventory every legitimate source: corporate mail, marketing platforms, ticketing systems, invoicing tools and other third-party senders.
- Configure each source to send with aligned DKIM, ideally a custom signing domain, and add it to SPF where possible.
- Move to p=quarantine, optionally with a low pct value, and watch reports for legitimate failures.
- Move to p=reject and protect unused domains and subdomains with their own reject records.
Large mailbox providers now require a DMARC record from bulk senders, so even organizations that do not plan enforcement need at least a monitoring policy.
Limitations and common mistakes
DMARC protects only against exact-domain spoofing. It does not stop lookalike domains, display name tricks or compromised accounts that send fully authenticated mail.
- Staying at p=none indefinitely gives visibility but no protection.
- Exceeding the SPF limit of 10 DNS lookups causes SPF to return a permanent error and can make DMARC fail.
- Forgetting the sp tag leaves subdomains open to spoofing when the parent policy is strict.
- Ignoring mailing lists leads to rejected messages when lists rewrite subjects or footers.
A plain-language summary
DMARC is a public instruction from a company about its own email. It tells other mail systems how to check that a message really comes from that company. It also says what to do when the check fails. The message can be let through, put in spam or refused.
Without it, anyone can write the company’s name in the sender line. It is like writing a famous return address on an envelope. With DMARC, fake messages using the real domain can be stopped before they reach the inbox. The company also receives regular summaries of who is sending mail in its name.
An example from practice
A regional insurance company finds that customers are receiving fake payment requests that show its exact domain in the From line. The IT team publishes a DMARC record with p=none and an aggregate report address, and within two weeks the reports reveal seven legitimate sending services, including a marketing platform and a claims system that sent mail without aligned DKIM.
The team configures DKIM signing on its own domain for each service, then moves to quarantine at 25 percent, raises it to 100 percent, and finally to p=reject after three months. Spoofed messages using the exact domain stop reaching major mailbox providers, and the remaining phishing attempts shift to lookalike domains, which the company then monitors separately.