DMARC Policy Not Enabled: How to Fix It Safely
In brief
Fix the DMARC policy not enabled warning: check the existing DNS record, verify sender alignment, then edit the policy in Cloudflare, GoDaddy, or your DNS host.

“DMARC policy not enabled” usually means your domain publishes a DMARC record with p=none, which requests monitoring without enforcement. To clear that warning safely, verify your legitimate senders first, then edit the existing policy to request quarantine or rejection of mail that fails DMARC.
Start with the DMARC checker. Read the returned record before changing DNS: a missing record, duplicate records, and a valid monitoring policy need different fixes.
What does your DMARC record actually show?
A “DMARC quarantine/reject policy not enabled” warning commonly points to p=none. The warning alone does not establish whether your legitimate email passes DMARC or reaches the inbox.
| What the lookup shows | What to do next |
|---|---|
One valid record containing p=none | Keep monitoring while you verify senders, then edit that record to enable enforcement. |
| No DMARC record found | Follow the missing DMARC record guide. Check the exact domain and any applicable parent policy before adding anything. |
| Multiple DMARC records or a syntax error | Repair the record first. The multiple-record guide covers the duplicate-record case. |
A valid p=quarantine or p=reject record, but the warning remains | Check the queried domain, cached results, and the complete record. Do not add a second policy just to clear the warning. |
DMARC needs either SPF or DKIM to pass with alignment to the visible From domain. Passing SPF for an unrelated sending domain is insufficient. See Microsoft's DMARC guidance for the authentication and alignment requirements.
How do you check the existing policy?
Check the domain after the @ in the message's visible From address. For person@example.com, look up TXT records at _dmarc.example.com:
dig TXT _dmarc.example.com +shortOn Windows, use:
nslookup -type=TXT _dmarc.example.comA monitoring record might return:
v=DMARC1; p=none; rua=mailto:reports@example.com;This is an illustrative record. reports@example.com is a placeholder, not a reporting address to paste into your DNS.
The p=none tag explains the enforcement warning. The rua tag requests aggregate reports at the specified destination; check that the address belongs to your reporting service or a mailbox you operate. For help reading those reports, see how to understand DMARC reports.
If your From address uses a subdomain, check that exact name too. DMARC policy discovery can use a parent policy when no usable record is found at the initial name, so an empty subdomain lookup is not conclusive. See the DMARC setup guide for configuration beyond this warning.
When is it safe to enable quarantine or reject?
Enable DMARC enforcement after you have verified the legitimate services that send as your domain. Microsoft's recommended rollout starts with monitoring and moves to stronger policies after addressing authentication failures.
Before changing p=none, check that:
- Every legitimate sender is accounted for. Include employee mail, marketing, support, billing, and transactional services. Assign an owner to each.
- Reports cover your actual sending cycle. Include infrequent invoices and campaigns, not just a quiet day of employee email. The review window depends on when your business sends.
- Each legitimate stream passes aligned SPF or DKIM. Investigate failures using the sender's configuration and a representative message. Do not authorize unfamiliar sources merely because they appear in reports.
- Real messages have been tested. Use the email deliverability test to inspect messages sent through important streams. A public DNS lookup cannot establish their authentication results.
- You can recover from a bad change. Save the current record, its TTL, the DNS owner's details, and the conditions that would make you restore the previous policy.
How do you change p=none without adding another record?
Edit the existing DMARC TXT record at your authoritative DNS host once your sender checks are complete. Preserve its reporting destinations and other intentional settings.
For example, a verified domain with this illustrative record:
v=DMARC1; p=none; rua=mailto:reports@example.com;could change only the policy value:
v=DMARC1; p=quarantine; rua=mailto:reports@example.com;Do not paste this example over your own record. Quarantine requests suspicious handling for DMARC failures, often a spam-folder placement; reject requests refusal. Receivers make the final handling decision. The quarantine-versus-reject comparison explains that choice.
After validating legitimate mail under quarantine, consider moving the same record to p=reject. Avoid old instructions that add pct=25 or another percentage: RFC 9989 removed the pct tag because intermediate percentages were applied inconsistently.
If a service manages your DMARC record through DNS delegation, make the policy change through that service's supported controls. Do not replace its delegation with a new TXT record without checking the integration.
Editing an existing DMARC record in Cloudflare
For a domain whose DNS is hosted on Cloudflare:
- Open the domain in Cloudflare and go to DNS → Records.
- Find the existing
_dmarcTXT record and select Edit. - Change its
p=value only after completing the sender checks above. Preserve the other intended tags. - Select Save, then query the record again.
Editing an existing DMARC record in GoDaddy
For a domain whose DNS is hosted on GoDaddy:
- Open Domain Portfolio, select the domain, then select DNS.
- Find the existing
_dmarcTXT record and select Edit beside it. - Update the policy in Value, retaining your real reporting address and other intended tags.
- Select Save and complete any account verification requested.
What if the warning remains after the change?
Retest the same domain after saving, and compare the returned TXT value with the value you intended to publish. DNS caches can still return the earlier record until its cached TTL expires. GoDaddy notes that updates can take up to 48 hours globally, although many appear sooner.
If the expected value never appears, check the authoritative DNS host, the _dmarc name, and whether you edited the root domain or a sending subdomain. If the checker returns the new record but still warns, inspect its detailed findings and any testing or subdomain settings before making another change.
Send representative messages again and review subsequent aggregate reports. A cleared checker warning confirms neither delivery nor correct authentication for every sender. If legitimate mail starts failing because of the policy change, restore the saved policy while you investigate that sender.
Sources
Questions readers ask
Frequently asked questions
Does p=none mean DMARC is disabled?
p=none means a DMARC monitoring policy is published, but it requests no enforcement handling for DMARC failures. The DMARC checker can show the published record; reports and message tests establish how your senders authenticate.
Should I add a second DMARC record with p=reject?
Do not add a second DMARC policy record to enable reject. Edit the existing record after verifying legitimate senders. The DMARC generator builds one complete record with the new policy from the settings you enter, including your current reporting address, so you paste a single value. Multiple DMARC records at the same lookup name are discarded during DMARC policy discovery, which can leave the intended policy unused.
Will enabling a DMARC policy fix email going to spam?
Enabling DMARC enforcement does not guarantee inbox placement. First test the affected message and investigate its authentication results and the receiving provider's response. Changing the policy without checking legitimate senders can create additional delivery failures.

Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, agentic DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →


