BIMI is an invitation, not a guarantee.

A BIMI record is the domain owner saying, “If this message qualifies, this is the brand mark we want you to consider.” It is not an instruction to paint that mark into every inbox. The receiver discovers the assertion, validates what it supports, applies local policy, and decides whether the current interface should show anything at all.

That distinction is the whole system. Without it, BIMI sounds like a logo-upload feature with unusually elaborate setup. With it, the design makes sense. The domain proves control over authenticated mail. A mark certificate can add evidence about rights in the logo. The provider remains responsible for what its users see.

BIMI standardizes a request for display. It does not standardize an entitlement to display.

The current BIMI specification is an active IETF Internet-Draft, explicitly marked as work in progress. Its practical behavior also depends on current receiver documentation. That is why an honest implementation records the source-review date, avoids promising universal support, and keeps provider policy separate from protocol validity.

“BIMI enabled” compresses several independent outcomes into one badge. A better model keeps five gates visible. Passing an earlier gate does not imply that a later one passed, and every failure points to a different owner and repair.

The gates also stop one success from making an unrelated claim. A BIMI pass is not evidence that the message reached the primary inbox. As Delivery is a receipt, not a result explains, acceptance, placement, attention, and action remain separate observations.

BIMI begins after authentication has already done its job. SPF can authorize a sending path. DKIM can attach a domain-linked signature. DMARC asks whether at least one of those passing identities aligns with the domain a person can see in the From field. BIMI relies on that aligned result; it does not create it.

Current BIMI guidance requires a strong DMARC policy on the organizational domain and the visible From domain. The policy must be quarantine or reject, not none. A quarantine policy cannot use a percentage below 100. Gmail's current setup guidance is stricter about rollout and requires the DMARC policy to apply to 100 percent of outgoing mail whichever enforcement action is used. These prerequisites are intentionally demanding: a brand should not ask receivers to associate a logo with its mail while leaving broad impersonation paths outside enforcement.

Enforcement should still be earned, not rushed. Inventory every legitimate service, configure aligned authentication, read DMARC reports, and resolve unknown traffic before changing policy. A logo is not worth rejecting valid account mail. The deeper guide, SPF, DKIM, and DMARC prove identity, not inbox placement, owns that rollout and the alignment model.

The usual BIMI assertion lives at a name such as default._bimi.example.com. Its value uses a compact tag-and-value format. The stable fields are the version, the HTTPS location of the logo, and, when supplied, the HTTPS location of a supported evidence file.

default._bimi.example.com TXT
"v=BIMI1; l=https://assets.example.com/brand.svg; a=https://assets.example.com/mark.pem"

The v tag identifies the BIMI version. The l tag locates the SVG indicator. The a tag locates evidence such as a mark certificate. Some receivers require that evidence; others may evaluate a self-asserted logo. Provider rules decide which path is meaningful.

DNS correctness is exacting. A record at the wrong label is absent. Multiple competing records can make discovery fail. A valid-looking URL that redirects into a blocked asset is not retrievable. The record should therefore be inspected as a chain, message selector, DNS answer, final HTTPS response, content type, asset, and evidence, not as a string copied from a setup screen.

An ordinary browser-friendly SVG is not automatically a BIMI logo. BIMI uses the constrained SVG Tiny Portable/Secure profile. The restriction excludes behaviors that do not belong in a mark fetched and rendered by receiving systems: scripts, animation, and external resources. The art must remain recognizable inside a square view box and at the tiny size of an inbox avatar.

Host the asset at a stable public HTTPS URL with the correct response type. Do not put authentication, hotlink protection, geo-fences, or brittle redirect chains in front of it. The same public-retrieval principle applies to the PEM evidence file. Your design system may own the logo, but mail systems need to retrieve a deliberately constrained distribution artifact.

This is not merely visual polish. A malformed or unreachable asset breaks the evidence path after authentication has already succeeded. Keeping that result distinct prevents a design-file problem from being misdiagnosed as a DMARC failure.

A mark certificate adds independently issued evidence that an organization has rights in the logo associated with the domain. That is a different claim from message authentication. DMARC connects an authorized message to a visible domain; the certificate connects a qualifying mark and organization to supported evidence.

Google currently accepts supported VMCs and CMCs for Gmail BIMI, but its verified checkmark is specific to VMC-backed senders. Other receivers can use different certificate and display policies. Before buying or renewing evidence, check the current issuer list and each provider you actually need to support. “BIMI compatible” without a named destination is not a complete procurement requirement.

Engineers naturally want a binary outcome: valid or invalid. BIMI has that layer, but the user-visible result sits beyond it. A receiver can validate the assertion and still decide not to render the indicator. It may require a particular evidence type, enough trustworthy sending history, or a supported surface. Its mobile and desktop clients may not place the mark in the same location.

Reputation belongs in this final decision without becoming a mysterious excuse for every setup problem. First prove the message aligns, the policy enforces, and the files validate. Only then investigate receiver eligibility, reputation, and caching. The companion field note Sender reputation is memory, not a score explains why one provider can make a different decision from another using the same domain.

BIMI also does not certify that a message was wanted. A verified brand can still send irrelevant mail. It does not prove consent, protect a poor audience, or guarantee inbox placement. It gives the receiver better evidence about domain and mark control, while every other sending decision remains accountable on its own merits.

Start with a fresh message delivered to the provider you are investigating. Configuration screenshots prove what someone intended to publish. The message headers and current DNS prove what that receiver could evaluate. Work outward in the same order as the five gates.

1. 01

   Inspect authentication on one real message.

   Confirm DMARC passed and identify which aligned SPF or DKIM domain produced the pass. A different From domain can lead to a different BIMI lookup.

2. 02

   Resolve the enforcement policy.

   Check both the organizational domain and the visible From domain. Confirm quarantine or reject and the required coverage rather than trusting a dashboard summary.

3. 03

   Resolve the exact BIMI record.

   Use the applicable selector, look for duplicate answers, and parse each supported field without silently correcting syntax.

4. 04

   Fetch the final assets as a public receiver would.

   Follow redirects, inspect TLS and response types, validate the SVG profile, and verify the complete PEM chain when evidence is present.

5. 05

   Check the destination’s current display rules.

   Confirm provider support, accepted certificate type, interface, reputation conditions, and any cache window before changing valid configuration.

Preserve each observation with its timestamp and source. Provider requirements and the underlying draft can change. A successful result from six months ago is context, not proof of what a receiver evaluated today.

Moosewave treats BIMI as an evidence chain rather than one ceremonial green check. The deliverability workspace reads live SPF, DKIM, DMARC, and BIMI records, names the exact domain under evaluation, and separates authentication from brand-indicator readiness. That makes a failure actionable without implying that a passing record controls the inbox.

The useful report keeps the layers intact: message alignment, policy, selector discovery, asset reachability, certificate evidence, and provider-side observation. When a logo does not appear, the team can see which evidence is missing and which decision belongs to the receiving provider. No one has to rotate DNS values until something changes by accident.

Open the interactive product walkthrough to see how domain configuration and placement evidence stay connected to the same sending identity. BIMI is most useful when the attractive result, the logo, remains attached to the less glamorous work that made it eligible.