DMARC Quarantine/Reject Policy Not Enabled: What It Means and How to Fix It Safely

You ran your domain through MXToolbox, or a security scanner did it for you, and it came back with a yellow warning: DMARC Quarantine/Reject policy not enabled.

It isn't an error, and nothing is broken right now. What it's telling you is narrower and more specific than most people read it as: you have a DMARC record, the record is syntactically fine, but its policy is set to p=none. Receivers are being asked to observe and report. They aren't being asked to do anything about mail that fails.

So anyone can still spoof your domain, and Gmail will still deliver it.

First, look at what you actually published

Before changing anything, read the record. On macOS or Linux:

dig +short TXT _dmarc.yourdomain.com

On Windows:

nslookup -type=TXT _dmarc.yourdomain.com

You'll get back something like this:

"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

The p= tag is the entire subject of the warning. Three values are legal. p=none tells receivers to report but deliver normally, p=quarantine tells them to treat failing mail as suspicious (usually the spam folder), and p=reject tells them to refuse it outright at the SMTP layer.

If you're seeing the warning, your record says p=none. Almost always this happened because you followed a setup guide two years ago, that guide correctly told you to start at p=none, and then nobody came back to finish the job. That's the normal story. It's not negligence so much as the second half of a task that had no deadline attached.

Why you should not just change it to p=reject

This is the part where people wreck their own mail, so it's worth being blunt about.

The moment you publish p=reject, every message that fails DMARC alignment gets refused by Gmail, Yahoo, Microsoft, and everyone else honoring the policy. Not spam-foldered. Refused. If your invoicing tool, your helpdesk, your CRM, or your payroll system sends as your domain and isn't properly aligned, those messages stop arriving that afternoon, and the people who notice first will be customers who never got a receipt.

The failure mode is nasty because it's invisible from your side. You don't see a bounce in your inbox when a SaaS tool sends on your behalf. You find out days later when someone asks why they never got the thing you swear you sent.

So the order matters more than the destination.

The part nearly everyone gets wrong: alignment

This one trips up otherwise careful people. SPF passing does not mean DMARC passes.

DMARC requires SPF or DKIM to pass and to align with the domain in the visible From: header. Those are two separate checks, and the second one is where mail dies.

SPF authenticates the envelope sender, the Return-Path, not the From: address your recipient sees. Plenty of email providers send your mail with their own bounce domain in the Return-Path. SPF passes beautifully, because their domain authorizes their servers. DMARC then compares that domain against yours, sees they don't match, and marks SPF as unaligned. The check passed and the alignment failed, which is a distinction no dashboard explains well.

DKIM is the more reliable leg, because DKIM alignment compares the d= value in the signature against your From: domain. If your sending platform lets you set up a custom signing domain, meaning you publish a CNAME or TXT so it signs as yourdomain.com rather than theirdomain.com, DKIM aligns and DMARC passes regardless of what the Return-Path says. Set that up for every platform that offers it. It's usually two DNS records and ten minutes.

By default DMARC uses relaxed alignment, so mail.yourdomain.com counts as matching yourdomain.com. Strict alignment, which you get with aspf=s or adkim=s, demands an exact match. Don't reach for strict unless you have a specific reason; relaxed is the sane default and turning it on tightens the noose for very little gain.

The rollout that works

Give this four to six weeks. It is boring on purpose.

Get reports flowing. If your record has no rua= tag, add one now. Without aggregate reports you are guessing about who sends as your domain, and you will guess wrong.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

The reports arrive as gzipped XML once a day from each receiver, and reading them raw is miserable. Parse them with something. There are free tools that will ingest them and give you a sender-by-sender view.

Inventory your senders. Two or three weeks of reports will show you every service sending as your domain. This list is always longer than people expect. Your ESP, Google Workspace or Microsoft 365, an invoicing tool, a form on the website, an appointment reminder system, something the marketing contractor set up in 2023 that nobody remembers. Each one needs SPF and DKIM configured, and DKIM aligned.

Fix each sender until it passes aligned. Work down the list. When your reports show close to 100% of legitimate volume passing with alignment, and the only failures left are things you don't recognize (which is spoofing, and which is the whole point), you're ready.

Move to quarantine, not reject. Publish p=quarantine and sit there for a week or two. If you broke something, the mail lands in spam instead of vanishing, which gives you a recoverable mistake instead of an unrecoverable one. If bounces do start coming back reading 554 5.7.5 permanent error evaluating DMARC policy, that's a sender you missed rather than a reason to abandon the rollout.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; fo=1

You can ramp with pct=25 to apply the policy to a quarter of failing mail. Major receivers still honor it, though the revised DMARC specification drops the tag, so use it as a temporary ramp rather than a setting you leave in place forever.

Then reject. Once quarantine has run clean, change one character:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1

That clears the warning, and more usefully, it means someone spoofing your domain gets their mail refused rather than delivered.

Two things that will waste your afternoon

More than one DMARC record. If _dmarc.yourdomain.com returns two TXT records that both start with v=DMARC1, DMARC is not partially working, it's failing entirely. The spec says a receiver finding multiple records treats the domain as having no policy at all. The same rule applies to SPF, and it's worth checking both while you're in your DNS panel. Merge them into one and delete the other.

The record in the wrong place. DMARC lives at the _dmarc subdomain, not the root. If you put the TXT record on yourdomain.com instead of _dmarc.yourdomain.com, every checker will report no record found. Some DNS panels append the domain automatically and some don't, which is how people end up with _dmarc.yourdomain.com.yourdomain.com. Check the resulting hostname after you save, not the field before you save.

Why Gmail says you're compliant while your scanner says you aren't

This confuses a lot of people, and both tools are telling the truth.

Google and Yahoo's bulk sender rules, which landed in February 2024 and apply if you send around 5,000 or more messages a day to Gmail, require that you have a DMARC record. p=none satisfies that requirement. So Google Postmaster Tools can show you as compliant while MXToolbox flags the same domain.

Google is asking whether you've published a policy. Your scanner is asking whether that policy does anything. p=none is a yes to the first question and a no to the second.

The bulk sender rules also require one-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers, and that they want your Gmail spam complaint rate under 0.3%, with 0.1% as the number to actually aim for. DMARC is the piece people notice because it's the one that generates a warning in a scanner.

What this is actually protecting

Domain spoofing isn't hypothetical for small businesses, it's just quiet. Someone sends an invoice with changed bank details, as your domain, to your customer. Or a message to your bookkeeper that reads exactly like it came from you. With p=none, those land in the inbox with no authentication barrier, and the only thing standing between your customer and a wire transfer is whether they happened to look closely.

With p=reject, the receiving mail server refuses the message before anyone sees it.

That's the trade you're making by finishing the rollout. It takes a month of low-effort attention, most of which is waiting for reports rather than doing anything.

If you only do one thing today

Add a rua= address to your existing record and let reports accumulate. You can't safely enforce a policy you have no visibility into, and every week you don't collect reports is a week you can't start the clock on.

The rest of it is patient work. Nothing about DMARC rewards moving fast, and the people who get burned are almost always the ones who read a warning, changed none to reject, and went to lunch.