Three Common Misconfigurations in DMARC, BIMI, and SPF Records

I was cross-referencing CipherCue's public DNS observations against three separate email-authentication tags when the same shape kept showing up. A domain does the hard part correctly: it hosts a logo, lists its sending servers, publishes a DMARC record. Then the one small tag that would switch the control on is wrong, missing, or a leftover nobody cleaned up. Three examples, three different tags, same underlying mistake.

Three unrelated standards, but the same failure mode each time. Someone configured a record for a reason. The requirement around it changed. The record never did.

BIMI: a logo that will never show

10.0%

276 of 2,754 BIMI domains we checked had a DMARC policy that does not meet BIMI's enforcement requirement.

One retailer's domain in the dataset publishes a BIMI record with a Verified Mark Certificate:

default._bimi.example-retailer.com. TXT "v=BIMI1;l=https://cdn.example.com/bimi/logo.svg;a=https://cdn.example.com/bimi/mark-certificate.pem"

A VMC is not free or automatic. It is a certificate purchased from an authority, tied to a registered trademark, and it is the specific thing Gmail and Apple Mail check for before they will render a BIMI logo at all. This domain has one. Its DMARC record is:

_dmarc.example-retailer.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example-retailer.com; ruf=mailto:dmarc-auth@example-retailer.com; fo=1;"

p=none. We found the identical pattern on a second, unrelated consumer brand's domain: a hosted SVG, a VMC, and p=none on DMARC.

Why it happens
The BIMI Internet-Draft (version 14, 1 May 2026) is explicit about the requirement: "Domain Owners MUST have a strong [DMARC] policy (quarantine or reject) on both the Organizational Domain, and the RFC5322.From Domain of the message. Quarantine policies MUST NOT have a pct less than pct=100." Gmail and Yahoo's own sender documentation says the same thing in plainer words: p=none never displays a logo, no matter how correct the SVG and certificate are. BIMI gets set up as its own project; DMARC enforcement is a separate, later project that never actually happens.

What it means
Every record here is syntactically valid, which is exactly why it doesn't get flagged. Of the 276 non-compliant domains, 225 sit at p=none, 26 at p=quarantine with pct= below 100, and 25 have no DMARC record at all behind the BIMI record. The pct=100 language in that BIMI requirement is itself citing RFC 7489, the older DMARC spec, not RFC 9989. The BIMI draft has not been updated for the tag's removal; it is still checking a value that the current DMARC standard no longer defines.

Fix: if you have a BIMI record, check the DMARC policy on the same domain. Anything short of p=reject, or p=quarantine with pct=100, means the logo will not display at Gmail, Yahoo, or Apple Mail, whatever the SVG and certificate look like.

DMARC: a tag that survived its own removal

8.1%

5,671 of 70,178 DMARC records carried an explicit pct value while using p=none, where pct has no effect.

A DMARC record from another domain in the dataset reads:

v=DMARC1; p=none; sp=none; rua=mailto:spam-reports@example.org; ruf=mailto:spam-reports@example.org; fo=1; pct=100

pct=100 on a p=none policy does nothing. pct= only ever meant "apply the stricter policy to this percentage of failing mail," and there is no stricter policy to apply a percentage of when the policy is already the weakest one available.

Why it happens
RFC 9989, the current DMARC specification published in 2026, removed the pct tag from the protocol entirely. Its own appendix explains why: "Operational experience showed that the 'pct' tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another." The value at 0 turned out to be genuinely useful, so RFC 9989 kept that behaviour under a new name, a "t" (testing) tag with values of just "y" or "n", and dropped pct as a general-purpose percentage.

What it means
Domains publishing pct=100; p=none are quoting a default value from a tag the specification's own authors just removed for being set wrong too often. Nobody should set out to write pct=100 today; it often came from a template, a tutorial, or an old copy of the record predating the change.

Fix: a pct= tag on a p=none policy is dead weight. Drop it, and if you were trying to express "test this at partial rollout", use the t= tag RFC 9989 replaced it with once you are ready to move past p=none.

