From p=none to p=reject: a step-by-step plan without dropping legitimate mail

22 October 2026

Teams stay on p=none because reject feels binary: one unknown ESP and invoices bounce. The safe path is report-driven: see every aligned passer, clear static blockers, then raise policy in stages a human approves. Finding DMARC_POLICY_NONE on the free audit means monitoring only—not that DNS is broken.

Why not jump to reject

Unnamed third-party senders still pass SPF/DKIM in the wild.
SPF PermError or +all makes enforcement dishonest.
Subdomain sp= weaker than p= leaves forgeable edges.

Transition plan

Publish working rua. Fastest path: Hosted DMARC CNAME so reports land at reports.senderidentity.com and the sender inventory builds in Account.
Keep p=none until every significant passer is named (SPF ip4/ip6 or published DKIM selector). Unnamed passers block a safe move off none in the Hosted DMARC wizard.
Clear free-audit blockers: no SPF_LOOKUP_LIMIT, no +all, valid single DMARC record.
Approve quarantine at 25%, then 50%—operators may publish these; watch fail volume and support tickets.
Account owner approves p=reject only when readyToReject is clear. Calendar days never publish a tighter record by themselves.
If a later report shows alignment failures, saved reject approval is voided; the published TXT stays until you act again.

Where Hosted DMARC helps

Self-hosted rua mailboxes drown in XML. Hosted DMARC turns aggregates into a sender list, stages policy with named reviewers, and keeps the customer zone to one CNAME. That is the practical answer to “we are afraid of reject.”

Shorter explainer: DMARC is still p=none. Bulk-sender context: 2026 Google & Yahoo checklist.