Treat avatar preference as a versioned proposal dependency
A request to make the company logo appear instead of a personal avatar sounds like a small branding change. In BIMI, it can involve draft syntax, receiver implementation, account-level images and client presentation rules. The first task is therefore to establish what the proposed tag means in a dated source, which receivers support it, and what evidence would show that it had the intended effect. A DNS edit alone cannot answer those questions.
This article retains the BIMI Group's avatar-preference explanation published on 11 September 2025 and retrieved on 8 November 2026. It is a scoped interpretation of that article, not proof of current universal support. Full current draft text was unavailable for verification in this review. BIMI remains draft work rather than an established IETF Standards Track RFC, so the release decision must keep current specification applicability and receiver behavior explicitly open.
Preserve the exact spelling and source version
The group article uses avp, expanded as Avatar Preference, and says it was introduced in version 09 of the BIMI work. It describes avp=personal as preferring a personal avatar when one exists, with the BIMI logo as fallback, and avp=brand as preferring the domain's brand logo. Preserve that exact spelling. Do not silently substitute apv, invent another value or assume that a similar-looking tag in an older example has the same meaning. BIMI Group avatar-preference article
The historical introduction statement does not establish the latest draft revision or the tag's complete current normative behavior. A source-status record should distinguish the published article date, retrieval date, draft version mentioned and current version still requiring review. If later verified text changes a value or interpretation, retain the old source as historical context and update the recommendation rather than blending incompatible versions into one instruction.
Separate preference from a display guarantee
The group explains a sender's display preference. That is not enough evidence to promise that a named receiver will always replace a personal image. Receiver support, the actual client surface and other eligibility requirements still matter. Avoid repeating the article's promotional language as an unconditional implementation guarantee. A responsible recommendation states what the source describes and what remains unverified for the target audience.
Google's retained setup page documents its certificate-backed BIMI workflow and VMC-linked checkmark, but that page does not establish implementation of the avatar-preference tag. Yahoo's BIMI page describes its logo surfaces and eligibility conditions without supplying evidence here of avp behavior. Do not convert ordinary BIMI support into a claim that either provider implements every newer tag. Google BIMI setup Yahoo BIMI
Inventory the competing image sources
Before planning a test, identify what image the observer is actually seeing. A personal contact photo, account profile avatar and BIMI brand indicator can look similar in a small interface. Ask the test owner to record the relevant account and contact-image state without collecting unnecessary personal information. A screenshot that contains a logo does not by itself prove which mechanism supplied it.
The proposed comparison should preserve client, account, message, time and image-source assumptions. If a personal avatar is absent, a test of personal preference may produce the brand image under the group-described fallback and tell little about precedence when both images exist. If a contact image was changed during the experiment, the resulting difference cannot be attributed solely to the DNS tag. Treat these as experimental design concerns rather than assumptions about undocumented receiver internals.
Keep authentication and certificate gates independent
An avatar-preference tag does not replace the underlying BIMI eligibility work. The actual sending stream still needs appropriate authentication, a suitable asset and any certificate material required by the receiver. Google's documented Gmail workflow accepts VMC or CMC and does not support a standalone SVG-only path. Yahoo lists a valid SVG reference, enforcement policy, bulk traffic, reputation and engagement conditions. These differences must remain visible in the target-receiver plan. Google prerequisites Yahoo conditions
Do not diagnose an absent preferred image as a tag failure before checking those prerequisites. A receiver might not display any BIMI image for reasons unrelated to avatar preference. Conversely, a displayed brand image under the default configuration does not prove that avp=brand was recognized. Record the strongest conclusion the observation supports and leave the rest unknown.
Original status and display worksheet
Use this proposed worksheet before recommending a production tag. It is not a completed compatibility matrix and contains no executed receiver test.
- Proposal identity: exact tag spelling, values, source title, publication date and referenced draft version.
- Current applicability: verified latest text or explicit gap, with a responsible reviewer.
- Receiver support: named provider, client surface and primary implementation evidence.
- Baseline: current assertion, personal-avatar presence, contact-image context and expected default.
- Eligibility: message authentication, asset, certificate and hosting evidence for the stream.
- Test comparison: planned preference cases, controlled inputs and authorization.
- Observation: retained message, display context, image identity and timestamp.
- Decision: recommend, defer or investigate, with limitations and a review trigger.
Keep syntax review and display observation in separate columns. A parser or checker may recognize a tag without establishing that the recipient interface uses it. Similarly, a receiver may display the expected image for a reason unrelated to the preference. The decision should depend on the complete evidence chain rather than a green DNS-check result.
Fictional example: a staff avatar and a company mark
Fictional Harbor Loom wants its support team's brand mark to replace staff profile photos. The planning team finds the avp article and assumes a single record change will force that result everywhere. The review instead identifies three open questions: current tag applicability, named receiver support and the source of the existing photos. It also asks whether the support stream already meets each receiver's BIMI prerequisites.
The proposed test would use authorized accounts with documented avatar states and compare the intended cases on specific clients. It would not promise a universal override or remove personal images as a shortcut. Harbor Loom is invented: no DNS record, avatar setting or message was changed, and no receiver display was observed. The scenario illustrates why a preference claim needs more than syntax.
Maintain a recommendation that can expire
Assign a review trigger when the working-group text, receiver documentation or client behavior changes. Preserve both the date of the recommendation and the evidence on which it depended. If support cannot be established, the useful result is a bounded deferral with the unresolved questions, not a guessed tag deployment. Avoid treating absence of documentation as proof that a feature is unsupported everywhere.
The catalogue requires a receiver-display test matrix and, if claimed, controlled outcome measurement with limitations. This manuscript supplies a proposed matrix only and makes no performance claim. Original evidence, human SME, source applicability, production routes, visual accessibility and owner release remain open. It must not be used as an implementation certificate or an assurance of universal avatar precedence.