SPF: an authentication check that authenticates nothing

2,286

of 90,090 SPF records checked end in ?all, which RFC 7208 requires receivers to treat exactly like having no SPF record.

One financial-services domain's SPF record lists six specific IP ranges, then ends here:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ip4:192.0.2.14 ip4:192.0.2.201 ip4:203.0.113.254 ip4:203.0.113.198 ?all

Someone listed the specific ranges this domain sends from. Then the record closes with a neutral qualifier on the catch-all mechanism.

Why it happens
RFC 7208 section 4.6.2 defines ? as producing a "neutral" result for anything not matched by the earlier mechanisms. Section 8.2 then tells receivers what to do with a neutral result: "MUST be treated exactly like the 'none' result; the distinction exists only for informational purposes."

?all is usually written down while someone is still finding out which IPs send their mail, as a placeholder while they watch what comes in. That's a reasonable place to start. The record has no expiry, so the placeholder outlives the reason it was written.

What it means
Mail from an IP outside those six ranges is authenticated by this record exactly as much as mail from a domain with no SPF record at all: not at all. Compare that to the far more common ~all (softfail, 39,826 records), which still tells a receiver "this probably isn't us, treat it with suspicion" and shows up in a mail server's spam-scoring math. ?all declines to say even that.

Fix: ?all should never be the resting state of a record. Once you know your sending sources, move the qualifier to ~all (softfail) at minimum, or -all once you are confident the list is complete.

Three records, same failure mode

All three can survive a superficial configuration check while failing to deliver the outcome their owner may expect.

The problem isn't bad DNS. It's configuration archaeology.

All three records pass a syntax check. That's the whole problem: nothing about them looks wrong, so nobody goes back to check. The BIMI configuration sits there after the DMARC work it depends on never got finished. pct sits there after the mechanism it belonged to got removed from the spec. ?all sits there after the testing phase it was written for ended.

A lot of these records started life copied from somewhere: a setup guide, a generator, an old example, a ChatGPT answer. That's not a bad way to get a first record onto a domain. It's a bad place to stop. Nobody checks their SPF or DMARC record every month, because nothing about a broken one throws an error, sends an alert, or shows up in a dashboard. Mail keeps flowing either way. The record just quietly stops doing what it was supposed to do, and stays that way until someone thinks to look.

Checking whether SPF, DKIM, DMARC, or BIMI records exist tells you they parse. It doesn't tell you they work. That gap isn't visible from the DNS zone; you only see it by checking the record against what it's actually meant to require, or by watching what real senders and receivers do with your mail.

Methodology and limitations

Method: Public DNS observations already stored by CipherCue for 130,700 tracked domains, latest observation per domain as of the most recent scan window. BIMI eligibility was checked against the DMARC policy and pct value stored for the same domain and observation. The 2,754 BIMI figure and the 90,090 SPF figure are domain counts with the relevant record present, not the full tracked set. The three example records shown are real, confirmed against live DNS at the time of writing; domain names and identifying details (mailbox addresses, exact IP ranges, CDN paths) have been replaced with placeholders, since the point is the misconfiguration pattern, not any specific company.

Limits: BIMI eligibility here is judged only on the DMARC policy tag; we did not verify the SVG file itself, the VMC's validity or expiry, or whether the domain's actual sending traffic aligns with DMARC (the record could be correct and the mail still fail alignment for unrelated reasons). The pct= figure counts any explicit pct value on p=none, not just pct=100; we did not distinguish domains that set pct= to something other than the default. DNS shows what is published, not why a specific value was chosen, whether it was copied from a template, or whether the domain owner is aware of the mismatch.

On pct= specifically: the tag is deprecated. RFC 9989 (2026) removed it from the current DMARC specification, replacing its one useful behaviour with a dedicated t= (testing) tag. A record using pct= is written against an older version of the standard, whether or not it also sits on p=none. The BIMI Internet-Draft's own pct=100 requirement (cited above) references RFC 7489, not RFC 9989, and has not been updated for the tag's removal.