DMARC in three steps: from p=none to reject without breaking email

A DMARC record with p=none is a monitoring instruction. It asks receiving mail servers to report abuse and explicitly tells them not to act on it. That is a sensible first step and a poor final state.

Step one: publish, and read the reports

Start at p=none with a reporting address (rua). Aggregate reports arrive as XML and are unreadable without a parser — which is why so many organisations publish the record and never look again.

What you are looking for is the complete list of legitimate senders: your mail provider, your CRM, ticketing, payroll, any application that sends as your domain.

Step two: align the senders

The failures at this stage are almost always third-party senders who send as your domain without SPF or DKIM alignment. Options:

• Add them to SPF, staying under the ten-DNS-lookup limit.
• Have them DKIM-sign with a key on your domain.
• Move them to a subdomain that carries its own policy.

A subdomain policy is often the cleanest fix. p=reject on mail.example.com stops abuse of that subdomain without endangering your primary domain.

Step three: move the policy, then move it again

Go to p=quarantine first and watch delivery of legitimate mail for a week or two. Then p=reject. If you need a staged rollout, use pct to apply the policy to a percentage of mail — but do not leave pct below 100 indefinitely, because it means part of your impersonation is still delivered.

The part people skip

Enforcement is not a project with an end date. New senders appear, marketing tools change, an acquired entity keeps sending from an old platform. The record stays correct only if someone is reading the reports.

That is the difference between a one-time configuration and monitoring — and the reason a check on its own is not protection.