Defaults.Exposed › Виправлення › Guides

"DMARC Policy Not Enabled": What Checkers Mean, and the Honest 5-Minute First Step (2026)

Опубліковано 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

“DMARC policy not enabled” means one of two different things: your domain has no DMARC record at all, or it has one set to p=none. Only 10.59% of domains — 27,640,987 of 261,086,232 — enforce a DMARC policy, according to the Defaults.Exposed census. Publishing a monitoring record takes five minutes; enforcement is a project.

This guide decodes the warning, gives you the exact TXT record to publish and exactly where to put it, walks through the syntax slips that make first attempts fail, and sets an honest expectation of what your first week of DMARC reports looks like. It is deliberately not a “fix DMARC in 5 minutes” guide — the five minutes gets you visibility, not protection.

What does “DMARC policy not enabled” actually mean?

Checkers like MXToolbox collapse two different findings into one orange warning, and the fix path depends on which one you have:

Data as of 2026-06-29.

The first row is where most of the internet lives: 75.11% of graded domains publish no DMARC record at all, and another 14.29% sit at p=none. The inverse of the last row is the number that matters: 89.41% of domains have no enforced DMARC policy — of 261,086,232 graded domains in the census. If your checker shows the warning, you are in the overwhelming majority. That is not reassurance; it is the reason spoofing remains cheap.

One clarification that saves confusion later: DMARC is the policy layer on top of SPF and DKIM, checked against the From header your recipient actually sees. “Not enabled” means you haven’t told receivers to do anything yet. If the three policy values are new to you, the plain-English explainer is what is DMARC: none, quarantine, reject.

What can you honestly fix in five minutes?

Publishing a record. That is the whole honest claim.

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

Five minutes after this TXT record goes live, receivers that check DMARC will start compiling daily reports about who is sending mail as your domain — legitimate servers and imposters alike. That visibility is genuinely valuable and genuinely instant.

What it does not do: p=none protects nothing. Spoofed mail is delivered exactly as it was yesterday, and a checker re-scanning tomorrow may still say “policy not enabled” — correctly, because the green tick is reserved for quarantine or reject. We’ve written up why in p=none is not protection; the staged path to a policy that actually blocks spoofing is from p=none to p=reject. The five-minute step below is how you start; that guide is how you finish.

How do you publish your first DMARC record?

1. Run the free scan before touching DNS. It tells you which of the two findings you actually have — no record vs. p=none — and whether SPF and DKIM are in place underneath, which decides how fast you can move to enforcement later.
2. Pick an address to receive reports. A dedicated mailbox like dmarc-reports@yourdomain is fine to start. If you use a report-analysis service instead, see the FAQ below — third-party addresses have a silent gotcha.
3. Add a TXT record at the host _dmarc. In most DNS control panels (see the IONOS DMARC setup guide for a worked example) you enter _dmarc in the host/name field — the panel appends your domain automatically, producing _dmarc.yourdomain.com. Value: v=DMARC1; p=none; rua=mailto:[email protected]
4. Verify it resolved. dig TXT _dmarc.yourdomain.com (or any online checker) should return exactly one record beginning v=DMARC1. Most DNS changes are visible within minutes; a low TTL helps.
5. Re-scan. Your report will show DMARC present in monitoring mode — an honest reflection of where you are: reporting on, enforcement pending.

One record covers your subdomains too: receivers that find no record on mail.yourdomain.com fall back to the organizational domain’s policy, so you don’t need a record per subdomain to start monitoring.

What are the most common mistakes when adding the record?

Nearly every failed first attempt is one of these — and they matter, because an unparseable record is treated as no record. The census counts 48,648 published DMARC records that fail to parse; the misspellings people actually publish are catalogued in the DMARC typos census.

