What is DMARC?

What a DMARC record looks like

• p=: the policy for the domain: none (report only), quarantine (send to spam) or reject (refuse).
• sp=: the policy for subdomains; defaults to the same as p.
• rua=: where aggregate (daily summary) reports go.
• ruf=: where forensic (per-message) reports go; few receivers send them.
• adkim= and aspf=: alignment mode, r (relaxed, organisational domain) or s (strict, exact match).
• pct=: percentage of failing mail the policy applies to; use it only during rollout.

Alignment: why SPF or DKIM passing is not enough

DMARC passes when at least one of SPF or DKIM passes and is aligned: the domain that passed must match the domain in the visible From header. SPF checks the Return-Path domain; DKIM checks the d= signing domain. A newsletter service that uses its own Return-Path and signs with its own domain will pass both checks and still fail DMARC.

DKIM alignment is the one to get right first, because it survives forwarding and SPF does not. That difference decides whether enforcement is safe, and it is worth understanding before you move off p=none — the next two sections explain it. Configure each sending service to sign with your domain.

What "forwarding" means here, and why it is not the Forward button

When you press Forward in Gmail or Outlook, your mail program writes a brand new message from you, with the original quoted or attached underneath. The From header says your address, so it is your domain being authenticated. The original sender’s DMARC never enters into it, and nothing breaks. That is not the forwarding that matters here.

The forwarding that matters is automatic: a mail server receives a message and relays it onward without changing the From header. The recipient still sees the original sender, because as far as the headers are concerned it is still their message. It is simply arriving from somewhere else.

Why forwarding breaks SPF but not DKIM

SPF is a question about the connection: is this IP address allowed to send for this domain? A forwarder relays the message from its own servers, so the IP that connects belongs to the forwarder, not to you, and it is not in your SPF record. Unless the forwarder rewrites the envelope sender to its own domain — a technique called SRS, which many do not implement — SPF fails. Nothing is wrong with your record; the check simply cannot survive the extra hop.

DKIM is a question about the message: here is a cryptographic signature over the body and the important headers, made with a key published in your DNS. A forwarder that passes the message along unchanged passes the signature along with it, and it still verifies, and it still matches the From domain. So DMARC passes on DKIM alone.

That is the whole reason DKIM is worth getting right before you enforce. A domain that passes DMARC only through SPF looks perfect in testing and starts losing mail the moment a recipient forwards it — and under p=reject, losing it means refused at the door, not filed in spam.

DKIM can break in transit too. A mailing list that appends a footer, tags the subject line, or rewrites links has altered what was signed, so the signature no longer verifies and both checks fail. ARC exists to let a trusted forwarder vouch for authentication it saw before it made those changes, but support is uneven, so a list that rewrites messages is still the hardest case.

The part people find uncomfortable: you do not control any of this. Your recipients set up forwarding without telling you — a university address they have kept for twenty years, a role address at their company that fans out to four people, a privacy alias they use for signups. "We do not use forwarding" is not a defence, because it is not your decision.

A worked example: our own domain

astraverify.com publishes p=reject with strict alignment on both checks — about as unforgiving as DMARC gets. Over two weeks our own aggregate reports covered 40 messages. Thirty-three passed both SPF and DKIM. Seven failed SPF and passed DKIM.

Those seven had been relayed by a forwarding service, which is why SPF failed: the connecting IP was the forwarder’s, not Google’s. Every one of them still passed DMARC, because the DKIM signature survived the hop intact. Had our DKIM not been signing, those seven messages would have been rejected outright — not delivered to spam, refused — and we would have had no idea, because the sender never learns that a recipient forwards their mail.

That is roughly one message in six on a domain that sends very little. The proportion is not the point; the point is that it is not zero, and it is invisible without reports.

A safe rollout order

• Publish p=none with an rua address. Nothing changes for your mail; reports start arriving.
• Read the reports for two to four weeks. Fix every legitimate sender that is not aligned (enable DKIM, add SPF includes).
• Move to p=quarantine, optionally with pct=25 then 100.
• Move to p=reject. This is the goal: spoofed mail is refused outright.
• Keep the rua address monitored; new tools that send email will show up there first.

Domains that do not send email

Parked domains, brand variants and typo domains are favourite spoofing targets because nobody watches them. Lock them down with a null MX (0 .), an SPF record of v=spf1 -all, and DMARC p=reject; sp=reject. This is safe immediately because there is no legitimate mail to break.