"DMARC Policy Not Enabled": What the Warning Means and How to Fix It

Where the warning comes from

You'll see versions of this text in security scanners, domain health reports, vendor security questionnaires and deliverability dashboards:

• "DMARC policy not enabled"
• "DMARC quarantine/reject policy not enabled"
• "DMARC policy is set to none"
• "No DMARC record found"

They all check the same thing. The scanner looks up the TXT record at _dmarc.yourdomain.com and reads the p= tag. If there is no record, or p=none, it reports that enforcement is off. Some scanners also flag a policy that only applies to part of your mail. Paste your domain into the DMARC checker to see exactly what they see.

What triggers it

What the scanner finds	Why it flags it
No TXT record at _dmarc	No DMARC at all. See DMARC record not found
p=none	Monitoring only. Spoofed mail is still delivered
p=quarantine; pct=25	Enforcement applies to only some failing mail
sp=none with p=reject	Subdomains are left unprotected
Two v=DMARC1 records	The specification treats this as no policy
Record on the wrong name (e.g. dmarc. or the root)	Receivers never find it

The last two are the sneaky ones: the DNS panel shows a DMARC record, yet the scanner says it's missing.

What the three policies do

• p=none: receivers deliver mail as normal and send you reports (if you include rua=). Useful for discovery, but it doesn't stop anyone sending as your domain.
• p=quarantine: receivers are asked to treat failing mail as suspicious. In practice that usually means the spam folder.
• p=reject: receivers are asked to refuse failing mail during the SMTP conversation. Microsoft returns errors like 550 5.7.509 when this happens.

Receivers treat the policy as a request. Large mailbox providers generally honour it, but they apply their own judgement on top.

Quarantine vs reject

Reject is the end goal because spoofed mail never reaches the inbox or the spam folder. Quarantine is the safety net on the way there. If you forgot a service, say the billing tool or the helpdesk, a quarantine policy sends its mail to spam, where someone eventually notices. A reject policy makes it vanish, and the first sign is a customer saying they never got the invoice.

So the honest answer to "which DMARC policy should I use" is: reject, eventually, after a period on quarantine.

A staged plan

1. Publish monitoring. v=DMARC1; p=none; rua=mailto:[email protected]. Build it with the DMARC generator if you prefer.
2. Read the reports for two to four weeks. Aggregate reports list every IP that sent as your domain and whether SPF and DKIM passed and aligned. Upload them to the DMARC report analyzer, or read how to read DMARC aggregate reports.
3. Fix each legitimate sender. Add DKIM signing on your domain for every tool that sends as you (CRM, ESP, helpdesk, billing). SPF alone often fails alignment for third-party senders; see DMARC alignment.
4. Move to quarantine. p=quarantine. Some teams ramp with pct= (for example 25, then 50, then 100). Note that a pct below 100 still triggers some scanners.
5. Move to reject. p=reject once reports show only legitimate, passing mail. Add sp=reject if you don't send from subdomains, or set subdomain policies deliberately if you do.
6. Keep the reports on. New tools get added; the reports catch the one someone forgot to set up.

The longer walk-through, with failure cases, is in moving DMARC from p=none to p=reject.

Can you have multiple DMARC records?

No. A domain gets one DMARC record at _dmarc.yourdomain.com. RFC 7489 says that if the lookup returns more than one DMARC record, the receiver should act as if no DMARC record exists. So adding a second "stricter" record to fix the warning actually removes your policy.

This usually happens when:

• a vendor's setup guide says "add this DMARC record" and someone adds it beside the existing one;
• a DNS host or email provider auto-creates a default record;
• someone puts rua and ruf addresses in two separate records.

The fix is to merge: one v=DMARC1 record, one p=, and all reporting addresses comma-separated inside a single rua= tag. Subdomains are different: _dmarc.mail.yourdomain.com is a separate name and can have its own record.

Don't confuse it with other DMARC errors

• "DMARC record not found": nothing at _dmarc, or it's in the wrong place.
• "DMARC fail" in headers: a message failed alignment. That's about one sender, not your published policy.
• 550 5.7.26 from Gmail: the message wasn't authenticated well enough. See Gmail 550 5.7.26.

After DMARC: the list is the next risk

Enforcing DMARC protects your domain's name. It doesn't protect its reputation from the list you send to. A domain with perfect SPF, DKIM and p=reject will still get throttled or flagged if a campaign hits a pile of dead mailboxes, because bounce rates are one of the clearest signals receivers and sending platforms watch. Mailbox providers also look at it the other way round: a domain with good authentication earns more trust, and bounces spend that trust fast.

Before the next send, run the list through the verify page. Each address gets a live mailbox check; invalid addresses are marked for removal, and catch-all addresses come back as risky, never guessed valid. Check one address in the box above, or the whole domain's setup with the bulk email authentication checker.

What it costs

• Pro, $39 a month: Unlimited email verification.*
• Starter, $9 a month: 2,500 emails a month.
• Free: the first 100 checks with a Google sign-in, no card.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.

The DMARC checker, generator and report analyzer are free and need no sign-up. See pricing.

More reading: SPF, DKIM and DMARC explained, Gmail and Yahoo bulk sender requirements.