Getting DMARC from p=none to p=reject without losing mail

Most domains that publish DMARC publish p=none, and stay there. It feels like progress and it stops nothing: none asks receivers to report what they see and to deliver the mail either way. Anyone can still send as your domain and it will still arrive.

What the policy actually instructs

DMARC has three settings, and they are instructions to the receiving mail server about messages that fail authentication.

• p=none — deliver as normal, and send me a report. A monitoring position, not a control.
• p=quarantine — treat as suspicious. In practice, the spam folder.
• p=reject — refuse at the SMTP conversation. The forged message is never delivered anywhere.

Only the third stops someone sending invoices in your name. That is the destination, and everything before it is scaffolding.

Why it fails when people rush it

A message passes DMARC when SPF or DKIM passes and aligns with the domain in the visible From header. The trap is that mail you did not think about is sent on your behalf: the invoicing system, the CRM, the marketing platform, the ticketing tool, the monitoring alerts. Each sends as your domain from infrastructure that is not yours.

Go straight to p=reject and every one of those that is not aligned stops being delivered, usually on a Monday, usually to a customer.

The order that works

1. Publish p=none with reporting. The point is the rua address, not the policy: v=DMARC1; p=none; rua=mailto:[email protected].
2. Read the reports for two to four weeks. They are XML. A parser or a hosted service turns them into "these seventeen senders use your domain", which is the list you actually need and almost certainly longer than you expect.
3. Fix each legitimate sender. Add it to SPF, or better, have it sign with DKIM using a subdomain key you control. DKIM survives forwarding, which SPF does not.
4. Move to quarantine with a percentage. p=quarantine; pct=25 applies the policy to a quarter of failing mail. Watch, then raise it.
5. Reject. Only when the reports show no legitimate sender failing.

How to validate where you stand

dig +short TXT _dmarc.example.com
dig +short TXT example.com | grep spf1

Three things decide whether the policy means anything. The p tag — a record with no p is treated as none. The pct tag — p=reject; pct=10 rejects one message in ten and looks like enforcement in a dashboard. And sp, the subdomain policy: without it, subdomains inherit, and a forgotten mail.example.com is a forger's way in.

Count your SPF lookups too. The limit is ten DNS lookups, not ten entries, and each include: can bring its own. Past ten, the record is a permanent error and SPF fails for everyone.

How it helps your infrastructure

At p=reject, a forged invoice from your domain is refused before it reaches anybody. That is worth more than most controls of comparable effort, because it protects people who do not work for you and cannot be trained — your customers, who cannot tell a real invoice from a copy.

The secondary benefit is deliverability. Providers weight authenticated, aligned mail from domains with an enforcing policy more favourably. The domain that reaches the inbox is usually the one nobody can imitate.

Email & DNS Lookup shows your policy, whether the percentage limits it, whether subdomains are covered, and the SPF lookup count that decides whether any of it works.