What does "no DMARC record found" mean?

That a DNS lookup for _dmarc.yourdomain.com returned no usable TXT record. Usually there genuinely is no record. The two other possibilities are a record published at the wrong hostname, which is invisible to every checker even though the text is perfect, and a record that exists but is malformed enough that parsers reject it.

How do I fix no DMARC record found?

Publish a TXT record at the host _dmarc with the value v=DMARC1; p=none; rua=mailto:you@yourdomain.com. It takes a few minutes, changes nothing about how your mail is delivered, and starts aggregate reports arriving so you can see who sends as your domain.

Why does my DMARC record exist but checkers say it is missing?

Almost always the hostname. Most DNS panels append the zone name to whatever you type, so entering _dmarc.yourdomain.com creates a record at _dmarc.yourdomain.com.yourdomain.com. The record is real and correctly written, and nothing will ever find it. Enter just _dmarc in those panels.

Does a subdomain need its own DMARC record?

No. Receivers that find no record at a subdomain look up the organisational domain and apply its policy, so a subdomain reporting no record of its own is normal and not a fault. Publish one at a subdomain only when you want different treatment there; otherwise control subdomains from the parent with sp= and np=.

How long does a new DMARC record take to work?

Usually minutes, though resolvers that already cached the absence of a record wait out the zone's negative caching TTL before asking again, which is commonly an hour. Aggregate reports are a slower signal: providers batch them daily, so expect the first XML files roughly twenty-four hours after publishing.

No DMARC record found

A checker looked up _dmarc.yourdomain.com, found no usable TXT record, and told you so. Most of the time that is the whole story and the fix takes five minutes. But two other situations produce exactly the same message while a record sits in your DNS looking perfectly correct, and people who hit those spend an afternoon re-reading text that was never the problem.

Confirm which one you are in before editing anything: the free DMARC record checker queries the name receivers query and shows you what came back.

Cause 1: there genuinely isn't one

The common case. No record exists, so anyone can send mail carrying your domain in the From address and no provider has been told to treat that as suspicious.

Publish a TXT record:

Field	Value
Type	`TXT`
Host / Name	`_dmarc`
Value	`v=DMARC1; p=none; rua=mailto:you@yourdomain.com`
TTL	Default, or 3600

p=none changes nothing about how your mail is delivered. It asks receivers to report rather than act, which is how you find out who sends as your domain before any of that mail is at risk. Scanners will now grade you as "DMARC policy not enabled" — that is the expected next state, not a new problem, and it is the one you want to be in while you read reports.

The full tag reference, including ruf=, adkim= and the rest, is on the DMARC record page.

Cause 2: it's published at the wrong host

This is the one worth reading even if you are sure it does not apply to you, because the record looks right in your DNS panel and is invisible to the entire internet.

Nearly every DNS provider appends the zone name to whatever you type in the host field. Type _dmarc and you get _dmarc.yourdomain.com, which is correct. Type the full name because it seems safer and you get this:

_dmarc.yourdomain.com.yourdomain.com     ← created
_dmarc.yourdomain.com                    ← what receivers query

The record is real, the syntax is flawless, and nothing will ever find it. Most registrar panels behave this way, while a handful expect the fully qualified name instead and produce the mirror-image mistake when you type the short one. The interface rarely tells you which kind it is, so read the saved record back in the list afterwards rather than trusting what you typed — the host field is covered in more detail on the DMARC record page.

Two neighbouring versions of the same error:

The record is at the apex. A TXT record on yourdomain.com itself holding v=DMARC1 is not a DMARC record — DMARC is only ever read from the _dmarc subdomain. It will sit there alongside your SPF record doing nothing.
The underscore was dropped. Some panels strip or reject a leading underscore. dmarc.yourdomain.com is a different name and is not consulted.

Cause 3: it exists but won't parse

A record is there, at the right name, and parsers reject it — so tools report it as missing rather than as broken. The causes are all small:

v=DMARC1 is not first. The version tag must be the first tag in the record. p=reject; v=DMARC1 is invalid, not merely unconventional.
Smart quotes. A value drafted in a word processor or a chat window arrives with curly quotation marks or an en dash in place of a hyphen. Retype it in a plain text field.
Two records. Publishing a second DMARC TXT record at _dmarc is not additive — receivers that find more than one apply neither, exactly as with SPF. Merge them into one.
A CNAME at _dmarc that no longer resolves. Hosted DMARC services publish a CNAME here, and when a subscription lapses or a vendor changes hostnames, the target disappears and the lookup returns nothing.
The TXT record is split oddly. A long value split into multiple strings is legal and gets concatenated, but some panels insert a space or a stray quote at the join, which corrupts the tag it lands in.

If the checker reports a record it cannot read, the text of the record is where to look. If it reports nothing at all, you are in cause 1 or cause 2.

A subdomain reporting no record is usually fine

Checking mail.yourdomain.com or news.yourdomain.com and seeing "no DMARC record found" is expected behaviour, not a gap. When a receiver finds no record at the exact name, it looks up the organisational domain and applies the policy it finds there. Your subdomains are already covered by the record at _dmarc.yourdomain.com.

Publish a record at a subdomain only when you want it treated differently — a bulk sending subdomain you are still fixing, for instance, while the parent is already enforcing. Otherwise control them from the parent with sp= for subdomains that exist and np= for ones that do not, both covered in the policy guide.

Checking that it worked

Re-run the DMARC checker. A new record usually resolves within minutes, but if you checked the domain before publishing, resolvers may have cached the absence — negative caching is commonly an hour — so a stale "not found" shortly after adding a record is normal rather than alarming.

The slower confirmation is reports arriving. Providers batch aggregate reports daily, so the first XML files land roughly a day after publishing, addressed to whatever you put in rua=. When they do, they are not meant to be read by hand: what is in a DMARC report covers what the XML contains, and the free report analyzer will turn a single file into something legible.

One thing to watch after this is fixed: records do not stay fixed. A migration rewrites a zone, a vendor's CNAME target changes, someone tidies DNS and removes an underscore name they did not recognise — and the error comes back on a domain nobody meant to touch. That is DNS drift.

Free checks: DMARC checker SPF checker DKIM checker Report analyzer