auth.dmarc.invalid_tag_value

Invalid DMARC Tag Value

What we check

We check every tag value in the DMARC record against the grammar RFC 7489 §6.3 defines: p= and sp= must be none, quarantine or reject; adkim= and aspf= must be r or s; fo= is a colon-separated list of 0, 1, d, s; pct= is a whole number from 0 to 100; ri= is a non-negative number. This finding names the tag whose value does not fit.

What this finding means

The record is not the record you think you published. A common example is fo=0,1,s — commas instead of colons — which no receiver can interpret as a failure-reporting option. Receivers differ in how they react: lenient ones ignore the one tag, strict ones treat the record as malformed and behave as if no DMARC policy existed. Your enforcement is therefore only as reliable as the strictest receiver's parser.

An invalid p= or sp= is graded the way RFC 7489 §6.6.3 tells receivers to treat it (see the "DMARC Policy Not Valid" finding). For any other tag we grade the policy the record declares and attach this warning, so the report shows both what you intended and that the tag is not doing its job.

Why it matters

• An unparseable record can mean no policy at all. For a strict receiver, p=reject next to a malformed tag is worth nothing.
• Reporting options silently fail. A broken fo= means the forensic reports you expect never arrive, and you will not notice the gap.
• It is a one-line fix that removes the ambiguity everywhere at once.

How to fix

1. Correct the value. For failure options, separate the values with colons:

   copy

   _dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=0:1:s"
   

2. Check the other tags against the list above — a typo such as p=rejekt or adkim=strict is the same class of defect.

3. Re-scan. The finding clears once every tag value is within the grammar.