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

DMARC policy not enabled is more than a technical warning, it means your domain is still exposed to spoofed email. In most cases, either no DMARC record exists or the record is set to p=none, which collects reports but does not tell inbox providers to block anything. The fix is to publish an enforced DMARC record at _dmarc.yourdomain.com.

If that warning just showed up in a scanner, the real question is simple: what is missing, and how do you fix it without disrupting legitimate mail? That matters because a domain can look fine in DNS while still offering no real protection. Until DMARC enforcement is in place, attackers can imitate your domain more easily, and mailbox providers have less guidance on how to handle suspicious messages.

What the Warning Actually Means

DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, sits on top of SPF and DKIM. SPF checks which servers may send for your domain, and DKIM signs messages so receivers can verify they weren't altered. DMARC then checks whether those signals align with the visible From address, so the message really matches the domain your customers see.

A DMARC policy not enabled warning usually means one of two things. Either there's no DMARC TXT record at all, or the record exists but uses p=none, which is monitoring-only. That state tells receiving servers to report failures, not act on them, so spoofed mail can still get through.

Why alignment matters

Alignment is the part many owners miss. You can have SPF and DKIM in place, but if they don't line up with the From domain, DMARC still won't enforce anything. That's why checking only SPF or only DKIM gives you a false sense of safety.

A quick internal refresher can help here, and we've covered the basics in our guide to what DMARC is and how it fits into email security. The key point is simple, DMARC turns authentication into a policy decision.

For a small business, this is about more than blocking fakes. Unenforced mail can land in spam or get treated as suspicious by receivers that do enforce DMARC, which hurts outreach and customer trust. If your domain looks “set up” but still says DMARC policy not enabled, you're seeing the gap between visibility and actual protection.

Why You Are Seeing It

The warning shows up for a few common reasons, and each one points to a different kind of fix. A brand-new domain may never have had a DMARC record published. A longer-running domain may have a record stuck at p=none because nobody revisited it after setup. A migration can also break the record if the DNS host changed and the TXT value didn't move cleanly.

Fresh domain versus stale setup

A fresh domain often looks healthy everywhere else, which is why this warning catches people off guard. The site works, mail flows, and SPF may already be present, but DMARC never got added. In that case, the scanner is telling you the domain is visible in DNS but not protected by a DMARC policy.

A stale setup is subtler. Someone may have copied a basic record years ago, chose p=none, and left it there. That record still reports on mail, but it doesn't stop anything, so the warning keeps appearing.

Third-party senders complicate the picture

Newsletters, CRMs, ticketing systems, and payment notices all add moving parts. If those services send mail for you, they can change how SPF and DKIM behave, which affects whether DMARC can enforce cleanly. That's why the warning often shows up right when a business starts sending more serious volume or adds another tool to the stack.

Practical rule: if you recently added a sender, changed DNS providers, or moved your mail platform, check DMARC before you change anything else.

The 2026 adoption gap makes this common, not unusual. Valimail's research found that 75-80% of domains with published DMARC records are stuck in monitoring mode, leaving themselves without actual enforcement protection.

That context explains why your warning is so often just a sign that the domain is still in the broad non-enforcing majority.

How to Check Your Current DMARC Record

Start with the DNS record, not with the scanner's opinion. You need to see what is published before you change anything, because a record that looks fine in a dashboard can still be missing or misread in live DNS. That matters for deliverability and for brand protection, since a weak or broken DMARC setup can leave receivers guessing about whether your mail is legitimate.

A quick lookup with dig or nslookup can show whether a TXT record exists at the DMARC host name. If you prefer a web tool, an MXToolbox-style lookup works as a backup and helps confirm what third parties can see. The point is to inspect the live DNS, not a cached copy or a remembered setting from last year.

Reading the record line by line

A DMARC record is a TXT value made of tags. The main ones are v for version, p for policy, rua for aggregate reports, ruf for failure reports, pct for percentage, sp for subdomains, and the alignment tags adkim and aspf. A record that begins with v=DMARC1; p=none is the clearest sign that you are still in monitoring mode.

A typical monitoring record reads like a label on a file folder, version first, then policy, then reporting and alignment details. If p=none is present, the domain is not enforcing anything yet. If you see a malformed record, or the version tag is missing, the scanner may treat it the same way as no policy at all.

If your DNS is managed at your registrar, check the domain's DNS section there first. If a third-party host handles DNS, look in that platform instead, because that is where the published record lives.

If you need a closer look at SPF before you decide what to fix next, review how SPF records work and how to create one. SPF and DMARC are linked, so confirming both helps you avoid chasing the wrong error.

Step-by-Step Fix

Start by publishing a valid DMARC TXT record at the _dmarc host, then move from monitoring to enforcement in stages. That approach keeps legitimate mail flowing while you learn which systems send as your domain. It also gives you time to catch alignment problems before receivers start treating failed messages differently.

