BIMI discovery connects a message's From domain and selector to a DNS assertion. The important question is which record a receiver is entitled to use, not whether any TXT value happens to contain the word BIMI. This article follows draft-brand-indicators-for-message-identification-15, an October 2026 Internet-Draft, rather than presenting it as a published RFC.
Annotate the assertion
References: Source §4.3.
In v=BIMI1; l=https://assets.example/logo.svg; a=https://assets.example/mark.pem, v identifies the protocol version, l points to the indicator and a points to authority evidence. The draft requires the version first and exact case. It allows an empty authority location; an optional tag at protocol level does not remove a receiver's certificate requirement. The example uses two URLs for clarity, while Google's current PEM-based example can use an empty l with the certificate location in a. Follow the applicable receiver path rather than assuming every syntactic variant creates the same display result.
The draft borrows DKIM tag-value syntax. Repeating a tag is not a way to define alternatives. Unknown tags are ignored by the specified extension model; they are not permission to invent new semantics. Keep unknown-tag handling distinct from an invalid required value.
Follow the discovery name
References: Source §5.1, Source §6.4, Source §7.2.
Without an explicit BIMI selector, the default selector is used. An explicit selector is carried in BIMI-Selector; it is not automatically the DKIM s value. For a message from notices.example.com and selector seasonal, the initial name is seasonal._bimi.notices.example.com. Section 7.2 step 6 preserves that selector in its organizational fallback algorithm. However, section 6.4 describes fallback to the default assertion on the Organization domain. These statements conflict within draft -15. This article describes the section 7.2 algorithm, not a universal deployed behavior: verify the intended receiver implementation before relying on either fallback. Publish the intended selected assertion directly where practical rather than designing around this unresolved inconsistency.
Draft -15 also describes local-part selector behavior through lps. That is a version-sensitive feature: document which implementation supports it before designing a campaign around it. The private review package’s parser fixture does not implement local-part normalization, header authentication, organizational-domain calculation or receiver caching.
Inspect the complete answer
References: Source §7.2.
A TXT record may consist of multiple character strings that form one logical value. That differs from two separate eligible assertion records. The draft's discovery procedure stops if the eligible record set is not unique. Query the full set and preserve quoting boundaries in the captured answer. A DNS control panel preview can hide this distinction.
The private review package’s bounded parser cases accept the ordinary example within the supported subset, reject duplicated assertions, detect repeated l tags, reject HTTP locations, reject a wrongly cased version, and accept an otherwise valid record containing an unknown future tag. These are executed decision tests, not observed responses from a mailbox provider. Their narrow parser should not be installed as a production validator.
Make a controlled correction
Correct the specific record name or value, re-query the authoritative server, and then inspect a recursive answer after the relevant cache interval. Retain both answers and the previous record. Re-test the actual receiving provider before declaring display restored. Changing DKIM selectors, DMARC policy or mail routing is not an appropriate blanket fix for a BIMI TXT syntax problem.