Moving DMARC from monitoring to enforcement without losing mail

A DMARC record at p=none protects nobody. It asks receivers to report on what they see and then deliver the message anyway, so anyone can still put your domain in the From header of a fake invoice. Enforcement — quarantine or reject — is the part that does something.

The reason so many domains never get there is a legitimate fear: turn on enforcement before you have found every system that sends as you, and you will silently destroy a mail stream that someone depends on. The way through is to make the invisible senders visible first.

Stage 1: publish p=none with reporting

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

This changes nothing about delivery. It asks participating receivers to send you a daily XML summary of every message claiming to be from your domain, and whether it passed SPF and DKIM with alignment.

Two warnings. First, if rua points at an address on a different domain, that domain has to publish an authorisation record at yourdomain.com._report._dmarc.theirdomain.com or conforming receivers will not send reports at all. Second, the reports are gzipped XML arriving from dozens of senders daily. Unless you intend to parse them, use a reporting service — several have free tiers for a single domain.

Stage 2: read the reports until nothing surprises you

Give it at least two weeks, ideally a full monthly cycle so that anything which only runs at month end shows up. You are building one list: every source IP sending as your domain, and for each one, what it is and whether it should be.

Expect to find things nobody mentioned:

• An invoicing or accounting system sending statements.
• A helpdesk or CRM sending as individual staff addresses.
• A print or mailing house sending on your behalf.
• A form on an old website relaying through a web host.
• Forwarded mail, which breaks SPF by design and is not an attack.
• Genuine spoofing, which is the thing you are trying to stop.

The judgement call at this stage is between an unknown-but-legitimate sender and an attacker. Volume, consistency and the reverse DNS of the sending IP usually settle it.

Stage 3: fix the legitimate senders

Every legitimate source has to pass SPF or DKIM with alignment before you tighten the policy. In practice this means, for each platform:

• Configure a custom sending domain on the platform, so DKIM signs with d=yourdomain.com rather than the platform’s own domain.
• Publish the DKIM public key the platform gives you, usually as a CNAME to a record they host so they can rotate it.
• Add the platform to SPF only if it cannot sign with DKIM — the lookup budget is limited and DKIM alignment is more robust, particularly across forwarding.

Watch the SPF lookup count while you do this. Adding a fourth or fifth include is exactly how a record tips over ten lookups and starts returning permerror.

Stage 4: quarantine before reject

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Quarantine sends failing mail to junk rather than refusing it. If you have missed a sender, the mail is recoverable and someone will tell you — which is a much better failure mode than a bounce nobody sees.

Sit here for a couple of weeks and keep reading the reports. Some teams use pct= to phase the policy in gradually, but receiver support for intermediate percentages is inconsistent and the tag is being phased out of the specification. Treat it as a short rollout aid at most.

Stage 5: reject

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com

Note sp=reject. Subdomains inherit p= when sp is absent, but setting it explicitly makes the intent clear and protects subdomains that have never sent mail and never should — which is where spoofing tends to move next.

Two things enforcement will not fix

Lookalike domains. DMARC protects the exact domain in the From header. It has nothing to say about yourc0mpany.com or yourcompany-invoices.com. Those need registration monitoring, and staff who know to check.

Display-name spoofing. A message from attacker@gmail.com with the display name “Your CEO” passes DMARC perfectly, because it is honestly declaring a Gmail origin. That is a mail-client and training problem, not a DNS one.

Keep reading the reports afterwards

Enforcement is not a finished state. Someone will sign up for a new platform in six months and send as your domain without telling anyone, and the only way you find out before a customer does is that the reports are still being read.