Invalid DMARC record

A missing or misplaced version tag. It must be the first tag in the record, and a record without it is not a DMARC record at all.

A missing policy tag, which is required. A record declaring only a reporting address is incomplete and is discarded.

A malformed reporting destination — a missing scheme prefix on the address is the most common instance.

Tags separated incorrectly, or a stray character introduced when a DNS interface split a long value across strings.

A second record at the same name, which is a permanent error under the specification exactly as it is for SPF.

Receivers discard an unparseable record and continue. There is no bounce, no warning and no notification to the domain owner.

Aggregate reports stop arriving — or never start — which is the only visible symptom and is easy to read as low mail volume.

Every checking tool that only verifies a record exists will report the domain as configured.

So the failure can persist for years, and it does, particularly on domains where DMARC was set up once and never revisited.

DNS TXT values have a per-string length limit, so long records are split into several strings that a resolver concatenates.

Some DNS interfaces do this correctly and some require the author to do it, which is where a space or a quote ends up inside the value.

A record that displays correctly in a provider's interface can therefore be served incorrectly, which is why checking from a resolver rather than from the interface matters.

A DMARC record long enough to hit this usually got there through multiple reporting addresses, which is worth simplifying for that reason alone.

Query the record from a resolver rather than reading it in the DNS provider's interface, so you see what receivers see.

Confirm the version tag is first and the policy tag is present.

Confirm each reporting destination carries its scheme prefix, which is the single most common syntax error in these records.

Confirm exactly one record exists at the policy name, and remove any duplicate after the correct one is verified.

Send a message to a mailbox you control and read the authentication results, which report the DMARC outcome the receiver computed.

Query the TXT record at the DMARC name for your domain, which is a dedicated subdomain rather than the apex.

Count the records returned. More than one is the defect regardless of content.

Read the value as returned, not as displayed in a DNS interface, so quoting problems are visible.

Check whether aggregate reports are arriving at the declared address — their absence over a week on a domain with real mail volume is a strong signal.

Confirm the reporting mailbox accepts mail from external domains, since a reporting address that bounces produces the same silence.

`email.dmarc.syntax` reports whether the record is unique and free of syntax errors, which is this problem directly.

`email.dmarc.present` reports whether a record exists at all, so an invalid record is distinguished from an absent one.

`email.dmarc.policy`, `email.dmarc.subdomain` and `email.dmarc.pct` report the parsed values where the record does parse.

`email.dmarc.rua` reports the aggregate destination, whose absence is what makes an invalid record so hard to notice.

`email.spoofing_exposure` reflects the combined outcome, which for an invalid record is the same as for no record.

The record is published at a dedicated name under the domain, not at the apex — a DMARC record on the apex TXT is simply not found.

That mistake produces the same silence as a syntax error, and it is common enough to check first.

For a subdomain, receivers look at the subdomain's own policy name and fall back to the organisational domain's policy when none exists.

Which is what the subdomain policy tag controls, and why a correct apex record covers subdomains unless something overrides it.

A record published on the wrong name and a record published twice on the right one produce identical symptoms: no reports and no protection.