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 nonequarantinereject, 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.