Moving DMARC from p=none to p=quarantine without losing mail

If you published a DMARC record at p=none, you did the right thing. The mistake is treating it as the finish line. p=none asks receiving servers to report what they saw and to change nothing about how they handle it — which means anybody can still send mail as your domain today and have it delivered to the inbox.

The reason people stay there is reasonable: tightening the policy feels like it risks real mail, and there is no obvious signal for when the risk has passed. There is one, though, and it is sitting in the reports you asked for.

What the reports actually contain

The rua address in your record receives aggregate reports: one XML file per receiving provider per day, each summarising every message that claimed to be from your domain. They are not readable as sent — they arrive gzipped, and a busy domain gets dozens a day — but what they contain is simple. For each sending IP address: how many messages, whether SPF passed, whether DKIM passed, and what the receiver did about it.

You are looking for exactly one thing: a sending source you recognise that is failing both checks. That is a system of yours which would start being filtered the moment you tighten. Everything else is either already passing, or is not you.

Do not point rua at your main inbox. Use a dedicated address, or one of the free aggregators that parses the XML into something a human can read. A fortnight of raw reports in your working inbox is how this project gets abandoned.

The sources that surprise people

Almost every domain discovers at least one legitimate sender it had forgotten. In rough order of how often they turn up:

• The invoicing or accounting tool, which sends from its own servers with your address in the From header.
• A contact form on the website, configured to send as the visitor rather than as the site.
• Newsletter software set up once and never revisited.
• A CRM or helpdesk that sends replies on your behalf.
• The previous mail host, still relaying mail nobody noticed was still flowing.
• A printer, scanner or alarm system on the office network with an SMTP configuration from years ago.

Each one needs the same decision: either authorise it properly — add it to SPF, or better, have it sign with DKIM — or confirm it should no longer be sending and turn it off. What you must not do is widen SPF to cover something you cannot identify. An include: you do not understand is a permanent hole in the thing you are building.

The condition for moving to quarantine

Move when all of the following are true, and not before:

1. You have at least ten to fourteen days of reports, covering a normal working period rather than a holiday.
2. Every sending source producing meaningful volume is one you can name.
3. Each of those passes SPF or DKIM — alignment matters: the passing domain has to match the domain in the From address, not merely pass in isolation.
4. Anything failing is either a source you have deliberately shut off, or traffic that is not yours.

The third point is where most domains quietly fail. A message can show spf=pass for the sending provider's own domain while the From address says yours — that is a pass without alignment, and DMARC counts it as a failure. Check the reports for alignment, not just for the word pass.

Tightening in stages

There is a percentage dial most people never use. pct applies the policy to a sample of mail, which makes the change reversible in practice rather than only in theory:

At pct=25, a quarter of failing mail is quarantined and the rest is delivered as before. If you broke something, a quarter of the complaints arrive instead of all of them, and you have the evidence without the full cost. Raise to 50, then 100 over a couple of weeks, watching the reports after each step.

Only after a fortnight at p=quarantine; pct=100 with nothing legitimate failing is p=reject a reasonable next move. Quarantine means a forged message reaches the recipient's junk folder, where a determined reader will still find it; reject means it is never accepted at all. Reject is the destination, but arriving there early is how a business loses a week of order confirmations and only finds out when a customer calls.

What to keep afterwards

Keep rua in place permanently. The reports are the only way you will find out that a new tool someone signed up for is sending as your domain and failing — and that discovery is worth more once the policy is enforcing than it was while it was merely listening.

Keep fo=1 as well. It asks for a report when either check fails rather than only when both do, which is what makes an alignment problem visible before it becomes a delivery problem.