DMARC Policy Not Enabled: How to Fix It

Your domain has a DMARC record, but it may still be wide open

A DMARC policy warning usually means the domain has no usable DMARC record, has more than one DMARC record, or is still set to p=none. With p=none, receivers can send reports, but you are not asking them to quarantine or reject mail that fails DMARC.

Do not switch straight to p=reject until every real sender is checked. DMARC passes when SPF passes and aligns with the visible From domain, or DKIM passes and aligns with that same From domain. A billing app, CRM, support desk, or newsletter tool can send mail that looks valid to users but still fails DMARC alignment.

Start with DNS. Look up the TXT record at _dmarc.yourdomain.com. A discovery record often looks like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The rua address receives aggregate reports that show which sources pass, fail, and align. If you need a quick read, the free DMARC report reader can turn a raw aggregate file into sender names and pass rates.

• Confirm there is exactly one DMARC TXT record for the domain.
• Make sure it starts with v=DMARC1 and has a valid p= value.
• Use p=none while you find and fix legitimate senders.
• Add a rua=mailto: address that someone reviews.
• Decide whether subdomains need their own records or an sp= policy.

Fix SPF and DKIM before changing policy

A stronger DMARC policy only helps when real mail can prove it belongs to your domain. SPF and DKIM are the two proof paths. Alignment is the part that breaks most rollouts.

SPF is a TXT record on the envelope sender domain, often seen as the return-path or bounce domain. It lists which mail servers may send for that domain. Publish one SPF record, include only active senders, and stay under the SPF 10 DNS lookup limit in RFC 7208. Too many nested include:, mx, a, ptr, or exists checks can cause a permanent SPF error. Use ~all while you are still testing. Use -all after the list is complete.

DKIM signs mail with a private key at the sender and a public key in DNS. Each sender uses a selector, such as selector1._domainkey.yourdomain.com. Turn on DKIM in every platform that sends as your domain. Check that the DKIM d= domain aligns with the visible From domain. DKIM often survives forwarding better than SPF, so fix it even when SPF already passes.

• List every sender: Google Workspace, Microsoft 365, CRM, help desk, billing, marketing, and website forms.
• Remove old SPF includes and keep the active path under 10 DNS lookups.
• Publish each DKIM selector from each sending platform.
• Send test mail from every source and check SPF pass, DKIM pass, and DMARC pass.
• Use the free domain scorecard to catch missing SPF, DKIM, DMARC, MX, and blocklist issues.

Move from p=none to enforcement in stages

The safe path is simple. Collect reports, fix real senders, then raise enforcement. That protects good mail while closing the spoofing gap.

Leave p=none in place until aggregate reports show that normal senders pass DMARC. Then move to p=quarantine. That asks receivers to treat failing mail as suspicious, often by placing it in spam. Receivers can still use their own local rules, so watch reports, bounces, and user complaints. When quarantine is clean, move to p=reject. Reject asks receivers to refuse failing mail.

Older DMARC rollout guides may suggest pct= values such as pct=10. Current DMARC guidance no longer relies on that tag, and receivers vary, so do not treat it as your main safety control. Use reports, sender fixes, and a quarantine step before reject.

A normal enforced record can be as short as v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com. Strict alignment with adkim=s or aspf=s is stronger, but it can break third-party senders that use a related domain. Keep relaxed alignment unless you have tested strict mode across every sender.

• Week 1: run p=none with aggregate reports and identify all sources.
• Week 2: fix failing legitimate senders and remove dead services from SPF.
• Week 3: set p=quarantine and watch reports, bounces, and complaints.
• Final: set p=reject after normal mail passes by aligned SPF or DKIM.
• Keep reports on after enforcement so you catch drift when a vendor changes mail flow.

Why mail can still land in spam after DMARC passes

DMARC proves identity. Inbox placement also depends on reputation, content, recipient behavior, and DNS health.

Gmail and Microsoft expect authenticated mail, aligned domains, low complaint rates, and clear unsubscribe paths for bulk mail. They also look at domain and IP reputation, sudden volume spikes, old lists, spam traps, URL reputation, attachment risk, and whether people open, reply, delete, or mark messages as spam. DMARC passing helps, but it does not create trust by itself.

Check MX records so replies and bounces work. Check public blocklists when delivery drops, while remembering that mailbox providers also use private reputation systems. Keep marketing and transactional mail separated when volume grows. Use a sending domain people recognize. Warm new domains slowly.

• Keep SPF, DKIM, and DMARC passing for every mail stream.
• Use Google Postmaster Tools and Microsoft sender guidance when you have enough volume.
• Remove inactive recipients instead of mailing them forever.
• Use clear From names and subject lines that match the message.
• Monitor blocklists, bounces, complaints, and authentication drift together.

Do not mix DMARC with AI search crawl rules

Email authentication controls who can send as your domain. Robots.txt states crawler access rules for your website. They solve different problems.

If your site needs to appear in AI answers, allow the crawlers that power live AI search: OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google Search and AI Overviews, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

Training controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is a site's stated policy, not proof of what a bot did. Perplexity-User and Bytespider have been reported to ignore it, so use server logs and edge controls if behavior matters.

Only Googlebot documents JavaScript rendering. If important content appears only after client-side JavaScript runs, other AI crawlers may miss it. Treat that as an undocumented risk. Test the HTML and crawler access. The free AI visibility checker is useful for that separate website problem.