What is DMARC, and how to set it up without breaking your mail

BySaaS

DMARC is a DNS record that tells receiving mail servers two things: what to do with mail that claims to come from your domain but fails authentication, and where to send reports about it. It is built on top of SPF and DKIM rather than replacing them, and the part that trips people up is not the record syntax — it is alignment.

The one concept that matters: alignment

SPF and DKIM each validate something, but neither validates the address your recipient actually sees.

  • SPF checks the envelope sender — the Return-Path, which the recipient never sees.
  • DKIM checks a cryptographic signature, and the signature declares its own domain in a d= tag, which need not match anything visible either.

So a spammer could pass SPF for their own domain while the From header reads ceo@yourcompany.com. Both checks pass. The mail is still forged.

DMARC closes that gap by requiring alignment: the domain that passed SPF, or the d= domain that signed with DKIM, must match the domain in the visible From header. A message passes DMARC if at least one of SPF or DKIM passes and aligns. One is enough — you do not need both.

Alignment comes in two modes. Relaxed (the default) accepts an organisational-domain match, so mail.yourcompany.com aligns with yourcompany.com. Strict requires an exact match. Relaxed is right for almost everyone.

The record

A TXT record published at _dmarc.yourdomain.com. The minimum useful version:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The tags worth knowing:

  • v=DMARC1 — required, and must come first.
  • p= — the policy: none, quarantine or reject.
  • rua= — where aggregate reports go. Without this you are flying blind.
  • sp= — a separate policy for subdomains. If omitted, subdomains inherit p=.
  • pct= — apply the policy to a percentage of failing mail, for staged rollout.
  • adkim= / aspf= — alignment mode, r relaxed (default) or s strict.

The three policies

p=none — monitor only. Receivers change nothing but send you reports. This is where every domain should start, and it is also where a great many domains wrongly stop.

p=quarantine — failing mail goes to spam. The intermediate step.

p=reject — failing mail is refused at the door. The goal, and the only policy that actually prevents your domain being used to spoof.

Rolling it out without breaking your own mail

The failure mode of DMARC is going straight to p=reject and discovering that a legitimate service — a CRM, an invoicing tool, a helpdesk — has been sending as your domain without alignment. That mail now vanishes.

  • Publish p=none with rua=. Change nothing else.
  • Read the reports for two to four weeks. They arrive as XML; several free parsers will render them. You are looking for every source sending as your domain, and which of them align.
  • Fix the legitimate ones — usually by configuring DKIM signing with your domain at each third-party sender.
  • Move to p=quarantine, optionally with pct= to ramp. Keep reading reports.
  • Move to p=reject once the reports show only sources you recognise, all aligning.

Why DKIM matters more than SPF here

Forwarding breaks SPF. When a recipient auto-forwards your message, the forwarding server becomes the sender and SPF fails for your domain — nothing is wrong, that is simply how SPF works. DKIM survives forwarding, because the signature travels with the message as long as the content is not modified.

Since DMARC needs only one of the two to pass and align, a correctly aligned DKIM signature is what keeps forwarded mail alive. If you set up only one properly, set up DKIM.

Two traps worth knowing

The SPF ten-lookup limit. An SPF record may trigger at most ten DNS lookups when evaluated. Each include: costs at least one, and each of those may chain further. Exceed ten and the result is a permanent error, which under DMARC counts as an SPF failure. Adding one more SaaS tool to an SPF record is a common way to silently break authentication for everything.

Subdomains inherit your policy. If you publish p=reject at the organisational domain and omit sp=, every subdomain inherits it — including ones you forgot about. Cold email sent from a separate subdomain is covered by the parent policy whether or not you configured it.

Is DMARC required?

Effectively, yes. Since February 2024 Google and Yahoo have required bulk senders — broadly, those sending 5,000 or more messages a day to their users — to publish SPF, DKIM and DMARC, alongside one-click unsubscribe on marketing mail and a user-reported spam rate below 0.3%.

Most cold email operations fall under the volume threshold, so the requirement does not bind them directly. It has still changed the baseline: a domain with no DMARC record now looks unusual to the systems doing the filtering, and unusual is not where you want to be when a filter is deciding about you. Publishing p=none with reporting costs nothing and takes ten minutes.

Authentication is a prerequisite rather than a result — it gets you considered, not delivered. What happens after that is measured differently, and the deliverability testing guide covers what can and cannot be measured. For the tools that do the sending, see the cold email hub.

Similar Posts