"DMARC policy not enabled": what it means and how to fix it safely

A security scan, a deliverability tool or your mail provider has flagged your domain with "DMARC policy not enabled", "No DMARC record found" or similar. The fix is a single DNS record, but publishing the strictest version straight away can block your own mail. This guide explains what the warning means and how to clear it in a safe order.

What does "DMARC policy not enabled" mean?

Scanners word it differently, but the warning covers two situations:

Both mean the same thing in practice. Receivers have no instruction from you to junk or reject mail that forges your domain.

RFC 9989, the DMARC standard, calls p=none with reports Monitoring Mode: the domain owner "expresses no handling preference for messages that fail DMARC validation." Anything stricter is Enforcement. So "policy not enabled" usually means "you haven't reached enforcement yet."

How receivers show it in headers

If there's no record, the Authentication-Results header on a received message shows dmarc=none, which RFC 9989 defines as "No DMARC Policy Record exists for the Author Domain." Microsoft 365 may show dmarc=bestguesspass; Microsoft's own troubleshooting table says that means no DMARC record was published, Microsoft inferred a pass, and you should "publish an explicit DMARC record" (Microsoft Learn). With p=none and failing mail, Microsoft shows dmarc=fail action=none.

Why does it matter?

Three reasons:

• Spoofing. Without enforcement, nothing you publish tells receivers to stop a forged message that uses your exact domain in From. See what is email spoofing.
• Bulk sender rules. Google requires DMARC from senders of close to 5,000 or more messages a day to personal Gmail accounts (Google sender guidelines). Yahoo requires bulk senders to publish a valid policy of "at least p=none" (Yahoo Sender Hub). Microsoft asks the same of domains sending more than 5,000 messages a day to Outlook.com, and rejects mail that falls short with 550 5.7.515. For these rules p=none is enough; having no record is not.
• Visibility. Without an rua address you get no reports, so you can't see who sends as your domain.

Google Postmaster Tools shows this too. Its Compliance status dashboard lists "DMARC authentication" as a bulk sender requirement and marks each item "Compliant" or "Needs work" (Gmail Help). Its authentication troubleshooting advice is to "Set up DMARC authentication with a policy of quarantine or reject."

You're not alone. In our scan of the Tranco top 1,000 domains in October 2026, 265 had no DMARC record and 117 used p=none. With one invalid record, that's 38.3% not enforcing.

Why not just publish p=reject?

Because DMARC judges every message that uses your domain, including your own. Any service that sends as you without aligned SPF or DKIM starts failing the moment you enforce: the billing system, the website contact form, the CRM, the scanner in the office.

RFC 9989 section 5.1.5 explains why everyone starts at p=none: "to ensure that nothing's been missed in the initial SPF and DKIM deployments." Google recommends the same: "When you start using DMARC, we recommend setting the policy option (p) to none" (Google Workspace Admin Help).

The one exception is a domain that never sends email. There, p=reject is safe on day one; see protecting parked domains.

How do I fix "DMARC policy not enabled" safely?

Follow these steps in order. Each one is quick; the waiting is in step 6.

1. Check what's published now. Run the DMARC Checker on your domain. It shows whether a record exists, its policy, and any syntax errors such as two records at the same name or v=DMARC1 not first.

2. List every service that sends as your domain. Your mailbox platform, marketing tool, CRM, helpdesk, accounting software, web forms and devices. Ask each team what they use.

3. Make each service pass SPF or DKIM with your domain. DKIM signing with d= set to your domain is the most reliable route, because it survives forwarding. Google's DMARC guide says to contact each third-party provider "to make sure SPF and DKIM are correctly set up." Check with the SPF Checker and DKIM Checker, and see the per-provider steps for Microsoft 365, Google Workspace, Mailchimp and others.

4. Set up a reports mailbox. Microsoft recommends a dedicated mailbox or Microsoft 365 Group, not a user's own inbox.

5. Publish a monitoring record. Add a TXT record with the host _dmarc:

   v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
   

   Google suggests allowing 48 hours after setting up SPF and DKIM before adding DMARC. The DMARC Record Generator builds the record for you.

6. Read the reports and fix what fails. Aggregate reports arrive as compressed XML. Drop them into the DMARC Report Analyzer and follow how to read DMARC reports. Fix every legitimate source that fails. RFC 9989 says these must be addressed before you enforce. If a source keeps failing and you can't see why, why DMARC fails walks through the causes.

7. Move to quarantine, then reject. Once reports show your real senders passing, change p=none to p=quarantine, watch again, then move to p=reject.

That last step is what actually clears a "policy not enabled" warning. Step 5 alone clears "no DMARC record found".

How long should each stage last?

There's no single number. RFC 9989 says reaching enforcement "may take many months" depending on how often you send. For domains whose users post to mailing lists, section 7.4 suggests p=none "for at least a month," followed by p=quarantine "for an equally long period of time," before considering p=reject. Our p=none to p=reject rollout gives a practical timeline: at least a month at each stage.

You can also use the t=y test flag from RFC 9989 to try a stricter policy one level down first. DMARC record examples shows the exact records.

How do I confirm the fix worked?

DNS changes aren't instant, and scanners cache results. Check in this order:

1. Query the record directly. Run the DMARC Checker, or from a terminal: dig TXT _dmarc.example.com +short. You should see exactly one string starting with v=DMARC1.
2. Check a real message. Send an email from your domain to an outside mailbox and open the headers. Authentication-Results should now show dmarc=pass instead of dmarc=none (or Microsoft's bestguesspass). Our Email Header Analyzer pulls the result out for you.
3. Wait for the first reports. RFC 9989 asks receivers to send aggregate reports at least once every 24 hours, so the first files usually arrive within a day or two of publishing. Not every receiver sends them.
4. Re-run the scanner that raised the warning. If it still complains, it may be reading a cached result or flagging p=none on purpose. A "policy not enabled" warning on a p=none record is expected until you reach enforcement.
5. Check Postmaster Tools last. Google says its dashboard data is typically updated within 24 hours, so a fix won't show there straight away.

What will the first reports show?

Expect three kinds of source. Your own platforms (Microsoft 365, Google Workspace) should pass. Services you forgot about will show up failing, often with SPF passing for their own domain but not aligned with yours. Forwarders and unknown IP addresses will fail too. Fix the second group, ignore normal forwarding, and treat the rest as possible spoofing. That sorting is what lets you enforce with confidence.

Common mistakes when fixing the warning

What about subdomains?

A DMARC record on your main domain covers subdomains that don't have their own record. Microsoft notes it covers "all subdomains (including nonexistent subdomains) that don't have their own DMARC TXT record." Use sp and np if you want different policies; DMARC subdomain policy explains how. A scanner checking news.example.com may still report the parent's policy, which is correct.

Next steps

1. Run the DMARC Checker to see which of the two warnings applies to you.
2. If you have no record, publish p=none with an rua address today.
3. Collect at least a month of reports, fix failing senders, then move to quarantine and reject.
4. New to DMARC? Start with what is DMARC for the full picture.

DMARC stops forgeries of your domain at other people's inboxes. Phishing that reaches your own users from other domains is a separate problem, which inbound filtering such as iBlockSpam addresses; see how it works.

Related: moving from p=none to p=reject and DMARC quarantine vs reject. Before you enforce, iBlockSpam's DMARC monitoring shows which of your senders still fail, so the warning can be fixed without blocking your own mail.

Browse our other SPF, DKIM and DMARC guides.