The p=none policy has a specific purpose: discovering what's sending email from your domain before you start blocking anything. It's meant to be temporary as it allows your domain to be used in a spoofing attack. But too often, domains stay on p=none indefinitely - or regress to p=none because of a change in provider or service.
Initial DMARC setup. You've just added a DMARC record to a domain that's never had one. You don't know what's sending email. Starting with p=none lets you collect reports and build a picture before enforcement.
Inheriting a domain with p=none. MSPs onboarding new clients often face undocumented email configurations. If a domain is handed over with p=none, review reports after a few weeks and then change to an enforcement policy.
The common thread: p=none is for learning, with a clear timeline to enforcement.
Once you're at p=quarantine or p=reject, there's rarely a good reason to go backwards.
Adding a new sender. You've had DMARC enforced for months. Now you're adding an Email Service Provider (ESP) or CRM that sends email. The temptation is to drop to p=none "just to be safe" while setting it up.
Don't. Configure SPF and DKIM for the new sender correctly, verify alignment in your reports, and keep your policy where it is. Adding one sender isn't starting from scratch.
Changing DNS provider. DNS records can be lost during provider transfers. Keep a record of your DMARC configuration before migrating, and verify it's restored correctly afterwards—don't assume the policy carried over.
Switching DMARC reporting providers. Migrating platforms means updating the RUA address in your DNS record. That's it. Your policy stays exactly the same - a domain at p=reject stays at p=reject. The reporting destination has nothing to do with enforcement. The VerifyDMARC DMARC record generator auto selects the same policy if there is an existing DMARC record.
Following bad ESP advice. All too often, email service providers tell customers to change their DMARC record to p=none when troubleshooting deliverability. This shifts the problem from their platform to your domain's security. If an ESP hasn't verified proper DKIM setup before sending, that's their configuration to fix - not a reason to weaken your policy.
This is more acute when using p=quarantine - with p=reject the new email service will never deliver email, even to junk, which is much clearer during implementation and testing. We recommend using p=reject over p=quarantine.
Including a pct tag in the DMARC record and setting it to anything less than pct=100 can have the same effect of bypassing DMARC enforcement. Most domains do not have a good use for the pct tag, so VerifyDMARC flags any domain with the tag and not set to 100 with a warning status.
Someone reaches p=reject, something changes, frustration sets in, and they drop to p=none. This removes DMARC protections and allows attackers to spoof the domain.
Correctly configure new sending services instead and verify DMARC compliance during your testing phase.
VerifyDMARC's Domain Setup Regression Alerts catch these downgrades before they become entrenched.
Sign up for our 30-day free trial to ensure you maintain continuous DMARC protection.
To fix "does not meet the required authentication level" from Microsoft, you need a DMARC record, SPF and DKIM passing, plus SPF or DKIM alignment.
We're excited to announce two new Insight reports designed to streamline multi-domain management: Sender Compliance Report and SPF Record Checker.
Managing DMARC for many domains has traditionally been complex and costly. VerifyDMARC addresses this with a unified, cost-effective solution for MSPs.