Separate the protocol from receiver eligibility
BIMI eligibility is not established by finding the word DMARC in a DNS record. The operator must determine the applicable authentication policy, whether the actual message passes the required checks, and what the intended receiver currently requires before displaying a logo. Those are related but distinct questions. A current protocol specification and a provider's operational help page can also differ in terminology or migration timing, so the evidence needs dates and explicit scope.
This article compares retained primary sources. Google's setup page was updated on 26 October; Yahoo's BIMI page was retrieved without an equivalent visible revision date. RFC 9989 supplies current DMARC protocol context. The article does not test a tenant or infer that a provider has implemented every aspect of the newer RFC. BIMI remains draft work, and receiver display is not a universal protocol guarantee.
Record Google's actual published conditions
Google's BIMI setup page says messages must be authenticated by DMARC and lists p=quarantine or p=reject, with pct=100. It also requires a VMC or CMC for its documented certificate-backed workflow and does not support standalone SVG-only deployment in Gmail. Record those statements as Google's published eligibility guidance, not as a complete definition of DMARC or proof of a particular message result. Google setup requirements
Its SVG requirements and hosting instructions form additional gates. A suitable DMARC policy does not make an invalid image suitable, obtain a certificate, or make the PEM publicly accessible. Conversely, a valid certificate does not repair a failing sender's aligned authentication. Use a checklist with separate rows so a team cannot accidentally mark the whole project ready after completing only the DNS-policy row.
Surface the pct discrepancy rather than hiding it
RFC 9989 obsoletes the earlier DMARC specifications and removes the pct tag. Its appendix explains the historical percentage mechanism and introduces the testing tag t with y and n values. This is a meaningful protocol change, while the retained Google BIMI page still explicitly mentions pct=100. Both observations should be preserved instead of silently rewriting either source to make them appear identical. RFC 9989, Appendix A.6
The operational response is to confirm current receiver applicability before changing a production policy on the basis of that mismatch. Do not claim that Google ignores, requires on the wire, or internally translates a particular tag unless current evidence establishes that behavior. Do not treat t as a universally proven BIMI eligibility substitute for pct merely because the RFC explains their historical relationship. Provider implementation and provider documentation can evolve on different schedules.
A source-applicability record should therefore include the RFC version, provider page date, exact disputed condition and the unresolved question. Ask the responsible reviewer to resolve it with current provider evidence or an authorized, appropriately scoped observation. This article does not perform that confirmation. The conflict is a reason for a gate, not a reason to weaken enforcement or improvise a compatibility claim.
Compare Yahoo's stated conditions independently
Yahoo's own BIMI page requires a quarantine or reject DMARC policy, a BIMI record pointing to a valid SVG, bulk mail, and sufficient reputation and engagement for the sending address. It says VMCs are not currently required, though a supplied VMC informs overall eligibility. Its page honors subdomain BIMI records while preferring organizational-domain setup. These are Yahoo-specific statements, not evidence that Gmail shares the same certificate or display policy. Yahoo BIMI requirements
Do not interpret Yahoo's absence of a pct condition on that page as proof of every possible tag-handling behavior. Record what the source actually states and what it leaves unspecified. Likewise, its bulk-mail and reputation conditions mean that a single personal test message may not represent the documented logo-display population. Do not invent a numeric sending threshold when the reviewed source does not supply one.
Connect policy to actual message authentication
DMARC evaluates alignment between the visible From domain and a passing SPF or DKIM identity under its rules. A published enforcement preference does not force every legitimate sender to pass. Inventory the sending services and identify which identities they authenticate before proposing stricter treatment. Changes to policy can affect legitimate workflows, so a logo deadline must not bypass the mail team's readiness and approval process. RFC 9989 authentication and alignment
For a later controlled observation, retain the actual received message and trusted authentication results. Do not accept a claimed pass from an arbitrary header without identifying the producing system and trust boundary. Keep policy discovery, message authentication and logo display as separate outcomes; a message can pass authentication without meeting a receiver's additional display conditions. RFC 8601 trust boundary
Original receiver-eligibility worksheet
Create one row per receiver and mail stream. The following proposed fields prevent a generic “BIMI ready” status from concealing important differences. No real deployment has been evaluated with this worksheet.
- Source: receiver page, retrieval date, visible revision date and protocol reference version.
- Domain policy: exact applicable record and any organizational or subdomain question.
- Documentation mismatch: disputed tag or condition, evidence and unresolved applicability owner.
- Message evidence: visible From, authenticated identities, alignment and trusted results source.
- Asset: approved SVG version, receiver dimensions and structural findings.
- Certificate: required category, issuer status and hosted PEM dependency.
- Retrieval and display: public endpoint evidence, receiver client, observation time and limits.
- Decision: eligible, not eligible or unknown for this stream, with remaining conditions.
Keep monitoring and enforcement decisions separate from display experimentation. If an existing sender fails alignment, resolve the sender configuration and business impact rather than changing a logo file repeatedly. If authentication passes but no logo appears, investigate certificate, hosting, support and discretionary eligibility without declaring DMARC broken solely from the missing graphic.
Fictional example: one checklist hides two receivers
Fictional Silver Orchard prepares a launch checklist that says “DMARC pass, certificate optional.” That wording merges Yahoo's certificate position with Gmail's different documented workflow. A reviewer also notices that an older internal guide treats pct as an unchanged universal protocol requirement, while RFC 9989 removed it and Google's current page still lists pct=100. The team has two documentation questions, not evidence that either receiver is malfunctioning.
The proposed next step is to split the checklist into source-dated receiver rows and escalate the tag-applicability question before changing production DNS. Each stream would need actual message evidence and its own asset and certificate checks. No Silver Orchard message, DNS record or receiver was tested. The example illustrates how a generic checklist can conceal unresolved assumptions.
The catalogue requires a receiver-specific eligibility matrix and evidence for DNS, logo, certificate and message authentication. This manuscript supplies a proposed matrix and documented differences, not the operational evidence. Original evidence, human SME, source applicability, production routes, visual accessibility and owner release all remain open. No policy change, live test or eligibility guarantee is implied.