Back to field guides
Primer · DMARC

What is DMARC, actually?

7 min read·Updated 2026-04

DMARC is the three-letter acronym that decides whether an email claiming to be from your domain actually gets delivered as being from your domain. It sits on top of SPF and DKIM — both of which predate it — and adds the one thing they lacked: an opinion.

The job DMARC was invented to do

Before DMARC (2012), receiving servers had two tools to verify that a message claiming to be from acme.com was actually authorised by acme.com: SPF (a DNS list of authorised sending IPs) and DKIM (a cryptographic signature). Both worked. Both told receivers only what had passed or failed. Neither said what to do when something failed.

So spammers spoofed your domain, SPF said “this didn't come from your authorised servers,” and Gmail's reply was effectively: cool, thanks, I'll deliver it anyway. There was no policy for what should happen on fail. DMARC fixes that.

What a DMARC record actually says

DMARC is a single TXT record published at _dmarc.<your-domain>. Here's a real one:

_dmarc.acme.com.   IN TXT  "v=DMARC1; p=quarantine; pct=100;
                          rua=mailto:dmarc@acme.com; sp=quarantine;
                          adkim=s; aspf=r"

Translated:

Alignment — the part nobody explains right

Most DMARC explainers stop at “DMARC says fail/pass.” That misses the actual mechanism, which is alignment: the visible From: domain has to match the domain that signed (DKIM) or the domain in the envelope sender (SPF).

A message can have a valid DKIM signature from mailchimp.com and pass SPF for mcsv.net, and still fail DMARC if the visible From: header reads marketing@acme.com. The signatures are valid; they're just not aligned to acme.com. Receivers who enforce DMARC will reject it.

This is why most operators' first DMARC report is a horror show. You discover that your own legitimate senders — Mailchimp, HubSpot, your CRM — aren't aligned to your domain by default. Each one needs configuring. DMARC didn't break anything; it surfaced a state of the world that was already true.

The three-policy progression

The expected lifecycle of a DMARC deployment is:

  1. p=none — observation mode. Receivers send you reports but don't enforce. Spend 4–6 weeks here cataloguing every legitimate sender and getting them aligned. Move on as soon as you can; p=none provides no protection.
  2. p=quarantine — failing mail goes to spam folders. Start with pct=10 for a week, then 25, 50, 100. Watch reports for legitimate senders that broke; fix them before raising the percentage.
  3. p=reject — failing mail is bounced at the SMTP layer. End state. Move here once p=quarantine pct=100 has been clean for 2–4 weeks.

Why this matters more in 2026 than it did in 2022

From February 2024, Google and Yahoo require any sender doing more than ~5,000 messages a day to have a DMARC record at p=none minimum. Microsoft signalled similar enforcement later in the year. That's ~70% of US inboxes combined. Without a DMARC record at p=none or stronger, your bulk mail to those providers experiences silent delivery loss — not bounce errors, just gradually worsening inbox placement.

The compliance bar moved. Not theoretical, not aspirational — published, dated, enforced. p=none is now the floor, not the ceiling.

What you actually do next

The two-line plan:

  1. Run our free DMARC analyzer on your domain. It reads what you currently publish and tells you which of the three states you're in (no record /p=none / enforced).
  2. If you have no record, generate one with the DMARC generator. Start at p=none with a rua pointer you control. Publish it. Wait a week. Read the reports.

If reading those reports turns into a job in itself — and for most operators it does, because they arrive as gzipped XML and there are usually 30–200 of them per month per domain — that's the moment you graduate from “doing DMARC manually” to “needing a tool.” That's us.

Things people get wrong

Where to read next