Start with one message and one intended assertion
A domain can have several BIMI assertions without every message using all of them. The intended design uses distinct selector names to identify different assertions. A conflict is a different situation: duplicate candidate records at one owner name, conflicting selector headers, or a sending platform that chooses a selector other than the one the operator expects. Diagnose these cases separately before deleting records that may support another legitimate mail stream.
This article uses the BIMI Group's selector guidance and retained DNS and authentication specifications. It does not claim that every receiver implements every draft behavior. No live DNS query or message verification was performed. The required evidence chain starts with a real message, continues through its selector and public DNS answer, and ends with a trusted verification result; a DNS-editor screenshot alone cannot supply that chain.
Distinguish selectors from duplicate records
BIMI Group guidance describes assertion names of the form selector._bimi.domain, with default as the conventional selector when no alternative is selected. It describes a BIMI-Selector header carrying the BIMI version and selector name, combined with the visible From domain to select the assertion. Separate assertions under different selectors are the mechanism for multiple logos; adding several competing assertions at the same name is not the same design. BIMI selector guidance
For an inventory, list each owner name, intended stream, asset and responsible team. Distinguish default._bimi.example.com from seasonal._bimi.example.com and from similarly named records under a sending subdomain. These example names are illustrative, not records that were queried. Do not merge their meanings into a single “domain has BIMI” result, because the message's selected name is the relevant starting point.
Read TXT data as DNS records, not editor lines
A DNS TXT resource record can contain one or more character strings. That wire-level structure means multiple quoted pieces in a display are not necessarily multiple records. Conversely, two separate records can look like one grouped entry in a provider interface. Inspect the actual returned record boundaries before deciding that the domain has duplicate assertions. RFC 1035 TXT format
The safe remediation proposal is one intended, unambiguous BIMI assertion at the selected owner name, with alternate logos assigned to distinct selectors. This article does not assert a universal receiver choice among duplicate assertions or supply a normative duplicate-record algorithm from unavailable draft text. Treat competing candidates as a configuration hold and verify the target receiver's documented behavior before relying on any observed selection order.
Trace the selector through the sending pipeline
Obtain an authorized copy of the received message, preserving headers. Record the visible From domain and all BIMI-Selector occurrences. Compare the received state with the sending platform's configuration and any intermediary that can add or change headers. An application may request a seasonal selector while an outbound service injects a different default preference. Without the actual message, the DNS team can be investigating a name no receiver was asked to use.
BIMI Group recommends including BIMI-Selector in the DMARC-aligned DKIM signature and warns that an unsigned selector header may be ignored. Preserve the relevant signature's signed-header list and verification evidence. Do not assume that a passing signature automatically covered this particular header. A signature can authenticate other parts of a message while leaving the selector preference outside its protection. BIMI signing guidance
If several selector headers appear, identify where they were added and resolve the sending configuration rather than guessing which one a receiver will honor. Preserve the original message before proposing a correction. Do not edit a received header and then present that edited message as evidence of the original verification result. Any later controlled test must be a fresh, authorized observation with its own identity and timestamp.
Establish a trusted verification boundary
Authentication-Results is useful only when the consumer knows which trusted system produced it. An arbitrary header can contain an untrusted assertion. RFC 8601 describes this trust boundary; use receiver-origin evidence or another explicitly trusted verifier rather than accepting a pasted result without provenance. Keep the BIMI decision, DMARC result and DKIM coverage distinguishable in the investigation. RFC 8601 trust boundaries
Record DNS observation time and resolver context alongside the message time. A later DNS lookup can show a repaired state that was not visible when the message was evaluated. Conversely, a current failure does not prove that an older message saw the same answer. Treat the collected evidence as a time-bounded chain, and avoid inventing historical DNS state from today's editor contents.
Original selector-conflict worksheet
Use this worksheet per affected stream. The fields are proposed evidence requests, not completed checks. Preserve sensitive message content only where necessary and authorized; header-focused redaction can often retain the relevant relationships.
- Message identity: receipt time, visible From domain and authorized evidence location.
- Selector state: absent, single or multiple header occurrences, with exact retained values.
- Signature coverage: aligned DKIM identity, signed-header list and trusted validation result.
- DNS target: selected owner name, public response, record boundaries and observation time.
- Assertion ownership: intended stream, asset, certificate dependency and DNS change owner.
- Conflict: duplicate assertions, mismatched selector, unsigned preference or unresolved receiver behavior.
- Proposed correction: exact affected record or sending configuration, approval and rollback plan.
- Closure: fresh controlled message, corresponding DNS observation and trusted receiver outcome.
The worksheet should distinguish facts from hypotheses. “Two records were returned at this name” is a fact only when an actual answer has been retained. “An intermediary may have added another header” is a hypothesis until the message path supports it. Keeping that distinction visible helps avoid broad DNS changes based on a plausible but untested explanation.
Fictional example: two teams share the default name
Fictional Amber Ferry has a corporate mail team and a campaign agency. Both propose publishing a BIMI assertion at the default owner name, while the agency's platform is configured to request a seasonal selector. The invented planning review reveals two independent problems: competing default intentions and a selected name that may not have the intended assertion. Deleting one default record alone would not establish that seasonal mail follows the correct path.
The proposed solution is to agree ownership, keep one intended assertion per selected name, and verify the agency's selector header and signature coverage in a fresh authorized test. Existing streams must be checked before any record is retired. No Amber Ferry DNS records or messages were inspected, and no correction or test was executed; the example shows how to separate conflicts rather than claim a successful repair.
Close only the chain that was observed
A successful observation for one selector does not validate every other selector, subdomain or sending platform. Record exactly which stream and receiver were checked and preserve remaining unknowns. BIMI Group also notes that certificate evidence is tied to a logo, so a second selector pointing to different artwork can introduce a separate evidence-document dependency rather than merely a DNS naming task. Multiple-logo guidance
The catalogue requires a message-to-selector evidence chain with public DNS and trusted verification. None exists for a real deployment in this manuscript. Original evidence, human SME, source applicability, production routes, visual accessibility and owner release remain open. This draft is a diagnostic workflow, not proof that duplicate handling or receiver selection has been tested.