“DMARC Policy Not Enabled”: What It Means and How to Fix It

ByBNW TEAM

You ran your domain through an email testing tool and got a warning: DMARC Policy Not Enabled. Maybe your deliverability is fine. Maybe your agency flagged it in an audit. Either way, it’s worth fixing, and it’s not as risky as it sounds if you do it in the right order.

This guide explains what the warning means, why it matters and the step-by-step path from “not enabled” to fully protected, without blocking your own email along the way.

What the warning actually means

DMARC is a DNS record that tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication. The warning shows up in one of two situations:

  1. You have no DMARC record at all. Receivers have no instructions, and nothing tells them to distrust fake mail sent as your domain.
  2. You have a DMARC record set to p=none. This is monitoring mode. Receivers send you reports, but they don’t act on failures. To most testing tools, that still counts as “policy not enabled”.

In both cases, anyone can send email that appears to come from [email protected], and mailbox providers won’t stop it on your behalf.

Why it matters

  • Phishing and invoice fraud. Spoofed emails from your domain can target your customers, suppliers and staff. The damage lands on your brand.
  • Gmail, Yahoo and Outlook.com now require bulk senders to publish DMARC. A record at p=none meets the minimum, but an enforced policy is a stronger trust signal.
  • Without DMARC reports, you have no idea who is sending mail as your domain, legitimate or not.

Step 1: Run a DMARC check to see where you stand

Start with a dmarc check on your domain. Look at three things in the result:

  • Whether a record exists at yourdomain.com, and what its policy (p=) is.
  • Whether SPF and DKIM pass, because DMARC is built on top of them.
  • Any syntax errors, such as missing semicolons or a record published in the wrong place.

Save the result. You’ll run the same check after each change.

Step 2: Make sure SPF and DKIM pass for every sender

DMARC passes when SPF or DKIM passes and matches the domain in the visible From address. Before enforcing anything, list every service that sends email as your domain:

  • Your mailbox provider (Google Workspace, Microsoft 365).
  • Newsletter and marketing platforms.
  • CRM, helpdesk and invoicing tools.
  • Your website (contact forms, WooCommerce order emails).

Each needs to be included in your SPF record, signing with DKIM on your domain, or ideally both. DKIM is the safer bet because it survives forwarding.

Step 3: Publish a monitoring record

If you don’t have a record yet, add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]

The rua address receives aggregate reports, usually once a day from each major mailbox provider. If you send reports to an address on a different domain, that domain must publish a small authorisation record, or receivers won’t deliver the reports.

Step 4: Read the reports for two to four weeks

DMARC reports are XML files, which are unpleasant to read by hand. A DMARC report analyser turns them into a list of sending sources with pass and fail counts. You’re looking for:

  • Legitimate senders that fail. Fix their SPF or DKIM before moving on.
  • Unknown senders. Often spoofing, sometimes a tool someone in marketing signed up for and never mentioned.

Move to the next step only when your legitimate mail passes consistently.

Step 5: Enforce gradually

Switch to quarantine, which sends failing mail to spam rather than the inbox. Many teams roll it out in stages with the pct tag, which applies the policy to a share of failing messages:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Raise pct to 50, then 100, watching reports at each step. Once everything has looked clean for a few weeks, move to the final policy:

v=DMARC1; p=reject; rua=mailto:[email protected]

At p=reject, receivers block spoofed mail outright and the warning disappears.

A realistic timeline

Week Policy What you’re doing
0 none Publish the record, start collecting reports
1–4 none Fix SPF and DKIM for every legitimate sender
4–6 quarantine, pct=25 to 100 Watch for legitimate mail landing in spam
6–10 quarantine Confirm reports stay clean
10+ reject Full protection; keep monitoring

Small businesses with one or two sending tools often move faster. Larger organisations with many systems may need longer.

Don’t forget subdomains and unused domains

  • The sp= tag sets the policy for subdomains. Without it, they inherit the main policy.
  • Domains that never send email are easy targets for spoofing. Protect them with v=spf1 -all and a DMARC record at p=reject.

Common mistakes

  • Two DMARC records on the same name. Receivers ignore both. Keep exactly one.
  • Publishing at the root of the domain instead of at _dmarc.
  • Jumping straight to p=reject before reading reports, which blocks your own invoices and newsletters.
  • Setting it and forgetting it. A new email tool or a DNS migration can break alignment months later.

Keep it fixed

The warning is easy to clear and just as easy to bring back. A DNS provider change can drop your record, and a new marketing tool can start failing alignment overnight. Re-run a check whenever your email setup changes, or use a monitoring service that grades your records and alerts you when SPF or DMARC changes. FastPing, for example, does this for SPF, DKIM and DMARC on a schedule, so you hear about a broken record before your open rates do.