It means your domain is at p=none — monitoring only — and the scanner wants you at enforcement. Nothing is broken right now. You have a finding, not an outage.
Got this as a bounce message instead? Jump to the bounce-message section →
“Quarantine/reject policy not enabled” is how scanners describe a DMARC record where the policy tag is p=none. Your record exists. It’s being read. It just tells receiving mail servers to observe failures and report them — not to filter or reject anything.
The scanner wants you at p=quarantine (failing mail goes to spam) or p=reject (failing mail is blocked outright). Those are the policies that actually stop someone from spoofing your domain.
p=none is a correct starting point, not a misconfiguration. It’s an unfinished journey. The job in front of you is moving from monitoring to enforcement without breaking legitimate mail along the way.
Different scanners, different forms, same underlying ask: move past p=none.
Vendor risk platforms, attack-surface scanners, and email posture tools all flag p=none as "DMARC not enforced." They’re reading your DNS record and grading you on the policy tag.
Carriers increasingly ask whether DMARC is at p=quarantine or p=reject as a prerequisite for renewal or for a preferred premium tier. p=none gets scored as "not implemented."
Procurement and security-review checklists for large customers often require DMARC enforcement before they’ll accept mail from you or list you as an approved sender.
Showing your logo next to your name in Gmail, Apple Mail, and Yahoo requires DMARC at p=quarantine or p=reject. BIMI readiness checks fail on any domain at p=none.
Google and Yahoo require DMARC for senders above 5,000 messages a day, and Microsoft has telegraphed the same direction. A published record meets the minimum — enforcement is where the protection actually lives.
If you do, the mail you break isn’t the mail you think about. It’s the marketing tool the comms team set up a year ago. The regional office on a local relay. The invoicing platform billing your customers. The helpdesk ticket replies routing through a forgotten SaaS. p=reject doesn’t care that those senders are legitimate — it cares only that they aren’t aligned. The fix is identifying every one of them before you advance the policy, not after the bounces start.
Three policies, one direction. You don’t skip steps — you advance through them as your data clears each gate.
p=none
Monitoring only
Receiving servers deliver every email normally and send you aggregate reports about who passed and who failed authentication. No mail is blocked or filtered. This is what your scanner sees and flags.
You should be here for at least 30 days while you discover every legitimate sender and clean up SPF/DKIM. p=none is a starting point, not a misconfiguration — the real problem is when domains stay here forever.
p=quarantine
Send failures to spam
Mail that fails DMARC alignment lands in the recipient’s spam or junk folder instead of the inbox. Any legitimate sender that isn’t fully authenticated will start landing in spam too.
Move here once your authenticated pass rate sits at 95% or higher for 30 straight days with zero unauthorized senders. Roll out with pct=10 first and raise as the data holds.
p=reject
Block failures outright
Receiving servers reject failing mail at the SMTP layer — it never reaches the recipient at all. This is what makes your scanner stop flagging you, and what BIMI and most compliance frameworks require.
Move here after at least two weeks at p=quarantine with no surprise sender failures and no spam-folder complaints from internal users.
Want the deeper explainer with record patterns and the 12 most common pitfalls? See the complete DMARC policy guide.
Whatever flagged you, the DMARC record itself lives at your DNS provider — not inside Microsoft or Google.
Microsoft 365 handles the SPF and DKIM signing for mail you send through Exchange Online, but it doesn’t host your DMARC record. You edit the TXT record at _dmarc.yourdomain.com in your DNS provider (Cloudflare, GoDaddy, Route 53, etc.) and change the p= tag there.
Full Microsoft 365 DMARC walkthrough →Same model: Google Workspace handles SPF and DKIM signing for mail you send through Gmail, but DMARC is published in your DNS. One quirk — if you generate DKIM keys in the Admin console, make sure you’ve activated the new key in DNS before you advance the policy, or properly signed mail will start failing.
Full Google Workspace DMARC walkthrough →The same four steps every domain runs. None of them is “flip a switch.”
Add one DNS TXT record and Verkh starts collecting the DMARC aggregate (RUA) reports your mail receivers already send. No agent, no MX change.
We auto-classify the IPs in your reports against 25+ known providers — Microsoft 365, Google Workspace, SendGrid, Mailchimp, HubSpot, Salesforce, and the rest. Unknown sources get flagged, not buried.
For each failing source you get the specific SPF or DKIM record to publish — plus a shareable page you can hand to the vendor when their support team asks "what do you need from us?"
The readiness panel tracks you against the 30-day / 95% / zero-unauthorized gate and shows which sender is keeping you from the next step. Then walks you through pct= rollouts at quarantine and reject.
The readiness gate is the part most tools skip: 95%+ legitimate pass rate for 30 straight days with zero unauthorized senders, plus a pct=10 rollout when you do advance. That’s how you move past the scanner’s finding without trading it for a deliverability incident.
You probably saw something like “unauthenticated email from is not accepted due to domain’s DMARC policy.” That’s a different situation from the scanner finding above. Pick the branch that matches.
You’re hitting someone else’s DMARC enforcement because your sending domain isn’t fully authenticated. The fix is on your side: align SPF and DKIM for the domain in your From address. Run a free check on that domain to see what’s missing.
Check the sending domain →This is the exact failure mode the safe path prevents. Roll the policy back to p=none, identify the failing source in your aggregate reports, fix authentication for that sender, then advance again — this time with a pct=10 rollout and the readiness gate met.
See the rollback & re-advance steps →No — p=none is the correct starting point for DMARC. It tells receiving servers to deliver mail normally and send you aggregate reports so you can see who is sending as your domain. The problem isn't starting at p=none; the problem is staying there forever. The scanner that flagged you is telling you it's time to move toward enforcement, not that you misconfigured anything.
Most teams clear the path from p=none to p=reject in 4 to 12 weeks once they actively work it. The variance comes from how many senders you have and how cooperative your vendors are. The 30-day floor at 95%+ legitimate pass rate isn't optional — it's the data window you need before you can be confident nothing breaks when you flip to enforcement.
Only if you do it without preparation. Moving from p=none directly to p=reject without identifying and authenticating every legitimate sender will silently kill mail from the senders that weren't fully set up — forgotten SaaS tools, regional offices, the CRM, the invoicing platform. Done correctly, you advance only after the aggregate reports show 95%+ legitimate pass for 30 days, and you use pct= rollouts so the new policy applies to 10% of failing mail first, not 100%.
Reject is the end goal. Quarantine is the staging step you use to gather two more weeks of real-world data before flipping the final switch. If your scanner, insurance form, or BIMI readiness check requires "enforcement," both quarantine and reject technically qualify — but reject is what actually stops spoofers at the SMTP layer and what BIMI logos in Gmail and Apple Mail require.
Your email working fine and your domain being protected are two different things. p=none doesn't stop anyone from sending mail as your domain — it tells receivers to deliver it and report on it. A spoofer impersonating your domain right now would still land in your customers' inboxes. The scan is flagging that gap, not anything wrong with your own outbound mail.
The DMARC record lives at your DNS provider (GoDaddy, Cloudflare, Route 53, etc.), not in the Microsoft admin center. Microsoft 365 doesn't host your DMARC record — it authenticates the mail you send through Exchange Online. You'll edit the TXT record at _dmarc.yourdomain.com and change the p= tag, then verify the change in your reporting tool. The full Microsoft 365 walkthrough is linked below.
Start with a free domain check. See your live record, your unauthenticated senders, and where you stand against the readiness gate.
Or start free monitoring to track this over time. One domain, no credit card.