BIMI Explained: How a Brand Logo Reaches the Inbox

Brand Indicators for Message Identification, usually shortened to BIMI, is a way for a sender to attach a verified logo to its email. When everything lines up, a mailbox provider can show that logo next to the message in the inbox, which helps a reader recognise the sender at a glance. The BIMI Checker looks at a BIMI record that you paste in and reports whether its structure makes sense. It is important to be clear about what this kind of tool does and does not do: it validates the record text you supply, and it does not perform a live domain lookup, fetch your logo, or prove that a mailbox provider will display it. That distinction matters, because a record can be perfectly formed and still fail in the real world if the logo file is unreachable or the certificate chain is incomplete.

How it works

A BIMI record is a DNS TXT record published at a special location under the sending domain, and it contains a version tag, a location pointing at an SVG logo file, and optionally an authority-evidence location pointing at a Verified Mark Certificate. The version tag tells a reader which version of the specification the record follows. The location must be a URL that a mailbox provider can fetch over HTTPS, and the file it points to must be an SVG in the particular profile BIMI requires, which is stricter than an ordinary SVG. The authority-evidence field is where a Verified Mark Certificate lives when the sender has one; some mailbox providers require it, while others accept records without it. Reading a record therefore means checking each piece in turn: is the version present, does the location look like a fetchable HTTPS URL, and is the evidence field present and well formed when one is expected?

Where it goes wrong

The most common record mistakes are small and easy to miss. A missing version tag is the first; without it, a reader cannot be sure how to interpret the rest. A location that uses plain HTTP instead of HTTPS, or that points at a PNG or JPEG instead of an SVG, is another frequent failure, because BIMI logos must be SVG files served securely. Typos in the host name, a trailing space, or a missing closing quote can also break parsing, since DNS TXT records are often split into character strings and reassembled. Another subtle error is publishing the record at the wrong name: the BIMI record belongs under the selector-based subdomain, not at the bare domain, and a record in the wrong place simply will not be found by a reader that looks in the right place.

Worked example

Worked example with sample values. Suppose you paste this sample record into the checker: v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/cert.pem. The checker can confirm four things from the text alone. First, the version tag v=BIMI1 is present and spelled correctly. Second, the location begins with https:// and ends in .svg, which matches the expected shape. Third, the authority-evidence value is also an HTTPS URL, so the field is well formed. Fourth, counting the fields gives three tags in total: version, location and authority. That is a pass on structure, but it is not a pass on the real world: the sample says nothing about whether example.com actually serves that file, whether the SVG meets the BIMI profile, or whether the certificate is genuine. Those checks need separate steps, and the sample domain here is illustrative only, not a live result.

Mistakes to avoid

A related mistake is treating a BIMI pass as a deliverability guarantee. BIMI sits on top of other email authentication: a domain normally needs SPF, DKIM and a DMARC policy in place before mailbox providers will consider its BIMI record at all. If those foundations are missing or misaligned, fixing the BIMI text will not help. It is also worth remembering that not every mailbox provider supports BIMI, so the same message may show a logo in one inbox and not in another, and that is normal rather than a fault in the record. Finally, logo design itself matters: a logo that is unreadable at small sizes, or that relies on fine detail, will look poor even when the technical chain works. Test the artwork at inbox size before publishing.

Putting it into practice

Use the checker as one step in a short routine. Paste the exact record text, including the version tag, and read every finding rather than stopping at the first. Correct the record at its source, in your DNS management, rather than patching a copy of the text. Then check the logo file separately for the BIMI SVG profile, and confirm that your SPF, DKIM and DMARC records are in order. Keep a copy of the exact published record so that future edits can be compared against a known-good version.

Related tools and reading: the SPF Checker and the DMARC Checker cover neighbouring checks that pair naturally with this one, and the guide at [/blog/email-deliverability-preflight-checker-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

  • Version tag present and spelled correctly
  • Location is an HTTPS URL ending in an SVG file
  • Authority-evidence URL well formed when present
  • Record published at the correct selector location
  • SPF, DKIM and DMARC foundations already in place

In short: A BIMI record points to a logo file and, usually, a certificate. The checker reads a pasted record; it does not run a live domain lookup. A wrong location, a bad file type or a missing certificate breaks the chain. Fix the record text first, then confirm the logo file itself separately.

One habit ties all of this together: re-check after every change. A result from the BIMI Checker is only as current as the text it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.