Why does my checker say no DMARC record when I added one?

The most common causes are: the record was published at the wrong name (dmarc. instead of _dmarc., or with the domain doubled by the DNS panel's auto-append); it was entered as the wrong record type; it exists but is formally invalid — a record whose version tag is not the very first element is ignored entirely, so parsers report nothing; it was published only on a subdomain while checkers test the organisational domain; or DNS propagation has not reached the checker yet. Querying the TXT records at _dmarc.yourdomain against your authoritative nameserver separates all of these in one step.

What happens if I have two DMARC records?

By the specification, receivers discard both. DMARC policy discovery (RFC 7489 section 6.6.3) states that if the remaining set of records contains multiple records, policy discovery terminates and DMARC processing is not applied; the current specification (RFC 9989) restates it as discarding all of them. There is no 'first record wins' or 'stricter record wins' rule — that is folklore. The fix is surgery: keep exactly one deliberate record and delete the other. A frequent hidden second record is a registrar default, such as GoDaddy's post-April-2025 shipped record.

What is the minimum valid DMARC record?

A TXT record at the name _dmarc on your organisational domain whose value begins with v=DMARC1 as the first element, followed by a policy tag p= with a valid value (none, quarantine, or reject). The practical starting record this site teaches is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain — monitoring first, enforcement after your senders are inventoried. An invalid p= value does not merely weaken the record: per the specification it degrades processing to p=none if a valid report address exists, and kills the record otherwise.

DMARC · DNS records · Fix

“DMARC record not found” — six different problems wear that one message

First published 20 October 2026 · Discovery rules quoted from RFC 7489 §6.6.3 and the current specification RFC 9989 — read directly for this guide. Folklore is labelled where it appears.

NOT FOUND …says the checker. Your DNS panel disagrees.

Both can be telling the truth — about different names, different validity rules, or a second record neither of you noticed. One authoritative query settles which world you're in.

Two records = both discarded, by specificationOne query sorts it

The fast answer — the one query

Look up TXT records at _dmarc.yourdomain — and repeat it against your authoritative nameserver (your DNS host's own server), so caches can't lie to you.
Match the answer to the table below. Each row is a different disease with a different cure; “add the record again” cures only one of them and causes another.

The authoritative answer	Your cause
No record at `_dmarc` — but one sits at `dmarc.` or `_dmarc.yourdomain.yourdomain`	1. Wrong name
No TXT — but a CNAME or another type sits at `_dmarc`	2. Wrong type / shadowed name
A TXT whose value doesn't begin with `v=DMARC1`	3. Invalid — ignored entirely
A valid record — but only on a subdomain; the root has none	4. Published at the wrong level
Two valid-looking TXT records	5. The secret second record
Correct at the authority, absent elsewhere	6. Propagation
Nothing, anywhere, and you truly never added it	7. Actually missing — the only row “add it” cures

The causes — fix and verify

1. Wrong name

The record lives exactly where the specification looks: the _dmarc subdomain (RFC 7489 §6.1) — underscore included. dmarc.yourdomain (no underscore) and panel-doubled names are the recurring shapes; Google's own setup guidance warns about the append behaviour explicitly. Fix: publish at the relative name _dmarc. Verify: the authoritative query returns it at the true name.

2. Wrong type / a name shadowed by a CNAME

Discovery asks for TXT specifically. A name carrying a CNAME cannot legally hold other record types alongside it (the DNS rules forbid the coexistence), so a TXT “added” under a CNAME'd name is a ghost — with one honourable exception: a deliberate CNAME delegating _dmarc to a DMARC service provider is legitimate design, and discovery follows it. Fix: remove the accidental CNAME and publish TXT, or confirm the delegation is intentional and its target serves your record.

3. Invalid — present but invisible

The subtlest family, and the specification splits it three ways — quote them to any tool that shrugs at you:

Version tag not first / malformed: only a record beginning with v=DMARC1 counts as a DMARC record at all. Anything else is ignored — checkers honestly report “none found.”
Invalid p= value: the record doesn't vanish; processing degrades to p=none if a valid report address exists, and dies entirely otherwise (9989 makes this fallback mandatory).
A typo in an optional tag: the record survives; the tag is ignored. Not every typo is fatal — position and the p value are what carry the record.

4. Published at the wrong level

Discovery starts at the From domain and walks up to the organisational domain — never down. A record on shop.yourdomain governs that subdomain; it creates no record for yourdomain. Fix: publish at the organisational domain's _dmarc; use subdomain records only as deliberate overrides.

5. The secret second record — surgery

The specification's step 5, verbatim in substance: if discovery ends with multiple records, “policy discovery terminates and DMARC processing is not applied.” The current spec says the set is discarded. There is no first-wins, no stricter-wins. The usual second author is a registrar: GoDaddy ships a default DMARC (quarantine, reports to GoDaddy) on domains arrived since April 2025 — owners who later “add DMARC” create the pair unknowingly. Surgery: decide provenance, not seniority — keep the record that is deliberate (your policy, your report address), edit it to final form, delete the other in the same session, then re-query. Verify: exactly one record remains.

6. Propagation

Real only when the authoritative server already serves the record (the table's test). Beware a borrowed number: the “48 hours” in Google's docs is the SPF/DKIM precondition from its setup flow, not a DMARC propagation promise — your TTL is the honest clock.

7. Actually missing

Then add the starting record, once, at the right name:

TXT · Name: _dmarc · Value

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain

…and climb from monitoring to enforcement with the rollout guide once reports show your senders aligned.

Traps around this fix

Trap	Why it bites
Deleting the registrar default “to start clean” — and stopping there	You removed an enforcing policy and replaced it with nothing. Edit-then-delete (or add-then-delete within one session) leaves no gap; a bare deletion is a gap by choice.
Putting the record at the root as a plain TXT	The root is where SPF lives; DMARC's home is the `_dmarc` name. A root TXT starting `v=DMARC1` is invisible to discovery.
Trusting one checker's disagreement with another	Tools differ on the invalid-record rows (some validate, some only count). The authoritative TXT query outranks every dashboard.

FAQ

Does the RFC 9989 update change any of this?

The practical rules for a root domain are the same; the new specification walks the domain tree label-by-label instead of using the public-suffix shortcut, hardens the invalid-policy fallback, and restates the multiple-record rule as discarding all — outcomes identical for the reader of this page.

My record starts with a space / the tags are reordered. Found or not?

Tag order after the version is flexible, but the version element must be first; stray leading characters break the precise match. When in doubt, retype the value cleanly from the record box above and re-query.

I only want DMARC on my shop subdomain.

Legitimate — publish _dmarc.shop.yourdomain. Just know it protects that subdomain only, and the root still needs its own record for the domain your customers actually see in From.

Sources

RFC 7489 — §6.1 (record location), §6.3 (version-first rule, invalid-tag handling), §6.6.3 (discovery steps 1–6: TXT query, walk-up, exactly-one rule, invalid-p fallback) · RFC 9989 — §4.10 (discarded sets), tree-walk discovery, hardened fallbacks · RFC 1034 §3.6.2 (CNAME coexistence/restart) · Google Workspace Admin Help — DMARC setup (name, append warning) · GoDaddy's April 2025 default-DMARC announcement (via this site's earlier verified research).

Verification note: discovery mechanics and the invalid-record trichotomy were confirmed against the RFC texts on 20 October 2026. Individual checkers' on-screen wording for these states varies and could not be captured uniformly during research, so this guide teaches the authoritative query instead of quoting dashboards.

Did this fix work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.