• Wrong host. The record must live at _dmarc.yourdomain.com, not the apex. On the bare domain it does nothing, and checkers keep reporting “no DMARC record found”.
• Double-appending the domain. Typing _dmarc.yourdomain.com into a panel that auto-appends gives you _dmarc.yourdomain.com.yourdomain.com. Enter just _dmarc.
• Commas instead of semicolons. Tags are separated by ;. An unparseable record is treated as no record.
• Missing or misplaced v=DMARC1. It must be the first tag, spelled exactly; records starting with p= fail parsing.
• mailto: missing from rua. rua=dmarc@yourdomain is invalid; it must be rua=mailto:[email protected].
• Two DMARC records. Receivers finding more than one v=DMARC1 record ignore them all — same failure family as multi-record SPF.
• Smart quotes from copy-paste. Curly quotes or non-breaking spaces smuggled in from a document break parsing. Retype the record if a checker says it’s malformed but it looks right.

What will the rua reports look like in week one?

Set expectations now so you don’t conclude it’s broken:

• They arrive roughly daily, per receiver. Google typically sends one aggregate report every 24 hours; Microsoft, Yahoo and others on their own cycles. For a small domain, week one usually means a handful of emails, mostly from [email protected].
• They are compressed XML attachments, not a dashboard. Raw, they’re near-unreadable; a free parser turns them into a sender table.
• Volume tracks your mail volume. If you send little mail, or mostly to providers that don’t report, expect sparse data. Two quiet weeks is normal for a low-volume domain — verify the record with dig rather than assuming it failed.
• Expect surprises. Most domains discover senders they forgot — the CRM, the invoicing tool, the contact form. Each one needs SPF or DKIM aligned before you can enforce. If reports show DMARC failing while SPF and DKIM individually pass, that’s an alignment problem — see DMARC fails but SPF and DKIM pass.

And do ask for the reports at all: 64.3% of domains with a DMARC record publish no rua= address, so they get no reports from it — the census cut on that is in DMARC publishing blind. Everything you learn here feeds the enforcement rollout — monitoring is week one of that project, not a destination. Parking at p=none indefinitely is the most common way domains end up in the 89.41%.

Frequently asked questions

Will publishing p=none hurt my email deliverability? No. p=none changes nothing about how receivers treat your mail — it only requests reports. It can help: Google and Yahoo’s bulk-sender requirements demand at least a p=none DMARC record from high-volume senders, so publishing one is a compliance floor, not a risk.

I published the record — why does the checker still say “policy not enabled”? Because it’s telling you the truth: your policy is none, and checkers reserve the pass for quarantine or reject. You’ve joined the domains that monitor but don’t enforce — as of 2026-06-29, only 10.59% of 261,086,232 graded domains enforce. The warning clears when you complete the rollout to enforcement.

Do I need SPF and DKIM set up before I add DMARC? You need at least one of them, aligned, for your mail to pass DMARC — but you don’t need them perfect before publishing p=none. Monitoring is precisely how you find what’s broken: 70,368,600 of 261,086,232 graded domains (as of 2026-06-29) have soft SPF and no DMARC enforcement, and reports are how they’d learn what’s stalling them.

Can I send reports to a third-party analyzer instead of my own mailbox? Yes — but a rua address on a different domain requires the vendor to publish an authorization record (yourdomain._report._dmarc.vendor.com), or receivers silently withhold reports. Reputable services do this automatically; if reports never arrive, check this first.

Send the owner the report

If you’re fixing this for a client or an employer, don’t let the work be invisible. Re-run the free scan after the record resolves and forward the graded report: it shows DMARC moving from absent to monitored, timestamped and in plain English — and it shows what’s next on the path to enforcement. Owners increasingly need exactly this evidence for cyber-insurance renewals and supplier security questionnaires, and a one-page graded report answers those questions better than a screenshot of a DNS panel ever will.

Check your domain free

See which of the two findings you have — no record or p=none — and what’s underneath it, privately and owner-only.

Check your domain → · Fix DMARC → · From p=none to p=reject → · How we grade → · Aggregate data only. Data stored and processed in the EU.