Verify the dependencies before editing DNS
Publishing a BIMI assertion is a small DNS change with several external dependencies. The record may refer to a logo or evidence document that another team hosts, and the receiving provider may reject an otherwise readable file because its certificate or authentication conditions are not met. Begin with an approved domain, receiver-specific plan and exact asset versions rather than a generic TXT string.
This guide covers the documented default-selector workflow. The retained BIMI version-15 document describes additional selectors and discovery rules, but it remains an Internet-Draft, not an RFC. Do not introduce advanced selector behavior merely because a sending platform can insert a header; confirm the intended sender and receiver implementation first. BIMI Internet-Draft 15, sections 4.3–4.4.
Establish the correct owner and assertion value
For the simple default case at example.com, the assertion owner is default._bimi.example.com. The version tag is v=BIMI1; the indicator location uses l=, and the authority-evidence location uses a=. The draft defines the evidence location as optional syntax, but that does not make evidence optional for every receiver. BIMI Internet-Draft 15, section 4.3.
A fictional dual-location illustration is v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. This is not a production record, a hosted asset or a certificate recommendation. Replace neither a real assertion nor a real certificate URL with those example values.
Google documents a PEM-based setup for Gmail, including an example with an empty l= value and the certificate location in a=. An SVG-only record is not the same implementation path. Select the form supported by the target receiver and the supplied evidence rather than treating every published example as interchangeable. Google BIMI setup, steps 2–4.
Check the applicable authentication policy
Confirm the Author Domain and the applicable organizational-domain policy using current DMARC discovery rules. Then inspect actual messages from the intended route for aligned authentication. BIMI Group calls for enforcement and notes the limited support of self-asserted records, but neither policy text nor a record-builder result proves that a sender is ready. BIMI implementation guide; RFC 9989, sections 4.4 and 4.10.
Provider documentation must be read with its version context. The current Google page still includes pct=100, whereas RFC 9989 removed that tag. Retain this discrepancy as a compatibility question for the mail administrator. Do not use a percentage setting or testing mode as a claimed shortcut to BIMI eligibility, and do not weaken existing enforcement while debugging an unrelated asset problem. RFC 9989, Appendix A.6.
Verify the resources that the assertion will advertise
The hosting owner should provide the exact public HTTPS URLs, the intended bytes and their hashes. A proposed fetch should confirm that the response is the expected asset or certificate bundle rather than a login page, branded error page or redirect to an unrelated resource. Record the status, final URL, content type, size and TLS result. These observations must come from the actual production path, not only a local file preview.
For a mark-certificate path, verify the issued evidence and chain against the target provider's requirements. Google's instructions describe its PEM bundle and the issuer-supplied chain order. The HTTPS server certificate protects retrieval; it is not the VMC or CMC that supplies mark evidence. Check both relationships independently. Google BIMI setup, web-server requirements and steps 2–3.
No public URL has been fetched on behalf of a real deployment here. If the team cannot provide an approved asset or certificate, leave that dependency unresolved instead of constructing a placeholder that could be mistaken for valid evidence.
Publish through the correct DNS authority
Identify the authoritative DNS service for the exact owner and inspect existing records before making a change. Confirm whether the editor expects a relative host label or a fully qualified name. Preserve the previous value and TTL, and use a reviewed change request that names the intended owner, type and value. Avoid duplicate competing assertions at the same discovery name.
After an authorized publication, the proposed checks include dig @AUTH_IP default._bimi.example.com. TXT +norecurse and dig @RESOLVER_IP default._bimi.example.com. TXT. The uppercase endpoints are placeholders. Save timestamps, complete responses, record boundaries and the actual values. These commands are proposed, not executed observations.
Check authoritative consistency before explaining disagreement as caching. Then compare the recursive paths relevant to the intended receiver where those observations are available. A DNS TTL or a provider's estimated display window is not a guarantee that every receiver has refreshed or will display a logo.
Validate a message and plan recovery
Send a controlled message through the exact approved workflow only after its prerequisites are ready. Retain the Author Domain, signing identities, trusted authentication results and any relevant BIMI diagnostics. Record a display observation separately with the mailbox provider, client version and date. Apple Mail's BIMI path, for example, depends on the receiving provider supplying the checks and headers Apple specifies. Apple BIMI server guidance.
If retrieval fails, repair the hosted dependency or restore the approved prior assertion under the change plan. If authentication fails, investigate the sender and policy. If only display is absent, do not infer a DNS error without checking the receiver row. Maintain the old evidence needed for a safe, authorized rollback; do not broadly reduce DMARC protection to recover a logo.
The exact evidence gate is “A receiver-specific eligibility matrix and evidence for DNS, logo, certificate and message authentication.” This draft provides a documentary matrix and fictional record illustration. No live publication, DNS query, certificate validation, tenant change or message/display test occurred, so the operational gate and owner release approval remain open.