Treat BIMI readiness as several evidence layers
A BIMI checker should distinguish DNS publication, logo structure, HTTPS retrieval, certificate evidence and receiver eligibility. A valid-looking record does not prove that the logo is acceptable, and a successfully fetched image does not guarantee that a mailbox provider will display it. The output should identify which layer was observed, which rule was applied and what remains unverified rather than compressing all of BIMI into a single pass.
The retained BIMI Group implementation guidance and Google setup documentation provide practical source material with different scopes. The group guidance is not a claim that BIMI is an Internet Standard, and Google requirements apply to Google's documented receiver behavior. This manuscript proposes checker requirements, not implemented EmailAuth output or a completed scan.
Preserve the DNS identity and selector
Record the exact selector and policy owner name under review, the queried record type, resolver or authoritative source and observation time. A default-selector result should not silently stand in for another selector. The checker should identify multiple candidate records and malformed input according to its supported BIMI specification or documented guidance, with that source version visible. It should not infer which logo a real message selected without the relevant message evidence.
RFC 1035 provides the TXT record structure needed to preserve record boundaries. Multiple strings within one TXT record differ from several TXT records at the same owner. The output should retain those boundaries before interpreting policy fields. No user-domain query was performed here, so there is no actual published BIMI record or selector result in this draft.
Evaluate the logo as an asset, not a screenshot
BIMI Group SVG guidance describes SVG Portable/Secure requirements and explains that the profile is stricter than SVG Tiny 1.2. A logo that looks correct in a browser can still contain unsupported structure, references or interactive content. A checker should identify the actual fetched asset and its content hash, then report profile findings against a named rule set.
Keep visual review separate from structural validation. A structurally acceptable asset can still be difficult to recognize at small sizes or have poor accessibility characteristics. A visually attractive image may fail the profile. The checker should not call one form of review proof of the other. This manuscript did not obtain a candidate asset, run a validator or render a logo; its worksheet specifies the evidence an authorized review would need.
Separate HTTPS transport from mark evidence
Google's documentation requires HTTPS hosting for BIMI files and describes its supported certificate-file requirements. The TLS certificate protecting the hosting connection is different from a VMC or CMC associated with the logo. A checker should label these separately. A valid HTTPS connection proves neither eligibility for a mark certificate nor the validity of the evidence document hosted at that endpoint.
For retrieval, record the requested URL, final endpoint where applicable, response status, content type, bytes or hash, connection time and certificate-validation result. If redirection occurs, retain the observed chain and assess it against the actual source requirements rather than inventing a universal redirect rule. A redirect-free endpoint can be an operational recommendation without being mislabeled as a universal normative requirement.
Scope certificate and receiver requirements
Google's retained setup guidance states that Gmail requires a VMC or CMC from supported issuers and distinguishes the VMC-related verified checkmark. That is not a promise that every receiver requires the same certificate or displays the same indicator. The checker should identify the intended receiver and current documented eligibility rules before interpreting missing certificate evidence as a universal BIMI failure.
Issuer eligibility is another boundary. DigiCert's CMC documentation describes its certificate validation and eligibility requirements. A checker may point to that process, but it cannot make a legal trademark determination or certify issuer approval from a DNS record. No certificate application, logo ownership claim or issuer transaction occurred here.
Keep DMARC readiness distinct
Google's documented BIMI eligibility includes DMARC-related conditions. The checker should cite the current receiver-specific requirement rather than silently substitute its own policy preference. At the protocol level, RFC 9989 defines current DMARC behavior, including changes from older conventions. If provider guidance and the current protocol vocabulary differ, state the applicability question rather than pretending all implementations have changed together.
A published enforcement policy does not prove that each legitimate sender is aligned or that a particular received message meets the receiver's other criteria. Keep sender readiness and receiver observation in separate evidence fields. Reputation, message context and receiver discretion can affect display, so a checker should avoid a guaranteed-logo-display conclusion from configuration evidence alone.
A layered checker worksheet
Create rows for DNS owner and selector, TXT structure, logo URL, retrieved asset, SVG profile findings, HTTPS connection, mark-evidence document and intended receiver. Each row should include source rule, observation time, evidence reference, status and limitation. Use statuses such as observed, failed, not tested and not applicable rather than forcing missing evidence into pass or fail.
For a certificate-validation failure, retain the exact endpoint, hostname checked, connection time, error stage and safe certificate evidence needed to reproduce the diagnosis. Distinguish an expired certificate, hostname mismatch, trust failure and unreachable service only when actual evidence supports the category. The catalogue specifically requires timestamped TLS connection evidence identifying the endpoint and failure; no such connection was attempted in this work.
Fictional diagnosis: the logo loads but eligibility is unresolved
A fictional team sees its logo open in a browser and assumes a checker should declare BIMI complete. The proposed review notes that browser rendering does not validate the required SVG profile, establish the mark-evidence status or demonstrate receiver eligibility. The HTTPS endpoint may work while one of those other layers remains unverified.
The team would collect an authorized asset hash, validator findings, connection evidence and the intended receiver's current requirements. It would not buy a certificate, upload a logo or change DNS merely to satisfy a checker label. This scenario is fictional, with no real logo, endpoint or receiver outcome observed. It illustrates why each layer needs its own result and explanation.
Report readiness without promising display
A useful checker conclusion describes which configuration and asset requirements were demonstrated and which receiver-specific conditions remain open. It should not convert a successful fetch into a promise that a logo will appear for every recipient. The value is a clear next action backed by evidence, not an overconfident readiness badge.
The required original TLS failure evidence remains open, along with human specialist review, source applicability, production routes, accessibility and owner release. This draft uses retained documentary captures with their recorded dates and contains no live scans, uploads or publication. A publishable tool example needs actual authorized evidence and a result bounded to its tested endpoint and receiver scope.