DMARC Quarantine/Reject Policy Not Enabled

This is not an SMTP bounce or a delivery failure — it is a posture/policy warning raised by DMARC checkers, security scanners, and bulk-sender compliance tools. It means your domain has a DMARC record, but the enforcement policy is p=none (monitor only) rather than p=quarantine or p=reject. With p=none, receiving servers report on mail that fails DMARC but take no protective action, so attackers can still spoof your From: domain.

What causes "DMARC Quarantine/Reject Policy Not Enabled"?

A DMARC record's behavior is set by the p (policy) tag in the TXT record at _dmarc.yourdomain.com. Per RFC 7489 §6.3 there are three values:

• p=none — "no specific action"; monitor and collect reports only. This triggers the warning.
• p=quarantine — receivers treat failing mail as suspicious (typically the spam folder).
• p=reject — receivers reject failing mail, ideally during the SMTP transaction.

The warning fires when the record is p=none, when the p tag is missing, or (less often) when an enforcing root policy is undercut by sp=none for subdomains or pct= set below 100. p=none is a valid starting point — Google and Yahoo's 2024 bulk-sender rules require only p=none as a minimum — but it provides zero anti-spoofing protection, which is why scanners flag it.

How do I fix "DMARC Quarantine/Reject Policy Not Enabled"?

Do not jump straight to p=reject. DMARC only passes when at least one mechanism — SPF or DKIM — both authenticates and aligns with the From: domain (RFC 7489 §3.1, §4.2). Enforcing before every legitimate sender aligns will silently quarantine or reject your own mail.

1. Stay at p=none and read your aggregate (RUA) reports. Confirm every legitimate source — your ESP, Courier, CRM, helpdesk, marketing tools — passes SPF or DKIM with alignment.
2. Roll out gradually to quarantine. Edit the TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

3. Watch reports for 1–4 weeks, fix any failing legitimate sources, then advance to reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

4. Publish and wait for DNS propagation, then re-scan to clear the warning.

DMARCbis note: In May 2026 the IETF published RFC 9989/9990/9991, obsoleting RFC 7489. They remove the pct= tag entirely (RFC 9989 Appendix A.6) — it is no longer a defined tag, not merely discouraged — so use the staged rollout above instead, and add the np= tag for non-existent-subdomain policy. Existing v=DMARC1 records remain backward compatible, so the fix above is unchanged.

For Courier senders, ensure the From-domain you configure aligns with the DKIM signature your email provider applies before tightening to p=reject.