Here's the simplest safe starting point for a small business, v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r. That setup tells mailbox providers to monitor, report, and leave delivery alone while you review the results. If you are still sorting out SPF, review how to create an SPF record and why it matters for DMARC alignment, since SPF and DMARC work together and a weak SPF record can make a DMARC rollout look broken when it is really just misaligned.

DMARC policy tags and what each one does

Once the monitoring record is live, you can tighten it to p=quarantine, then to p=reject after your reports show the legitimate sources are aligned. Quarantine tells receivers to place failing mail in spam, while reject stops it at the SMTP layer. That staged path protects inbox placement and brand trust while you move from watching reports to enforcing policy.

A few DNS hosts label the field differently, but the setup is the same. The host name is _dmarc, the value is the policy string, and the save button is the last step. If you send from a custom domain on Typewire, you still use the same DNS record format, so there is no special DMARC version for that setup.

Rolling Out Enforcement Safely

The cleanest rollout is a three-stage path, monitoring, quarantine, then reject. You should not jump straight to reject unless you already know every legitimate sender is aligned. If you do, you risk blocking mail from your own newsletters, invoicing tools, or help desk systems.

Monitoring first, then tightening

A typical monitoring period is two to four weeks at p=none, because you need enough report data to see all the mail streams that speak for your domain. During that time, you're looking for normal senders, not just obvious ones. Marketing platforms, receipt systems, and password-reset mail can all show up in the aggregate data.

After that, many teams move to p=quarantine for another short test window. The exact time matters less than the signal, which is whether legitimate mail still aligns while suspicious mail gets pushed into spam. Once those reports look clean, p=reject becomes the final step.

For a small business with only one or two sending sources, the rollout is often faster because there's less to map. That doesn't mean you skip the monitoring stage, it just means you can review the report set more quickly. The goal is confidence, not speed for its own sake.

Use the reports as your checklist. If every normal sender is aligned and nothing unexpected keeps appearing, enforcement is usually ready.

The global adoption numbers make this staged approach even more sensible. As of August 2026, DMARCDKIM.com's monitoring of 1.3 million domains found that 68.6% have no effective DMARC protection, while only 11.5% have full
protection with p=reject at 100% enforcement. That's a reminder that strong enforcement is still the exception, so a careful rollout matters.

Troubleshooting Common Pitfalls

A first DMARC rollout usually goes off track for ordinary reasons. A third-party sender may be passing SPF or DKIM in its own way, but not aligning with your visible From domain. The report inbox may also be full, closed, or pointed at the wrong address, so you never see the data that should guide the change. A policy change made before those reports are reviewed creates the same problem, because the record is published but the domain still has blind spots.

If reports stop arriving, check the rua address first. A typo in the reporting address or a mailbox that no longer accepts mail can leave you without feedback while DMARC is still publishing. If you use a parser, confirm that it still accepts the inbound XML files and that someone reviews the dashboard, because raw reports are easy to miss once they start piling up.

Common breakpoints and quick fixes

A sender can pass SPF and still fail DMARC if the visible From domain does not align. DKIM can fail for the same reason when the signing domain belongs to a vendor instead of your own domain. The fix is to have the third-party platform sign mail with your domain, or to authorise that sender correctly in its setup so the authenticated domain matches the one recipients see.

Another common slip is setting pct=100 too early. That tells receivers to apply the policy to all mail, which only works once alignment is steady across your normal mail streams. If you still see failures in the reports, lower the rollout pressure first, then tighten the policy after the aligned traffic stays clean.

A practical check helps catch mistakes quickly. Send mail from a source you know is not authorised. If DMARC is working at the stage you chose, that message should be quarantined or rejected.

If you need a clearer picture of how SPF, DKIM, and DMARC fit together, our deliverability note on email sender authentication and inbox placement is useful background. It explains why one misconfigured sender can affect the whole domain.

Verifying It Is Working

A DMARC rollout should start acting like a real filter, not just a line in DNS. Re-run the lookup and confirm the published record now shows p=quarantine or p=reject. Then check that third-party scanners stop reporting the domain as missing a policy. If the warning still appears, the record may be published at the wrong host, or an old value may still be cached somewhere.

The clearest live test is to send a message from a sender you have not authorised. With quarantine, that mail should land in spam or junk. With reject, the receiving server should block it. That difference matters because it shows the policy is protecting your brand and not just sitting there for display.

A simple final checklist

• Confirm the record exists: Make sure the DMARC TXT entry is published at the right host.

• Check the policy: Verify it moved from p=none to p=quarantine or p=reject.

• Review the reports: Look for aligned senders before you tighten further.

• Test the result: Send a non-authorised message and see whether it is blocked or filtered.

For a business using a custom domain on Typewire, the same DNS steps apply, and the result is easy to observe. Your domain stops saying “monitor only” and starts telling receivers how to handle spoofed mail. That gives you a clear signal that your brand is harder to impersonate and your legitimate mail has a cleaner path to the inbox. For a wider view of how authentication supports delivery, see email sender authentication and inbox placement.