Glossary · Deliverability

DMARC

Also: Domain-based Message Authentication, Reporting and Conformance

Definition

DMARC is a DNS policy that tells receiving mailbox providers how to handle mail claiming to be from your domain when it fails both SPF and DKIM alignment — and where to send reports about those failures.

DMARC sits on top of SPF and DKIM. Those two prove that a message was authorised by, or signed on behalf of, some domain. DMARC adds the two things they are missing: a policy for what to do when they fail, and reporting so you find out that they are failing.

It is published as a single TXT record at _dmarc.yourdomain.com.

Alignment is the part that catches people

A message can pass SPF and still fail DMARC. This surprises almost everyone the first time.

SPF authenticates the envelope sender — the return-path — and DKIM authenticates the domain in the signature. DMARC requires that one of those aligns with the domain in the visible From: header, the one the recipient actually sees.

So if your mail sends from [email protected] but the return-path is on your provider’s domain and the DKIM signature is your provider’s key, both checks pass and DMARC still fails. The fix is to authenticate on your own domain: a verified sending domain, your own DKIM key, and a return-path subdomain you control.

The three policies

  • p=none — take no action, but send me reports. Changes nothing about delivery. This is where you start.
  • p=quarantine — treat failing mail as suspicious, typically the spam folder.
  • p=reject — refuse failing mail outright.

The correct rollout is none → quarantine → reject, moving on only once reports show that all your legitimate mail passes. Going straight to reject reliably blackholes something you forgot about — an invoicing system, a recruitment tool, a form on an old microsite.

DMARCbis changed the record format

DMARC was respecified in RFC 9989 (2026), which obsoletes the original RFC 7489. Existing v=DMARC1 records keep working, but three things changed that most published guidance has not caught up with:

  • The pct tag was removed. Partial rollout is now expressed with a new t (test mode) tag: t=y tells receivers not to enforce the stated policy, t=n — the default — applies it.
  • A new np tag sets the policy for non-existent subdomains independently of the parent. Publishing np=reject is a cheap way to shut down spoofing of subdomains you have never used.
  • The Public Suffix List is replaced by a DNS tree walk for working out the organizational domain, and a psd tag flags public suffix domains.

If a tool or article is still telling you to set pct=, it predates the current standard. Our DMARC record generator follows RFC 9989.

Why it increasingly is not optional

Major mailbox providers have moved from treating DMARC as a nice-to-have to requiring it of bulk senders. If you send marketing volume to Gmail or Yahoo addresses without a DMARC record, expect placement to suffer regardless of how clean your list is.

For multi-brand senders

Each brand should authenticate as itself. If several brands share one sending domain, they share one DMARC policy and one reputation — so the least careful brand sets the ceiling for the most careful one. Verify a sending domain per brand and the policy follows the brand it belongs to.

Bring your provider.
Keep your brands distinct.
Start today.

Set up your first workspace, connect a provider, and publish a workflow — free, in test mode, before you pay a thing.