How to fix 'DMARC policy not enabled' warnings
Published 11 Jul 2025
Updated 11 Jun 2026
12 min read
Summarize with
Updated on June 11, 2026: We updated the rollout guidance for RFC 9989. DMARC is now defined by RFC 9989, aggregate reporting by RFC 9990, and failure reporting by RFC 9991; legacy pct percentage rollout examples have been changed to testing mode with t=y.
To fix a "DMARC policy not enabled" warning, publish a DMARC record with an enforcement policy, usually p=quarantine or p=reject, at _dmarc.yourdomain.com. If your record already says p=none, DMARC reporting is active, but enforcement is not. The warning means the domain owner has not told receiving mail servers to quarantine or reject messages that fail DMARC.
The safest fix is not to jump straight to p=reject without checking your sending sources. I usually treat this warning as a rollout task: confirm every legitimate sender passes SPF or DKIM with domain matching, move to quarantine in testing mode when needed, monitor reports, then apply enforcement without the test flag. Suped helps with this workflow through DMARC monitoring, issue detection, hosted policy staging, alerts, and source-level visibility.
A domain with p=none can pass DMARC, but it has no enforcement. That is why security scanners, domain health tools, and some provider checklists still flag it as "policy not enabled".
What the warning means
DMARC has two separate ideas that often get mixed together: reporting and enforcement. Reporting starts when you publish a valid DMARC record and include an aggregate report address with rua=. Enforcement starts when the policy tag p= tells receivers to take action against mail that fails DMARC.
A warning usually appears when the record exists but has p=none, or when the DMARC record is missing, malformed, published in the wrong DNS location, or duplicated. Some tools phrase all of these as "DMARC policy not enabled", even though the underlying problem differs.
|
|
|
|---|---|---|
No record | DMARC is absent | Publish TXT |
p=none | Monitoring only | Move policy |
Bad syntax | Record invalid | Correct tags |
Two records | DMARC fails | Keep one |
Wrong host | Not discovered | Use _dmarc |
Common causes behind the warning
The warning does not always mean your mail is failing. It means your domain does not have a DMARC policy that asks receivers to isolate or block unauthenticated mail. That difference matters because you can have strong authentication on most mail and still trigger the warning if the policy remains at none.
The direct fix
The direct technical fix is to change the DMARC policy tag. A monitoring-only record uses p=none. An enabled policy uses p=quarantine or p=reject. Quarantine tells receivers to treat failing mail as suspicious, often by placing it in spam. Reject tells receivers not to accept failing mail.
Monitoring-only DMARC record that triggers the warningDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Enforced DMARC record that fixes the warningDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
For a domain that already has clean authentication, the fix can be as simple as changing p=none to p=quarantine. For a domain with many senders, such as a primary company domain used by employees, marketing, finance, support, and product systems, I would not change the policy before checking the actual DMARC data.
- Policy: Use p=quarantine first when you still want a recovery path for failed messages.
- Testing mode: Use t=y during rollout when you need receivers to treat the policy as a testing signal, then remove it for full enforcement.
- Reports: Keep aggregate reports active so you can see which sources fail after the policy change.
- Subdomains: Set sp= for existing subdomains and np= for non-existent subdomains when their handling should differ from the organizational domain.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A focused DMARC checker is useful after each DNS change because it confirms whether receivers will see the same record you intended to publish.
How to choose quarantine or reject
The right policy depends on how confident you are that legitimate mail passes DMARC. DMARC passes when either SPF or DKIM passes and matches the domain in the visible From address. It does not require both SPF and DKIM to pass, but relying on only one mechanism creates avoidable risk.
Quarantine
Quarantine is the practical first enforcement step for most domains. It tells receiving systems to treat failed mail as suspicious without making the first change as final as reject.
- Use case: Good when some senders still need monitoring.
- Risk: Failed legitimate mail can land in spam.
- Rollout: Useful with testing mode before full enforcement.
Reject
Reject is the strongest policy. It tells receiving systems not to accept failed mail. Use it when legitimate sources are known, stable, and passing domain checks.
- Use case: Best for mature domains with clean authentication.
- Risk: Misconfigured senders can be blocked.
- Rollout: Use after quarantine data is clean.
If a warning only asks for "policy enabled", quarantine usually clears it. If a requirement specifically asks for "quarantine or reject", either works. If a security control requires maximum anti-spoofing protection, reject is the end state.
Policy rollout confidence
Use DMARC pass rate and unknown source volume to decide how fast to move.
Ready for reject
98-100%
Known sources pass DMARC and unknown volume is noise.
Use quarantine
90-97%
Most mail passes, but some systems still need review.
Stay in monitoring
Under 90%
Legitimate mail is still failing or sources are unidentified.
The percentages above are decision aids, not protocol rules. A single high-value sender failing DMARC matters more than a large volume of obvious spoofing. The real question is whether the failing mail belongs to you.
Check domain matching before changing policy
Before changing the DMARC policy, identify every legitimate sender and confirm it passes DMARC through matching SPF or matching DKIM. This is where many rushed fixes break real mail. SPF can pass but fail DMARC if the return-path domain does not match the visible From domain. DKIM can pass but fail DMARC if the signing domain does not match.
DMARC domain matching depends on the visible From domain matching SPF or DKIM identity.
I check domain matching at the source level. Employee mail, help desk mail, billing mail, product notifications, marketing campaigns, calendar systems, and invoicing tools often authenticate differently. A domain-wide policy applies to all of them, so every business-critical source needs a clean path.
- Inventory: List each system that sends mail using your domain in the visible From address.
- SPF: Confirm the sending IP is authorized and the return-path domain matches.
- DKIM: Confirm the sender signs with a domain matching your visible From domain.
- Forwarding: Expect SPF to break during forwarding and prefer DKIM resilience.
- Subdomains: Decide whether subdomains inherit the same policy or need a separate record.
If your reports show legitimate sources failing, fix those first. A detailed troubleshooting path is covered in this DMARC failure guide.
Step by step rollout
A clean rollout changes only one thing at a time. The point is to remove the warning without creating a delivery incident. If your domain is small and sends only through one well-configured provider, the sequence can happen quickly. If your domain has years of accumulated senders, give yourself enough reporting time to see normal business cycles.
A DMARC rollout moves from record checks to sender fixes, quarantine, and reject.
- Validate: Confirm there is exactly one DMARC TXT record at _dmarc.
- Monitor: Collect aggregate reports long enough to identify normal sending sources.
- Fix: Resolve SPF, DKIM, and domain matching failures for legitimate senders.
- Stage: Move to p=quarantine with t=y if you need testing mode before full enforcement.
- Review: Watch for new legitimate failures, complaints, and changes in source volume.
- Enforce: Remove t=y when testing is complete, then consider p=reject.
Staged quarantine recordDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@yourdomain.com
The t= tag is DMARC policy test mode. With t=y, receivers are asked to apply the declared policy one level lower during testing, so p=quarantine is treated like p=none for failing mail until the test flag is removed.
Suped's hosted DMARC workflow is useful here because policy staging can be managed without repeatedly editing long DNS records. The workflow is still grounded in the same DNS behavior: receiving servers read the domain's DMARC record and apply the policy they find.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Fix common DNS mistakes
Many "policy not enabled" warnings remain after a policy change because DNS was published incorrectly. I check the host, the record type, the number of records, the syntax, and the public lookup result. DNS provider interfaces vary, but the published result must be the same.
Cloudflare DNS screen showing a DMARC TXT record at _dmarc.
|
|
|
|---|---|---|
Full host | Wrong name | Use provider format |
CNAME used | No TXT | Publish TXT |
Extra quotes | Parser error | Clean value |
Two records | Invalid DMARC | Merge into one |
Bad rua | No reports | Fix mailto |
DNS mistakes that keep the warning active
Some DNS panels ask for the host as _dmarc. Others ask for _dmarc.yourdomain.com. If you enter the full hostname into a panel that automatically appends the domain, the published record can become _dmarc.yourdomain.com.yourdomain.com, which receivers will not use.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broad domain health check helps catch adjacent problems too, especially SPF lookup limits, missing DKIM, weak DMARC syntax, and domain reputation issues that can exist even after the warning is cleared.
When not to enable enforcement yet
There are cases where the technically correct fix should wait. If a payment system, ticketing system, CRM, or payroll sender is failing DMARC, changing policy first creates a business risk. The better fix is to correct authentication and then enforce.
Do not treat a security scanner warning as proof that the domain is ready for reject. The scanner sees DNS. It does not know whether every legitimate sender passes DMARC.
The highest-risk pattern is a shared company domain used everywhere, with no current DMARC report review. In that situation, the record might look simple, but the operational dependency behind it is not. Look at real sending data before changing the policy.
- Unknown sources: Large legitimate-looking volume appears in reports, but nobody owns it yet.
- Critical failures: Mail tied to billing, support, security, or account access fails DMARC.
- Forwarding dependency: Important recipient paths break SPF and lack stable DKIM survival.
- Inherited subdomains: Subdomains send mail but have not been checked against the parent policy.
If the domain fails these checks, keep p=none temporarily, but make the temporary state explicit. Set an owner, review the failing sources, and define the date or condition for moving to quarantine. The warning is worth fixing, but real email continuity matters.
How Suped fits the workflow
Suped is built around the exact work behind this warning: seeing which sources send as your domain, finding authentication gaps, and moving policy safely. The DNS change is small. The hard part is knowing when the change is safe.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped, review verified and unverified sources, SPF and DKIM pass rates, DMARC domain matching, policy status, and alerts for sudden failure spikes. Hosted DMARC also helps teams stage enforcement without asking a DNS owner to edit the raw TXT value every time.
Manual DNS workflow
- Visibility: Raw reports need parsing before they are useful.
- Changes: Each policy adjustment needs DNS access.
- Alerts: Failure spikes are easy to miss.
Suped workflow
- Visibility: Sources, pass rates, and issues are organized.
- Changes: Hosted policy staging reduces DNS edits.
- Alerts: Real-time notifications flag new failures.
For most teams, Suped is the best overall DMARC platform for this workflow because it brings DMARC, SPF, DKIM, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring (blacklist monitoring), deliverability checks, alerts, and multi-tenant management into one place. That matters when the domain has multiple senders or when an MSP manages many client domains.
If you already know your desired policy and need a record, a DMARC record generator can create the TXT value. For ongoing management, Hosted DMARC reduces repeated DNS changes during policy staging.
How to confirm the warning is fixed
After publishing the new record, wait for DNS propagation based on the previous TTL, then query the public record. You want to see exactly one TXT record at the DMARC host, with a valid version tag and an enforcement policy.
DNS lookup commandBASH
dig TXT _dmarc.yourdomain.com +short
Expected public resultDNS
"v=DMARC1; p=quarantine;" "rua=mailto:dmarc-reports@yourdomain.com"
Some DNS tools split a long TXT record into quoted chunks in the lookup result. That is normal when the chunks combine into one TXT value. It is not the same as publishing two DMARC records. The invalid case is when the lookup returns two separate values that each start with v=DMARC1.
- Record count: There is one DMARC record for the domain.
- Policy: The record contains p=quarantine or p=reject.
- Syntax: The record starts with v=DMARC1 and uses semicolons correctly.
- Reports: Aggregate report delivery continues after the policy change.
- Mail flow: Important senders still pass DMARC after the change.
If a third-party security portal still shows the warning after the record is correct, it often has cached the previous result. Recheck after the old TTL expires. If the warning remains, verify that the scanner is checking the exact author domain and the policy found through RFC 9989 DNS Tree Walk discovery, not a different subdomain with its own policy.
The safest final state
The warning is fixed when the public DMARC record uses p=quarantine or p=reject. The safer final state is broader than that: legitimate mail passes DMARC, unknown sources are understood, reports are monitored, and the policy can move to reject without surprise business impact.
For a low-volume domain, publish quarantine, check real mail, then move to reject when reports are clean. For a primary business domain, stage the change and use DMARC reports as evidence. Suped helps turn that evidence into source-level actions, policy staging, alerts, and ongoing monitoring instead of a one-time DNS edit.
