“DMARC record published but not valid” — what it means, and why it is worse than having none
A DMARC checker has told you your record is invalid, has a syntax error, or that the policy could not be read. The record is there. You can see it in your DNS console. Every field looks right.
This is the one DMARC result that is genuinely worse than publishing nothing, and the reason is short: a receiving mail server does not repair your record, and it does not warn you. It discards it. From that moment your domain is treated exactly as if you had never published DMARC at all — while your DNS console, your reporting address and your compliance checklist all continue to say you are protected.
domains that publish a DMARC record at all publish one that is void — 6 of the 3081 DMARC records among 7,519 small-business and agency-built domains we measured on 2026-09-05. It is rare, and that is precisely the problem: it is too rare for anyone to be looking for it, and every one of those owners believes the control is on.
Free, no signup: what a stranger can already read about your domain
You cannot settle this one by eye, which is the whole problem. This reads the record your domain publishes right now and tells you the policy value it parsed - not merely that a record is there.
Type a domain and get four checks in about ten seconds: whether anyone can send email in your name (SPF, DKIM and DMARC), how long your HTTPS certificate has left, when your domain registration expires, and whether the site answers over HTTPS rather than plain http. No email address, no account, nothing installed. It runs the same code our paid monthly report runs.
Open the free check on its own page → · We measured 604 domains: 72-83% had at least one finding
What the standard actually says
DMARC is defined by RFC 7489. Section 6.3 defines the p tag and admits exactly
three values — none, quarantine, reject —
and nothing else. Section 6.6.3 then tells receivers what to do with a record that does not
carry one of them:
Records that do not include a
ptag that is valid are ignored, and the receiver applies no DMARC processing to the message.
“Ignored” is the whole story. Not rejected with an error, not downgraded to p=none, not reported back to you. Silently skipped, on every message, at every receiver, for as long as the typo stands.
yourcompany.com publishes a DMARC record with no usable policy setting. The standard allows only p=none, p=quarantine or p=reject, and a record without one of those is discarded — receiving servers act as though you had published no DMARC record at all. The record still looks present in a DNS console, and any reporting address in it keeps working, which is why this is normally found only by a tool.
The sentence above is the wording our own free checker returns for this finding, reproduced here from the running code rather than retyped.
Why nothing tells you
Four things conspire to keep this invisible, and it is worth naming them because each one is a place you would reasonably have expected a warning:
- DNS accepts it. A TXT record is a string. Your DNS provider is not
a DMARC validator and will publish
p=quarentineas cheerfully asp=quarantine. - Presence checks pass. Any tool that asks “is there a DMARC
record at
_dmarc.yourdomain.com?” gets a yes. A great many dashboards ask only that. - Your reports may keep arriving. The
ruaaddress is a different tag. Some receivers still honour it, so a monthly aggregate report can land in your inbox from a record no receiver is enforcing — the single most convincing false reassurance in this whole area. - Nobody complains. The failure mode of a discarded DMARC record is that forged mail gets delivered. There is no bounce, no error, no ticket.
Compare that with having no DMARC at all, where at least the checker says so and nobody is under any illusion. Here the belief and the reality point in opposite directions, and the belief is the one written down.
The shapes we actually found
These are the void records in our own measurement, quoted as published. None of them is exotic; every one is a plausible thing for a competent person to type once:
(no p= tag)— 3 domainsp=quarentinep=rejectedp=policy
Three patterns cause almost all of it. A misspelling of one of the
three legal words — quarentine is the common one, and it is one
transposed letter from correct. A template placeholder left in place, where
p=policy is what a copied example said and nobody substituted the real value.
And a missing p tag entirely: a record carrying only
v=DMARC1, or one that sets the subdomain policy sp= and never sets
the domain policy it inherits from.
That last one deserves a warning of its own, because it is the most reasonable
mistake on the list. sp= without p= reads like it should mean
“this policy for subdomains, defaults elsewhere”. It does not. Without a valid
p the entire record is void, and the sp you carefully set governs
nothing.
How to check yours in thirty seconds
Read the record and compare the p= value against the three legal words
by eye. Do not trust a tool that only reports presence:
nslookup -type=TXT _dmarc.yourcompany.com
dig +short TXT _dmarc.yourcompany.comYou are looking for a single string beginning v=DMARC1 that contains
p=none, p=quarantine or p=reject — spelled
exactly, in lower case by convention, with nothing appended. p=rejected is not
p=reject. Three further things void a record just as completely:
- Two DMARC records on the same name. Receivers are told to apply none of them. This happens when a new record is added beside an old one instead of replacing it.
v=DMARC1not first. The version tag must be the first tag in the record.- A record at the wrong name. It belongs at
_dmarc.yourcompany.com, not at the root of the domain. Some DNS panels append the domain automatically and some do not, which is how_dmarc.yourcompany.com.yourcompany.comgets created.
The fix, and the one decision inside it
Correcting the spelling takes a minute. The decision is what to correct it to, and it is not automatically the value you meant to type. A void record has never been enforced, so your domain has been running with no DMARC in effect for however long the typo has stood — and you have no idea which of your own systems would fail enforcement, because you have never had a working report.
Publishing the p=reject you originally intended is therefore a change
from nothing straight to strictest, on a mail estate you have no data
about. That is the standard way a business breaks its own invoicing:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomainPublish that first. It changes nothing about delivery and starts the aggregate
reports flowing from a record receivers will actually read. Once a full billing cycle has
passed and every sender you recognise — your mail provider, your invoicing tool, your
booking system, your newsletter — is authenticating cleanly, move to
p=quarantine, then to p=reject. If the typo you are fixing is
itself in a p=reject record, this is not a step backwards: you are not weakening
enforcement, because there has not been any.
After you save the change, read the record back. That is the entire lesson of this page: the only proof a DMARC record works is a tool that parses the policy value, not one that confirms a record exists.
Fix it yourself. Then find out when it breaks again.
Everything on this page is the whole fix, free, with nothing held back. What a DNS change cannot do is tell you when somebody edits it back, when a certificate runs out, or when a registration lapses — all three carry dates and none of them announce themselves. A3E’s perimeter monitor re-runs all four checks every month and emails you only when something moves: CA$99/month per site, cancel any time. A single report with no monitoring is CA$29.
Check a domain free See the monitorQuestions
What does an invalid DMARC record actually do?
Nothing. RFC 7489 section 6.6.3 tells receiving mail servers to ignore a record that carries no valid p tag, so they apply no DMARC processing at all. The domain is treated exactly as if no DMARC record had ever been published.
Is an invalid DMARC record worse than no DMARC record?
In effect they are identical — both leave the domain unprotected. In practice the invalid one is worse, because a missing record is reported by every checker and an invalid one still looks present in a DNS console, may still deliver aggregate reports to the address in its rua tag, and so is believed to be working.
Which values are allowed in the DMARC p tag?
Exactly three: none, quarantine and reject. Anything else voids the record. A value that merely begins with a legal word does not count — p=rejected is not p=reject, and some checkers wrongly match the prefix and report the domain as enforcing.
Can I have sp= without p= in a DMARC record?
No. The sp tag sets the policy for subdomains only and cannot stand alone. Without a valid p tag the whole record is discarded, and the subdomain policy you set governs nothing.
I fixed the typo — should I go straight back to p=reject?
No. A void record has never been enforced, so you have no reports telling you which of your own systems would fail. Publish p=none first, read the aggregate reports for a full billing cycle until every legitimate sender authenticates, then move to quarantine and reject.
Why did my DMARC checker say the record was fine?
Many tools test only whether a record exists at _dmarc.yourdomain.com and never parse the policy value. A presence check passes on every void record on this page. Use a checker that reports the p value it read.
The other five in this set
No DMARC record found: what it means and the record to publish
DMARC p=none: what it does, and how to move off it safely
No SPF record found: the record to publish, and why SPF alone is not enough
Gmail 550-5.7.26: what it means and the records that fix it
SPF permerror — too many DNS lookups, and how to get back under ten
The measurement behind every number on this page: 604 domains, method and limitations
Every figure on this page is generated from the stored raw measurement files behind our 604-domain study (522 agency-built sites measured 2026-08-20, 83 independent domains measured 2026-08-01), and the quoted finding wording is read out of the running checker at build time. An automated control re-asserts both against this live page on every operating cycle; if either changed and this page did not, it fails. Generated 2026-09-05T23:34:13Z.
← Back to all articles