How to fix 'DMARC policy not enabled' warnings
Published 11 Jul 2025
Updated 22 Oct 2026
15 min read
Summarize with
Updated on 22 Oct 2026: We clarified DMARC test-mode compatibility and added recovery steps for legitimate mail failures.
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 evaluation is active, but enforcement is not. Aggregate reports require a valid rua= address. The warning means the domain owner has not asked receiving mail servers to quarantine or reject messages that fail DMARC.
Check your sending sources before publishing p=reject. Treat this warning as a rollout task: confirm every legitimate sender passes SPF or DKIM with domain matching, review reports, then apply the chosen enforcement policy. Suped's DMARC reporting and email authentication platform supports this workflow through DMARC monitoring and hosted policy management.
Messages from a domain with p=none can pass DMARC, but that policy requests no enforcement. That is why security scanners and some provider checklists still flag it as "policy not enabled" or "DMARC quarantine/reject policy not enabled".
What the warning means
DMARC (Domain-based Message Authentication, Reporting, and Conformance) has separate reporting and enforcement functions. A valid record with an aggregate report address requests reports through rua=. Enforcement starts when the policy tag p= asks receivers to take action against mail that fails DMARC.
Aggregate reports are XML summaries of passing and failing mail, usually sent daily rather than in real time. If the rua= address uses an external domain, its operator must authorize report delivery in DNS. Receivers withhold reports to unauthorized external destinations, as specified in RFC 9990.
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, duplicated, or missing an explicit p= value. RFC 9989 treats an otherwise usable reporting record without p= as p=none. Some tools phrase all of these as "DMARC policy not enabled", even though the underlying problem differs.
|
|
|
|---|---|---|
No record | DMARC is absent | Publish a valid DMARC TXT record |
p=none | Monitoring only | Validate senders, then enforce |
No p tag | Defaults to none | Add an explicit p= value |
Bad syntax | Record invalid | Correct tags |
Two records | Policy discovery fails | Keep one |
Wrong host | Not discovered | Use _dmarc |
Common causes behind the warning
The warning alone does not mean mail is failing. It is a DNS policy warning rather than an SMTP reply or bounce code. The Gmail sender requirements and Yahoo sender requirements accept p=none as the minimum DMARC policy for bulk senders; their other authentication and sending requirements still apply. Clearing the warning does not guarantee inbox placement.
Change the DMARC TXT record to quarantine or reject
The direct technical fix is to change the DMARC policy tag. A monitoring-only record uses p=none. An enforcement policy uses p=quarantine or p=reject. Quarantine asks receivers to treat failing mail as suspicious, often by placing it in spam. Reject asks receivers not to accept failing mail. Receiving systems still apply local policy when deciding the final disposition. Update the existing DMARC record instead of adding a second one.
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
Edit the record in the authoritative DNS zone, which is not always managed by your registrar or mailbox provider. Replace yourdomain.com and dmarc-reports@yourdomain.com with your domain and a working report mailbox. The rua= tag requests reports; it is optional for enforcement.
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, check the actual DMARC data before changing the policy.
- Use p=quarantine first when you still want a recovery path for failed messages.
- Treat t=y as a test-mode request only for receivers that support it. Older receivers ignore it, so prepare for the published p= policy to take effect.
- Keep aggregate reports active so you can see which sources fail after the policy change.
- 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
Suped's DMARC checker verifies the public DNS policy after a change. It does not establish whether every legitimate sender passes DMARC.
How to choose quarantine or reject
The right policy depends on how confident you are that legitimate mail passes DMARC and how the domain is used. DMARC passes when either SPF or DKIM passes and matches the domain in the visible From address. Configure both SPF and DKIM for resilience, even though only one passing mechanism with a matching domain is needed for DMARC.
Quarantine
Quarantine is an enforcement policy and often the right long-term choice for general-purpose mailbox domains. It asks receiving systems to treat failed mail as suspicious while leaving a recovery path for legitimate indirect mail.
- Good for general-purpose domains and senders still under review.
- Failed legitimate mail can land in spam.
- Keep p=none until legitimate senders are ready, then apply quarantine.
Reject
Reject is the stricter request. Use it for dedicated sending domains after validating legitimate sources, or for domains that should never send mail.
- Best suited to dedicated sending or no-mail domains.
- Mailing-list and forwarding paths can lose legitimate mail.
- Use only after quarantine data and indirect-mail review are clean.
RFC 9989 says domains that host users who might post to mailing lists should not publish p=reject. Mailing lists and forwarding paths can change the message in ways that break SPF alignment, DKIM validation, or both. A receiving system can then reject legitimate mail even though the original sender authenticated it correctly.
If a warning only asks for "policy enabled", quarantine usually clears it. If a requirement specifically asks for "quarantine or reject", either works. Choose the policy by domain use and indirect-mail risk, not by treating reject as an automatic end state.
Policy choice by domain use
Use domain purpose and indirect-mail exposure to choose the enforcement level.
Consider reject
Controlled use
Dedicated sending domain with stable matching DKIM, or a domain that sends no mail.
Prefer quarantine
Indirect mail
General-purpose mailbox domain or routine mailing-list participation.
Keep testing
Unmapped senders
Legitimate sources still fail or remain unidentified.
These categories 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 and whether the domain is used for indirect mail.
Check DMARC alignment 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 without satisfying DMARC when the return-path domain does not match the visible From domain. The same applies to DKIM when its signing domain does not match. DMARC needs only one passing mechanism with the required domain match.
DMARC alignment compares the visible From domain with the SPF return-path or DKIM signing domain.
DMARC alignment is relaxed by default: the authenticated domain and visible From domain can share an organizational domain. With aspf=s or adkim=s, the applicable domains must match exactly. For example, bounce.yourdomain.com and yourdomain.com match under relaxed SPF alignment but fail strict SPF alignment.
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.
- List each system that sends mail using your domain in the visible From address.
- Confirm the sending IP is authorized and the return-path domain matches.
- Confirm the sender signs with a domain matching your visible From domain.
- Expect SPF to break during forwarding and prefer DKIM resilience.
- 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.
Roll out DMARC enforcement safely
A clean rollout changes only one thing at a time. The point is to remove the warning without creating a delivery incident. RFC 9989 made pct= historic and introduced t=y for policy testing. Neither tag is a dependable safety control across receivers using different DMARC versions. Keep p=none while fixing legitimate senders, then publish quarantine when those senders are ready. Collect enough reporting data to cover normal business cycles, including infrequent billing runs.
Legacy DMARC rollout flowchart showing quarantine at 25% and 100%, followed by reject.
The diagram includes historic percentage stages. Use the current rollout steps below: do not rely on pct= for staged enforcement, and choose reject only when the domain's use supports it.
- Confirm there is exactly one DMARC TXT result at _dmarc.yourdomain.com, including any hosted CNAME target.
- Collect aggregate reports long enough to identify normal sending sources.
- Resolve SPF, DKIM, domain matching, and record discovery failures for legitimate senders.
- Move to p=quarantine when legitimate senders are ready. Add t=y only if you also accept that older receivers can enforce quarantine immediately.
- Watch for legitimate failures and changes in source volume. Check bounce messages and test deliveries while waiting for aggregate reports.
- Remove t=y when testing is complete. Consider p=reject only when the domain's use and indirect-mail risk support it.
Quarantine test request, with enforcement possible on older receiversDNS
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 implementing RFC 9989 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.
Because RFC 7489 receivers ignore unknown tags, do not assume they honor t=y: plan for them to apply the declared p= value. A test flag also does not guarantee that a scanner will clear its enforcement warning.
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. Check the host, record type, record count, syntax, and public lookup result. DNS provider interfaces vary, but the published result must be the same.
Cloudflare DNS editor with a DMARC TXT record at _dmarc using p=quarantine.
|
|
|
|---|---|---|
Domain suffix appended twice | Wrong name | Use provider format |
CNAME target | No TXT result | Ensure the target returns one DMARC TXT record |
Literal extra quotes in the value | Parser error | Remove quotes stored as record content |
Two records | Invalid DMARC | Merge into one |
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. If you use a hosted CNAME at this name, update its served TXT policy rather than publishing a competing TXT record alongside the CNAME.
?
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.
- Large legitimate-looking volume appears in reports, but nobody owns it yet.
- Mail tied to billing, support, security, or account access fails DMARC.
- Important recipient paths break SPF and lack stable DKIM survival.
- 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. Assign an owner to fix the failing sources and set a condition for moving to quarantine.
If legitimate mail fails after enforcement
If delivery problems begin after the policy change, use the bounce response or the receiving system's Authentication-Results header to confirm a DMARC failure. Clearing the DNS warning alone does not prove that legitimate messages authenticate.
- Identify the affected sending source and check its SPF return-path domain or DKIM signing domain against the visible From domain.
- If critical mail is failing, temporarily set the applicable policy to none. Change p= in a directly applicable record or sp= when the subdomain inherits that policy. Keep rua= so reporting continues.
- Allow for the previous DNS TTL, then retest the affected sending source. A rollback does not recover messages already rejected; resend them after authentication is fixed.
- Repair the source configuration, confirm dmarc=pass in fresh test messages, then reapply the chosen enforcement policy and monitor new reports.
Use delivery logs during recovery. Aggregate reports usually arrive daily, so they cannot provide an immediate view of every message.
How Suped fits the workflow
Suped's DMARC reporting and email authentication platform organizes the sources that send as your domain and the authentication gaps that need attention. Review those sources before changing the policy, then use Hosted DMARC to manage the chosen policy.
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
- Raw reports need parsing before they are useful.
- Each policy adjustment needs DNS access.
- Review incoming reports on a schedule to detect failure spikes.
Suped workflow
- Review authentication results by sending source.
- Hosted policy staging reduces DNS edits.
- Threshold-based notifications flag failures in received report data.
Use Suped's source data to assign authentication fixes to the team that owns each sender. Configure failure-rate alerts to catch regressions after enforcement. Alerts based on aggregate reports depend on when receivers send those reports.
If you already know your desired policy, generate the DMARC TXT value and publish it. For ongoing management, Hosted DMARC reduces repeated DNS changes during policy staging.
How to confirm the warning is fixed
After publishing the new record, confirm it in authoritative DNS, then allow for cached answers to expire based on the previous TTL. Query public resolvers for exactly one usable DMARC TXT result with the intended enforcement policy, including any hosted CNAME target.
Compare public DMARC DNS answersBASH
dig TXT _dmarc.yourdomain.com +short dig @1.1.1.1 TXT _dmarc.yourdomain.com +short dig @8.8.8.8 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 on the same output line. 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 output lines that each start with v=DMARC1.
- There is one DMARC record for the domain.
- The record contains p=quarantine or p=reject and testing disabled (t=n or no t= tag).
- The record starts with v=DMARC1 and uses semicolons correctly.
- If rua= is configured, aggregate report delivery continues after the policy change.
- Important senders still pass DMARC after the change.
Send test messages through each critical source and inspect the receiving system's Authentication-Results header for dmarc=pass. SPF or DKIM pass alone does not prove DMARC passes. A DNS lookup verifies policy publication; message tests verify authentication.
If a security portal still shows the warning, check its refresh schedule as well as DNS caching. Confirm which visible From domain or subdomain it checks. A subdomain's own p=none record or an inherited sp=none can leave that subdomain without enforcement even when the parent uses p=reject. Also check for t=y and differences between current DNS Tree Walk discovery and legacy receiver behavior.
Frequently asked questions
No. p=none means DMARC evaluation is active, but enforcement is not. When the record has a valid rua= address, participating receivers can send aggregate reports. The policy does not ask them to quarantine or reject failures.
Yes, in most scanners. p=quarantine is an enforcement policy when testing mode is off. A scanner still flags the domain if its applicable subdomain policy remains none or if it requires reject specifically.
Use quarantine first unless the domain has controlled sending paths, clean DMARC data, stable aligned DKIM, and known indirect-mail behavior. Quarantine can remain the final policy for a general-purpose mailbox domain. Reject is better suited to dedicated sending domains and no-mail domains.
No. Both accept a valid DMARC policy of p=none as the minimum for bulk senders, provided messages pass the required authentication and alignment checks. A scanner can still warn that enforcement is not enabled.
Common causes are DNS or scanner caching, the wrong hostname, duplicate DMARC records, invalid syntax, testing mode, or a subdomain with a monitoring-only policy.
Reduce the risk by confirming legitimate senders pass DMARC while p=none is still published, then apply quarantine and monitor deliveries. Do not rely on t=y to prevent enforcement by older receivers. Keep a rollback plan for critical mail.
