DMARC quarantine/reject policy not enabled: answering the scanner finding

When a customer’s scanner says “DMARC quarantine/reject policy not enabled”, it means one of two things: nothing is published at _dmarc.yourdomain.com, or a record is there and it says p=none. Either way, receivers deliver mail claiming to be from your domain exactly as they did before anyone looked, and the scanner is right to flag it. You’re in a large group. Of the 78,444,857 DMARC records the September 2026 census found, 41,798,631 sit at p=none, and 36,602,897 enforce with quarantine or reject. The fix is ordered and mostly waiting: publish a monitoring record today, read the reports it generates, then raise the policy in stages. The warning stays on the report until p= reads quarantine or reject, which is correct behaviour, so the plan below is about getting there without losing your own mail on the way.

Work out which of the two findings you have

The one warning collapses two different states, and the fix path differs, so separate them before you touch DNS. From any terminal:

dig TXT _dmarc.yourdomain.com

If nothing comes back, you have no record, and step one is publishing one. If it returns a single line beginning v=DMARC1; p=none, you already have monitoring in place and possibly weeks of reports waiting in a mailbox, so you can skip to step three. If it returns two lines beginning v=DMARC1, receivers ignore both of them, and you’re in the no-record case with a deletion to do first.

The free scan shows the same split, and underneath it whether SPF and DKIM are in place, which decides how fast you can move to enforcement later.

Step one: publish the monitoring record (minutes, then one TTL)

This is the record, verbatim:

v=DMARC1; p=none; rua=mailto:[email protected]

It lives at the host _dmarc.yourdomain.com, never at the apex. Most DNS panels append the domain for you, so the host field takes only _dmarc; typing the full name produces _dmarc.yourdomain.com.yourdomain.com, which is a record nobody will ever query. Replace the report address with a mailbox you’ll read, or with the address a report-analysis service gave you.

Four rules of syntax decide whether the record parses. v=DMARC1 must be the first tag and spelled exactly that way. Tags are separated by semicolons; a comma anywhere in the record breaks it. The rua value needs the mailto: prefix. And there must be one record at the host, because two v=DMARC1 records means receivers ignore all of them. An unparseable record is treated as no record, so a typo puts you back where you started.

Propagation is the record’s own TTL. A fresh record at a name that had nothing there is visible as soon as a resolver asks for it, with one catch: if you ran dig against that name before publishing, your resolver may have cached the empty answer for as long as the zone’s negative TTL allows. Ask the authoritative nameserver directly (dig TXT _dmarc.yourdomain.com @<your nameserver>) and you’ll see the record straight away.

Publishing p=none changes nothing about how receivers deliver your mail. The large mailbox providers’ bulk-sender requirements ask for a DMARC record at minimum, so this step carries no delivery risk. It also doesn’t clear the finding. The scanner will keep reporting “quarantine/reject policy not enabled” after this record goes live, and it’s telling the truth, because your policy is none.

One record covers the whole tree. When a receiver finds no record on mail.yourdomain.com, it falls back to the organisational domain’s policy, so you don’t need a record per subdomain to start monitoring. The sp= tag is how you override that later, and the subdomain policy piece covers when you’d want to.

Step two: verify it and catch the slips (same day)

Run the check again:

dig TXT _dmarc.yourdomain.com

You want exactly one record beginning v=DMARC1. If you get anything else, it’s almost always one of these.

• The record was put on the bare domain instead of _dmarc. On the apex it does nothing, and the scanner keeps saying no record found.
• The host got the domain appended twice. Enter _dmarc on its own.
• A comma crept in between tags.
• The record starts with p= and v=DMARC1 is missing or later in the string.
• [email protected] without the mailto: prefix.
• Two records at the host, usually because a previous attempt was left behind.
• Curly quotes or non-breaking spaces copied out of a document. If a checker says the record is malformed and it looks right to you, retype it by hand.

