DMARC Explained: Defending Your Domain Against Spoofing

SPF tells receivers whether the IP was authorised. DKIM tells them whether the message body is intact. DMARC is the missing piece — it tells receivers what to do when the answer is no, and it gives the domain owner the visibility to discover misuse of their brand. Since Gmail and Yahoo's bulk-sender requirements landed in 2024, every domain that sends real volume needs a DMARC policy of some kind.

What DMARC adds on top

SPF authenticates the envelope sender. DKIM authenticates a signed selection of headers and the body. Both are useful, but neither tells the receiving server how strict the domain owner wants it to be when something goes wrong. A failing SPF check on its own is just a data point — the receiver decides whether to act on it.

DMARC, defined in RFC 7489, fills three gaps:

1. Alignment. SPF and DKIM each authenticate some domain. DMARC requires that domain to match the visible From: header that the user actually reads.
2. A published policy. The domain owner declares what receivers should do with unaligned mail: monitor only, quarantine, or reject.
3. Reporting. Compliant receivers send aggregate XML reports back so the domain owner can see who is sending in their name — including unauthorised parties.

Alignment: the concept everyone trips on

This is the part of email authentication that confuses people most reliably. SPF authenticates the address in the MAIL FROM envelope, which the recipient never sees. DKIM authenticates the domain in the d= tag of the signature, which they also never see. The address the recipient does see is the From: header.

Without alignment, an attacker can:

• Send with MAIL FROM: bounce@phisher.example — SPF passes for phisher.example.
• Sign with a DKIM key for phisher.example — DKIM passes for phisher.example.
• Set the visible From: to support@your-bank.com.

SPF and DKIM both legitimately pass — for the wrong domain. The user reads support@your-bank.com. DMARC alignment requires either the SPF-authenticated domain or the DKIM-signing domain to match the From-header domain. If neither does, DMARC fails and the published policy kicks in.

Strict vs relaxed alignment

The aspf and adkim tags pick the comparison mode:

• Relaxed (r, default): the organisational domains must match. mail.example.com aligns with example.com.
• Strict (s): the labels have to match exactly. mail.example.com would not align with example.com.

Relaxed is the right choice for almost every sender. Strict is reserved for organisations whose threat model includes subdomain abuse from inside their own DNS estate.

The three policies

The p= tag is the single most consequential field in a DMARC record.

p=none (monitor only)

No enforcement. Receivers continue delivering exactly as they would have without your DMARC record — but they send aggregate reports back. This is the only safe place to start. You will discover senders you forgot existed: the marketing team's survey tool, the ops team's status page, the auto-responder for scheduling links. Fix each one before tightening the policy.

p=quarantine

Receivers should treat failing messages as suspicious. In practice this almost always means delivery to the spam folder. It is a reasonable middle stage but it is not a destination — an attacker still gets a phishing message in front of the user, just in a slightly less convenient folder.

p=reject

Failing messages are bounced at SMTP time. The recipient never sees them. This is the goal for any domain that cares about its brand being abused. Gmail, Microsoft and Yahoo all favour senders who publish a strong DMARC policy in their inbox-placement decisions.

The full record syntax

A DMARC record is a TXT record at _dmarc.{domain}. A representative example:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fo@example.com; fo=1; adkim=r; aspf=r; pct=100"

The tags, in order of importance

• v=DMARC1 — required, always literally this.
• p= — required policy: none, quarantine or reject.
• sp= — subdomain policy. Defaults to whatever p= is.
• rua= — address(es) that should receive aggregate XML reports. Comma-separated list of mailto: URIs.
• ruf= — address for forensic per-failure reports. Few receivers send these any more for privacy reasons.
• fo= — failure reporting options. 0 only when both SPF and DKIM fail; 1 when either fails; d on DKIM fail; s on SPF fail.
• adkim=, aspf= — alignment mode (r relaxed or s strict).
• pct= — the percentage of failing messages the policy applies to. Useful during rollout: pct=10 means apply the policy to 10% of failing mail.
• ri= — report interval in seconds. Default is 86400 (one day).

A rollout that won't break your mail

The single biggest DMARC mistake is jumping straight to p=reject and discovering that you have been quietly blackholing a third of your legitimate traffic. The right approach takes about four to six weeks.

1. Week 1: publish p=none. Set rua= to a mailbox you actually read — or, better, to a DMARC reporting service that aggregates the XML for you.
2. Weeks 2–3: read the reports. Catalogue every IP and source domain sending under your name. Confirm each one is legitimate. Fix SPF and DKIM so each aligns. For unknowns, investigate.
3. Week 4: move to p=quarantine; pct=10. A small slice of failing mail goes to spam. Watch for a week.
4. Week 5: ramp pct= through 25, 50, 100.
5. Week 6 onwards: graduate to p=reject. Failing mail is now blocked outright.

Why DMARC matters more than ever

Since February 2024, Gmail and Yahoo have required any sender pushing more than 5,000 messages per day to a Gmail or Yahoo address to publish a DMARC policy of at least p=none, with alignment between From: and either SPF or DKIM. Microsoft is moving the same direction. Without DMARC, your mail increasingly ends up in spam regardless of how clean the rest of the stack looks.

Beyond pure deliverability, a strong DMARC posture is brand protection. It makes it materially harder for criminals to send convincing phishing under your domain — and it gives you the visibility to spot them when they try.

The tools we actually use

• dmarc.postmarkapp.com — free weekly digests of your aggregate reports. Very readable.
• dmarcian.com — commercial, with a comprehensive UI.
• parsedmarc — open-source Python tool that ingests reports and ships them to Elasticsearch or Splunk.
• MXToolbox DMARC Lookup — the fastest way to confirm your record parses.

For the next layer of detail, see our companion guides on parsing DMARC aggregate XML and on the complete authentication stack.