Dmarc Quarantine Reject Policy Not Enabled: The Real Fix
The finding reads like a checkbox: dmarc quarantine reject policy not enabled. It arrives in vulnerability scans, pentest reports, email security graders, and compliance questionnaires, and it tempts exactly one response - change one word in DNS so the scanner goes quiet. That word-change is real (the finding is legitimate and worth fixing), but done on day one it is also the most reliable way to bounce your own invoices, password resets, and newsletters in production. This guide decodes what the scanner actually checked, why the naive fix backfires, and the sequence that clears the finding without an outage - including the legitimate fast path for domains that send no mail at all.
What the scanner checked, literally
The tool looked up the TXT record at _dmarc.yourdomain.com and found one of two things: no DMARC record at all, or a record whose policy tag is p=none. Either way, the conclusion is the same - your domain currently tells the world's mail receivers to deliver mail that fails authentication normally. A phisher can put your exact domain in the From line of a message, fail SPF, DKIM, and alignment completely, and your published policy asks Gmail to deliver it anyway.
That is the risk being flagged: spoofability. Business email compromise and phishing campaigns lean on exactly this gap, and it is why frameworks keep tightening around it - the US government's CISA directive has required p=reject on federal domains since 2017, and cyber-insurance questionnaires and vendor security reviews increasingly ask the same question the scanner does. The finding is not noise. The timeline the scanner implies - fix it now - is the part that needs adult supervision.
Why you cannot just flip to p=reject today
A DMARC policy of quarantine or reject punishes every message that fails aligned authentication - and it cannot tell a criminal from your own marketing platform that never got its DKIM keys configured. Most domains that have never run DMARC have no idea what sends on their behalf: the CRM, the billing system, the support desk, the HR platform, a contractor's mail-merge tool, an office scanner. Publish p=reject blind and every one of those streams that isn't aligned starts bouncing simultaneously, and you learn your sender inventory from angry coworkers instead of reports.
So the real fix is a sequence, not a setting. Each stage below is a one-line DNS record; the work between the lines is reading what comes back.
The safe path to a policy the scanner accepts
| Stage | Record | Duration | What you're doing |
|---|---|---|---|
| 1. Observe | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com |
2-4 weeks | Collecting the sender inventory |
| 2. Align | (unchanged) | days-weeks | Fixing SPF/DKIM per legitimate stream |
| 3. Quarantine | v=DMARC1; p=quarantine; rua=... |
1-2 weeks quiet | Failures go to spam; watching for stragglers |
| 4. Reject | v=DMARC1; p=reject; rua=... |
permanent | Finding cleared; spoofing stopped |
Stage 1 publishes p=none with a rua reporting address. Delivery changes for nobody - but every major receiver starts sending you daily aggregate XML reports listing each IP that sent mail as your domain and whether it passed. (Raw XML is unpleasant; free and paid DMARC report viewers turn it into a sender table.) Note honestly: this stage does not clear the scanner finding - p=none is precisely what it flags - but it is the stage that makes clearing it safe.
Stage 2 is the actual work: for each legitimate stream the reports reveal, get SPF or DKIM passing with alignment - the platform signs with your domain, or its envelope domain aligns. Streams you don't recognize get investigated; some turn out to be shadow IT, some turn out to be the spoofing the whole exercise exists to stop.
Stage 3 moves to p=quarantine once reports show your legitimate streams clean. Failures now land in spam folders - annoying if you missed something, recoverable. Some teams step through pct=25 then pct=100; fine, with the caveat that partial percentages behave inconsistently across receivers.
Stage 4, after quarantine runs quiet, is p=reject. The scanner finding clears, and - the actual prize - spoofed mail claiming your domain stops arriving anywhere that honors DMARC.
Re-run the original scan (or dig TXT _dmarc.yourdomain.com) to confirm the finding closes. Total calendar time for a typical small business: three to six weeks, most of it waiting on reports while normal mail flows untouched.
The fast path: domains that send nothing
Parked domains, defensive registrations, and dormant brand domains have no legitimate senders to break - and they are also favorite spoofing targets precisely because nobody watches them. For these, skipping the sequence is correct: publish v=DMARC1; p=reject; immediately, alongside an SPF record of v=spf1 -all (authorizing no one). Every domain your organization owns but doesn't mail from can be hardened in an afternoon, and scanners covering your whole domain portfolio go green on those instantly.
Two ways teams game the finding, and why not to
The first dodge is publishing p=quarantine; pct=0 - technically an enabled quarantine policy applied to zero percent of mail. Some scanners accept it; receivers treat it inconsistently (and a zero-percent quarantine famously behaves as sp=none inheritance bait); and it protects nothing, which the next pentest writes up with less patience. The second dodge is setting p=reject on the apex while sp=none leaves every subdomain wide open - scanners increasingly check the subdomain policy too, and spoofers moved to subdomains years ago. Both dodges spend effort adjacent to the real fix without buying its protection; the staged rollout above costs a few weeks and buys the actual thing.
The finding, decoded, is an invitation: your domain is one of the shrinking number that a stranger can still impersonate for free. Close it in stages and the checkbox turns green as a side effect of the protection being real.
Frequently asked questions
Is 'DMARC quarantine/reject policy not enabled' a real vulnerability?
It is a legitimate hardening gap: with no policy or p=none, receivers deliver mail that fails authentication normally, so your domain can be spoofed. It is not an exploit in your systems, but it is worth closing properly.
Can I just set p=reject to clear the finding?
Only for domains that send no mail at all - park those at p=reject with v=spf1 -all immediately. For a sending domain, run p=none with reports first, align every legitimate sender, then step through quarantine to reject.
Does publishing p=none clear the scanner warning?
No - p=none is exactly what the scanner flags. It is still the correct first step, because its aggregate reports give you the sender inventory that makes quarantine and reject safe to publish.
How long does it take to reach p=reject safely?
Typically three to six weeks: two to four weeks reading reports at p=none, days to fix sender alignment, then a quiet week or two at quarantine before finishing at reject.