Introduction
"No DMARC record found" is the most-Googled DMARC error message. Sometimes it means exactly what it says — there's no record. More often, the record exists but isn't where the checker expects to find it. This article walks the fix for both cases.
Why this topic matters
This error blocks the entire DMARC workflow. A checker, an audit tool, or a mailbox provider sees "no DMARC record" and treats the domain as unconfigured. Receivers default to no enforcement; auditors flag the gap; compliance fails. Fixing it is usually a five-minute job — once you know which fix applies.
Case 1: You haven't published a record yet
If dig +short TXT _dmarc.yourdomain.com returns nothing, the record genuinely doesn't exist. Publishing it is the fix:
- Compose a minimal record:
v=DMARC1; p=none; rua=mailto:[email protected] - In your DNS provider, add a TXT record at name
_dmarc, value the string above, TTL 3600. - Wait 1-5 minutes for DNS propagation.
- Re-test with
dig.
How to create a DMARC record step by step covers the full first-record workflow.
Case 2: The record is published but at the wrong DNS name
The most common "no record found" cause. DMARC requires the record at _dmarc.yourdomain.com — the underscore prefix is mandatory.
Check both:
“bash dig +short TXT _dmarc.yourdomain.com # correct dig +short TXT yourdomain.com # wrong but common dig +short TXT dmarc.yourdomain.com # also wrong “
If you see your DMARC string at the second or third name, you've published to the wrong place. In your DNS provider, the record name field should be _dmarc (just the underscore prefix; the domain is appended automatically). Move or recreate the record at the correct name.
Case 3: DNS provider quirks
Some DNS providers handle underscore-prefixed names oddly:
- GoDaddy: The record name field needs to literally start with
_. - Cloudflare: Use the record-management UI rather than the "DMARC" preset, which sometimes adds escape characters.
- AWS Route 53: TXT records require the value to be in double quotes. Some other providers add quotes automatically; double-check yours doesn't double-quote.
- Old cPanel installations: Sometimes strip leading underscores. Verify the record after saving.
Case 4: TTL hasn't propagated yet
If you just added the record, propagation takes 1-15 minutes typically, up to 24 hours in extreme cases (high TTL on the parent zone). Wait 15 minutes and retest before assuming anything is wrong.
Case 5: Multiple DMARC records
If dig +short TXT _dmarc.yourdomain.com returns more than one line, you have duplicate records. Receivers ignore all of them, and many checkers report "no record" rather than "multiple records." Delete the duplicates, keep the most recent.
Step-by-step troubleshooting approach
- Direct DNS query.
“bash dig +short TXT _dmarc.yourdomain.com “
- Output empty → continue to step 2.
- One record returned → record exists, problem is elsewhere (why your DMARC record is not working).
- Multiple records → delete duplicates.
- Check the wrong-name locations.
“bash dig +short TXT yourdomain.com dig +short TXT dmarc.yourdomain.com “
If your DMARC string appears here, you published to the wrong name.
- Check from outside. Some DNS issues only surface when querying authoritative servers from a different network. Tools like dig from a public resolver confirm propagation.
- Verify in your DNS provider UI. Log in, look for the TXT record at
_dmarc. If present in the UI but not via DNS lookup, it hasn't propagated or wasn't saved.
- Try a different checker. Some online DMARC checkers cache aggressively. Force a fresh lookup or try a different one.
Best practices
- Always test with
digafter publishing. Don't rely solely on online checkers for the first verification. - Document your DNS provider's quirks. When you find one (Cloudflare's UI, GoDaddy's name field), note it for next time.
- Keep TTL low during initial setup. 300-3600 seconds while iterating; raise once stable.
- Validate from outside your network. A public DNS resolver tells you what receivers see.
Recommended next step
If your record is published correctly and "no record found" persists for more than 24 hours, the issue is upstream of your zone — usually a delegation problem. Verify your domain's NS records and that the zone you're editing is actually authoritative.
FAQ
Why do online checkers sometimes report "no record" when dig finds it?
Caching, mostly. Online checkers query through resolvers that may have cached an old (empty) result. Wait a few minutes or try a different checker.
Can a parent-domain DMARC record block a subdomain check?
No. DMARC checks are domain-specific. A _dmarc.yourdomain.com record doesn't satisfy a check for _dmarc.subdomain.yourdomain.com. The sp= tag tells receivers what to do for subdomains absent their own record, but it doesn't create one.
Does CNAME work for DMARC records?
Technically yes, but it's risky. Some receivers handle CNAME chasing oddly. A direct TXT record is safer.
Why does my DNS provider show the record but it's not in dig?
Two possible reasons: it just hasn't propagated, or it was saved to the wrong zone. Confirm the zone matches the domain you're querying.
What if my DNS provider doesn't allow underscore-prefixed names?
Almost every DNS provider does, but old or proprietary systems sometimes don't. The fix is to move authoritative DNS to a modern provider — Cloudflare, Route 53, or any major operator.
Final thoughts
"No DMARC record found" is annoying but almost always solvable in under 10 minutes. The cure is methodical: query directly, check the wrong-name locations, verify in the provider UI, wait for propagation. Once the record is visible to dig +short TXT _dmarc.yourdomain.com, the rest of DMARC starts working.