p=none, quarantine or reject: which to choose

The DMARC policy is the instruction you publish for mail servers everywhere. It applies only to messages that fail DMARC, meaning those where neither SPF nor DKIM is both valid and aligned with the displayed domain. A correctly configured legitimate message is never affected, whatever the value.

This is the most expensive misunderstanding in the subject. A domain at p=none has a valid DMARC record, shows as “compliant” in most online checkers, and ticks the box on insurance questionnaires. It blocks not one spoofed message.

p=none exists for one reason: discovery. During the first weeks of a rollout it brings in the daily reports that reveal which services legitimately send in your name, without risking blocking one of them by mistake. It is scaffolding. Scaffolding left up for three years is no longer scaffolding, it is an admission.

The Google, Yahoo and Microsoft requirements for high-volume senders ask for “at least p=none”. That phrasing is often read as a recommendation; it is an eligibility floor, not a target.

Quarantine is a stage, not a destination. It has a real virtue during rollout: if a legitimate sender has been missed, its messages land in the recipient's junk folder instead of vanishing, and somebody eventually notices.

Its weakness is the same fact: the message stays reachable. A client expecting an invoice who does not see it arrive goes looking in their junk folder, finds it, and acts on it. Against bank-detail fraud, quarantine only slows things down.

The pct= tag gives the share of failing messages the policy applies to, from 1 to 100. It defaults to 100. Its purpose is gradual tightening: p=quarantine; pct=25 junks a quarter of failing messages and lets the other three quarters through.

The trap is in the fallback. Messages not selected by pct= are not treated as though the policy were none: they get the next policy down. With p=reject; pct=25, a quarter of messages are rejected and the other three quarters are quarantined, not delivered. It is reasonable behaviour, and it is almost never what people expect.

Without sp=, subdomains inherit the policy published on the parent domain. That is the desirable behaviour in nearly every case: a fraudster who cannot spoof example.com will try accounts.example.com, which has never existed and which nobody watches.

sp= serves the opposite exception: a subdomain sending through a provider that is not yet aligned, which you want to leave in monitoring while the parent domain is already rejecting. It is a temporary measure, to be documented and dated, or it becomes a door left open.

1. The domain sends no email at all (parked, defensive registration, old trading name): publish p=reject immediately, with an empty SPF record. No monitoring period is needed, since there is nothing legitimate to break.
2. The domain sends and you do not yet know all its senders: p=none with rua, for two to four weeks. No longer.
3. The reports are clean and every legitimate sender is aligned: p=quarantine for one to two weeks, watching.
4. Nothing has moved the wrong way: p=reject, then adkim=s; aspf=s once rejection has settled.

The detailed procedure, with what to check at each stage, is in the article on moving to rejection.

The policy applies only to messages displaying exactly your domain. A message from a cousin domain is unaffected, whatever the value of p=: it does not fail your DMARC, it never meets it.

It is also an instruction, not a guarantee of enforcement. Nearly all world mail volume is handled by servers that honour it, but a poorly maintained company mail server may simply ignore it.