There’s one more that fails silently rather than at parse time. A rua address on a different domain requires that domain to publish yourdomain._report._dmarc.<vendor domain>, or receivers withhold the reports without telling anyone. Report-analysis services publish this automatically, so if reports never arrive at a vendor address, check for that record before you assume the vendor is broken.

Step three: wait for the reports (days to two weeks)

Aggregate reports arrive roughly daily per receiver, as compressed XML attachments. They aren’t a dashboard. Raw, they’re close to unreadable, and a free parser turns them into a table of who sent mail as your domain and whether it passed. Volume tracks your mail volume: a domain that sends little, or sends mostly to providers that don’t report, gets sparse data. Two quiet weeks is normal, so verify the record with dig rather than concluding it failed.

Ask for the reports at all. Only 31,037,403 of the 78,444,857 DMARC records in the September 2026 census carry a rua address; the rest request nothing from receivers, and their owners are monitoring blind. Without reports you can’t do step four, and without step four you can’t safely do step five.

What you’re reading for is alignment, which is the thing the individual green ticks hide. SPF can pass on the envelope sender and DKIM can pass on a signing domain, and DMARC still fails if neither of those domains matches the one in the From header your recipient sees. Only the aggregate reports show that, per source, and a line that shows DMARC failing while SPF and DKIM individually pass is an alignment problem rather than a missing record.

Step four: align each legitimate sender (weeks)

Most domains discover senders they’d forgotten. The CRM, the invoicing tool, the contact form on the website, the newsletter platform, the ticketing system that sends from a support address. Each one shows up in the reports as a source IP with a pass or fail against your domain, and each one needs SPF or DKIM aligned with your From domain before you can enforce without bouncing your own mail.

For a sender you control, DKIM alignment is usually the cleaner route: sign with a selector under your own domain. For a third-party platform, follow their setup for either a DKIM record under your domain or an SPF include, and check which mechanism they use, because an include that passes SPF on the platform’s own bounce domain does nothing for DMARC. The SPF piece walks through the include and lookup-limit side of that.

The clock at this step is the TTL of each SPF or DKIM record you change, plus a day or so for the next round of reports to reflect it. Don’t move on until the reports show a run of days where every source you recognise passes and the only failures are sources you don’t. The DMARC guide has the full picture of how the three records fit together if you need to go deeper here.

Step five: quarantine, then reject (one TTL per change, weeks between)

Before each policy change, lower the TTL on the _dmarc record to a few minutes, then wait out the old TTL so the low one is what resolvers hold. That makes rollback a minutes-long affair rather than an hours-long one if a sender you missed starts landing in spam.

Change the record to p=quarantine; pct=10 first. Quarantine tells receivers to send failing mail to the junk folder, and pct=10 applies that to a tenth of the failing mail while the rest is treated as none. Watch the reports for a few days, raise pct in steps to 100, and watch again. What breaks at this stage is any legitimate sender you didn’t align, and it breaks visibly: staff notice their mail landing in customers’ spam folders, which is your cue to align that sender and hold the percentage until it’s clean.

Then change to p=reject. Reject tells receivers to refuse failing mail outright, so an unaligned sender now bounces rather than landing in junk, and you’ll hear about it faster. Once it’s stable, raise the TTL back to something normal.

The scanner finding clears when p= reads quarantine or reject. Partial enforcement with pct=10 counts, because the policy tag is what the scanner reads, though the honest answer to the customer is that you’re stepping up and here’s the date it reaches 100.

What to tell the customer by Friday

You don’t need enforcement done by Friday. You need a true statement and a dated plan, and after step one you have both. Something like this holds up:

“A DMARC record is now published at _dmarc.ourdomain.com in monitoring mode, with aggregate reports going to a monitored mailbox. We’re using the reports to align each of our sending systems on SPF or DKIM. Enforcement is scheduled: p=quarantine from [date], stepping to 100% by [date], then p=reject by [date]. Your scanner will continue to show the warning until quarantine is live, which is expected.”

That answer is accurate, it names the mechanism, and it commits you to dates you can meet because each step above has a known clock. Put the record in today, put the dates in the calendar, and the finding takes care of itself in the order described.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.