DMARC p=none under RFC 9989: what it means
If the email-posture checker reports p=none, your domain has published a DMARC monitoring policy. It requests no DMARC enforcement action from receivers, but it can still provide valuable visibility when aggregate reporting is configured and actively reviewed.
What the three policies actually do
DMARC lets a domain owner publish a requested handling policy for messages that fail DMARC validation. Receivers retain local discretion and can consider other signals:
- p=none — monitoring mode; no DMARC enforcement action is requested.
- p=quarantine — request that failing mail receive suspicious treatment, commonly spam placement.
- p=reject — request rejection of failing mail during SMTP handling.
A p=none policy does not ask a receiver to quarantine or reject a message because it failed DMARC. It does not guarantee inbox delivery either: reputation, content and the receiver's own policy still apply.
So why does p=none exist?
Because turning on enforcement blindly breaks things. Most organisations send legitimate mail from more systems than they realise — the CRM, the invoicing platform, the recruitment tool, the marketing service, the monitoring alerts. Every one of those needs to be authorised in SPF or signed with DKIM.
p=none is a legitimate monitoring mode. You publish it, collect aggregate reports and discover legitimate or unauthorised sources using the domain. The operational problem is leaving it unattended: a monitoring policy without report analysis produces visibility that nobody acts on.
How to move to enforcement without breaking mail
- Add an aggregate-report destination such as
rua=mailto:dmarc@yourdomain.comand ensure the mailbox or reporting service is prepared for XML reports. - Collect enough representative data to cover routine systems, seasonal campaigns and third-party senders.
- Inventory every legitimate source and confirm whether SPF or DKIM passes with alignment to the visible From domain.
- Fix unauthenticated or unaligned sources. Watch the SPF ten-DNS-lookup limit and prefer aligned DKIM where practical.
- Move a controlled subdomain or lower-risk mail stream to
p=quarantine, then evaluate authentication and delivery evidence. - Expand enforcement through deliberate DNS changes, sender segmentation and rollback plans—not the legacy
pcttag, which RFC 9989 removed. - Move to
p=rejectwhen legitimate mail is consistently aligned and monitoring shows that enforcement is safe.
While you are in there: SPF
The checker distinguishes ~all (soft fail) from -all (fail) and counts top-level DNS-lookup mechanisms. That is only a screening check. A complete SPF audit must recursively expand includes and redirects, account for void lookups and confirm every actual sending path.
The thing worth internalising
DMARC reduces unauthorised use of the exact visible From domain. It does not stop lookalike domains, display-name impersonation or mail sent from a compromised legitimate account. Pair authentication with secure mailbox controls, payment-verification procedures and user reporting.