BIMI (Brand Indicators for Message Identification) is a DNS TXT record that tells email clients to display your logo next to your emails in the inbox. It is a brand trust feature, not a deliverability fix. When it works, your recipients see your logo before they even open the message, which makes your mail instantly recognizable and harder to pass off as a phishing attempt.
Here is the part that catches most brands off guard: BIMI has a hard prerequisite. Your domain must pass DMARC with a policy of p=quarantine or p=reject. If your DMARC is p=none, or your DKIM is broken, or your SPF is failing, BIMI will not display. A lot of brands that try BIMI get stuck on exactly this. They add the BIMI record, nothing shows up, and they have no idea why. The reason is upstream of the BIMI record, in the authentication stack.
The inbox is a crowded, untrusted place. A logo next to your name does three things. It makes your mail recognizable at a glance, so recipients stop treating your transactional mail like a stranger. It reduces successful phishing, because an attacker who spoofs your domain but cannot produce your logo (or a valid Verified Mark Certificate) will not get the logo displayed. And it is becoming a baseline expectation in enterprise inboxes. Outlook, Gmail and Apple Mail all support BIMI, and the brands that show up with a logo are the ones recipients learn to trust.
For agencies and MSPs, BIMI is also a client-facing win. A client whose domain shows its logo in the inbox is a client who can point to a visible, verifiable improvement. That is a concrete deliverable, not a "we improved your deliverability" claim.
BIMI will not render unless your domain passes DMARC with an enforcing policy. This is not a soft recommendation. It is a hard gate. The receiving mail system checks your DMARC record, and if the policy is p=none, the BIMI logo is not shown, regardless of whether the BIMI record itself is correct.
So before you touch BIMI, you need three things in place:
The free audit checks all three in about 30 seconds and tells you the exact record to fix if one is missing. That is the fastest way to find out whether you are actually BIMI-ready.
The logo has to meet a few specific constraints, and these are where a lot of rollouts stall:
The VMC is the part that surprises people. It is not free, it takes a few days to issue, and it requires proof of trademark ownership. If you are rolling out BIMI for a client, budget for it.
Once your DMARC, DKIM and SPF are passing, the BIMI record itself is simple. It lives at default._bimi.yourdomain.com:
v=BIMI1; l=https://yourdomain.com/logo.svg
With a VMC, the record references the certificate:
v=BIMI1; l=vmc:https://yourdomain.com/logo.svg; aa=https://yourdomain.com/certificate.crt
The l tag points to your logo. The aa tag points to your VMC. Both must be served over HTTPS.
Run the free audit first. It checks SPF, DKIM, DMARC, MX, TLS and PTR in about 30 seconds, and shows the exact record to add if one is missing. If your DMARC is at p=none, that is your first fix. If your DKIM selector is wrong, that is your second. Only after those pass do you add the BIMI record.
If you are managing this for a client or a portfolio of domains, the Pro plan monitors every domain around the clock and alerts you the moment a record breaks or an IP gets listed, so a BIMI rollout does not silently stop working because a DKIM key rotated.
Related: What is DMARC · p=none vs quarantine vs reject · SPF vs DKIM vs DMARC
The free audit checks SPF, DKIM, DMARC, MX, TLS and more, and shows the exact record to add if one is missing. No account needed.
Run the free auditWant this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →