DMARC Explained: Protect Your Domain from Email Spoofing

SPF and DKIM tell receivers whether a message was authorised. DMARC tells them what to do when the answer is no — and gives the domain owner the visibility to discover unauthorised use of their brand. Since Gmail and Yahoo's 2024 bulk-sender requirements, every domain that sends real volume needs a DMARC policy.

What DMARC actually adds

SPF authenticates the envelope sender. DKIM authenticates a signed set of headers and the body. Both are useful, but neither tells the receiving server what the domain owner wants to happen when authentication fails. A failing SPF check on its own doesn't mean "reject the message" — the receiver has to make that decision based on its own policies.

DMARC (RFC 7489) closes that gap with three additions:

1. Alignment. SPF and DKIM each pass against some domain. DMARC requires that domain to match the visible From: header that the user sees.
2. A published policy. The domain owner declares what receivers should do with unaligned mail: do nothing, quarantine, or reject.
3. Reporting. Receivers send aggregate XML reports back to the domain owner so they can see who is sending using their domain — including unauthorised senders.

Alignment: the part everyone gets wrong

This is the single most misunderstood concept in email authentication. 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 visible From: header.

Without alignment, an attacker could:

• Send mail with MAIL FROM: bounce@attacker.com (passes SPF for attacker.com).
• Sign with a DKIM key for attacker.com (passes DKIM for attacker.com).
• Set the visible From: to billing@your-bank.com.

SPF and DKIM both pass — for attacker.com — but the user sees billing@your-bank.com. DMARC alignment requires either the SPF-authenticated domain or the DKIM-signing domain to match the From-header domain. If neither matches, DMARC fails.

Strict vs relaxed alignment

The aspf and adkim tags control how strict the match has to be:

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

Relaxed alignment is right for almost everyone. Strict is for organisations whose threat model includes subdomain abuse.

The three policies

The p= tag is the heart of a DMARC record. Its value tells receivers what to do when a message fails alignment.

p=none (monitor)

No enforcement. Receivers continue to deliver as they normally would, but they send aggregate reports back. This is where every DMARC deployment should start. You'll discover senders you didn't know about — the marketing team's surveys, the helpdesk SaaS, the auto-responder that fires off scheduling links — and you can fix them before tightening the policy.

p=quarantine

Receivers should treat failing messages as suspicious. In practice this usually means delivery to the spam folder. Quarantine is a reasonable middle step but not a final state — an attacker still gets their phishing message in front of the user, just in a different 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.

The full record syntax

A DMARC record is a TXT record at _dmarc.{domain}. 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"

Tag reference

• v=DMARC1 — required, always this string.
• 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 (default) 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= — percentage of messages the policy applies to. Useful during rollout: pct=10 means apply the policy to 10% of failing messages.
• ri= — reporting interval in seconds (default 86400, one day).

A safe rollout plan

The cardinal sin of DMARC is jumping straight to p=reject and discovering you've been blackholing a third of your real mail. The right approach takes about a month.

1. Week 1: publish p=none. Set up 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. Identify every IP and source domain that sends mail under your name. Confirm each is legitimate. For the legitimate ones, fix SPF and DKIM so they align. For unknown ones, investigate.
3. Week 4: move to p=quarantine; pct=10. A small slice of failing mail goes to spam folders. Watch the reports for a week.
4. Week 5: ramp pct= to 25, then 50, then 100.
5. Week 6+: 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 domain sending more than 5,000 messages a day to a Gmail or Yahoo address to publish a DMARC policy of at least p=none. They also require alignment between From: and either SPF or DKIM. Microsoft is moving in the same direction. Without DMARC, your mail is increasingly going to spam regardless of how much effort you put into the rest of the stack.

Beyond pure deliverability, a strong DMARC posture is a brand-protection measure. It makes it materially harder for criminals to send phishing emails that appear to come from your domain — and it gives you the visibility to spot them when they try.

Tools we actually use

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

For a deeper read, see our guides on parsing DMARC aggregate XML and on the complete authentication stack.