BIMI is published but DMARC is not enforcing
What this check looks for
You have a BIMI record, but your DMARC policy is not strict enough for it to be used. No mailbox provider will show your logo until DMARC is at quarantine or reject and is actually being applied.
Why it matters
The BIMI record is doing nothing. The work that pays off here is finishing the DMARC ramp, not editing the BIMI record.
When the check passes, your report says: “DMARC is enforcing, as BIMI requires”.
What it costs your score
When this check fails it removes 6 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.
It shares the email-auth.bimi family ceiling of 10 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 6 points
- Family cap
- email-auth.bimi · 10
- Category
- Email authentication
- Module
- Email bimi
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Finish the DMARC ramp to quarantine or reject; the BIMI record then starts working as it is.
BIMI is only honoured for domains at an enforcing DMARC policy.
Read your DMARC aggregate reports and fix any legitimate sender failing alignment.
Move
_dmarc.‹domain›top=quarantine— with nopcttag, which RFC 9989 removed, and not=y, which asks receivers not to apply it — and then top=reject.Leave the BIMI record as it is; it takes effect once DMARC enforces.
How to confirm it worked
dig +short TXT _dmarc.‹domain› — expect p=quarantine or p=reject, with no pct tag, no t=y and no sp=none
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
default._bimi.‹domain› exists, but _dmarc.‹domain› publishes p=‹dmarc policy›. The BIMI specification requires the domain to be at p=quarantine or p=reject, applied to all mail and without sp=none; anything weaker means the record is ignored. A surviving pct tag below 100 counts as weaker even though RFC 9989 removed the tag, because BIMI validators still read it. A t=y tag counts as weaker too: the BIMI draft predates the tag, but RFC 9989 Appendix A.6 introduced t=y as the replacement for pct=0, which the draft excludes by requiring an effective percentage of 100 — so we read a record that asks receivers not to apply its policy as failing the prerequisite, and a validator that disagrees is the exception rather than the rule.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.