What Is a BIMI Record, and Do You Need One?

The short answer

A BIMI record can help your logo show beside trusted mail in some inboxes. It will not rescue a weak sending setup.

BIMI stands for Brand Indicators for Message Identification. It is a DNS TXT record, often published at default._bimi.example.com, that points mailbox providers to your brand logo. Some providers require a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) before they show the logo. Gmail documents support for both VMCs and CMCs, with different display treatment, so check the current mailbox provider rules before you buy a certificate.

You need BIMI only after your core email authentication is clean. If SPF, DKIM, and DMARC are broken, Gmail and Outlook are more likely to distrust the message. A logo cannot overcome failed authentication, poor list quality, spam complaints, missing MX records for replies, or a domain or IP on a blocklist.

If you send customer mail from a real brand domain, BIMI can be worth doing after DMARC is enforced. It can make trusted mail easier to recognize. If you send a few internal or early-stage emails, fix authentication and reputation first.

What a BIMI record looks like

BIMI is small in DNS, but strict in practice.

A common BIMI TXT value looks like v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem. The l tag points to the logo file. The a tag points to a certificate file when your mailbox provider requires one. The logo must be hosted over HTTPS and must meet the BIMI SVG profile. A normal PNG, JPG, or random website SVG is not enough.

The record does not sign mail. DKIM signs mail. The record does not tell receivers what to do with failed mail. DMARC does that. BIMI is a brand display layer that sits on top of those controls.

The checks that must come first

Do these before you spend time on a logo certificate.

• SPF: Publish one SPF TXT record for the domain that sends mail. Include the services that send for you. Stay under the SPF 10 DNS-lookup limit from RFC 7208. Use ~all while you are still checking sources, then move to -all only when you are sure no valid sender is missing.
• DKIM: Turn on DKIM signing in each mail platform. Each sender may use its own selector, such as google._domainkey or a provider-specific name. The public key in DNS must match the private key used to sign the message.
• DMARC: Publish _dmarc for your visible From domain. DMARC passes when SPF or DKIM passes and aligns with that From domain. Start with p=none and a rua mailbox so you can see who is sending. Read the aggregate reports with the free DMARC report reader. Move to p=quarantine or p=reject once valid mail passes. For BIMI, expect mailbox providers to require an enforced DMARC policy.
• MX and replies: Make sure the domain can receive mail if people reply. Broken MX is a trust and operations problem, even when outbound mail is signed.
• Reputation: Check whether your domain or sending IP appears on major blocklists. Authentication helps receivers know who sent the mail, but reputation still affects inbox placement.

You can run the free domain scorecard before touching BIMI. It reads SPF, DKIM, DMARC, and MX, then shows the highest-risk fix first.

When BIMI is worth it

BIMI is a good second-stage project for teams that already send clean mail.

It is worth considering when you send customer-facing mail from a stable brand domain, your DMARC policy is enforced, your logo can pass the certificate path your mailbox providers expect, and you care about brand trust in crowded inboxes.

It can wait if you are still using a shared sending domain, changing email platforms, missing DKIM on one sender, sending cold mail from fresh domains, or getting spam-folder complaints. In those cases, Gmail and Outlook are judging the basics first: authentication, alignment, complaint rate, engagement, sending patterns, links, content, and reputation.

One DNS record will not cover every surface

BIMI affects inbox display. It does not control whether AI search tools can read your site.

If your brand also depends on search answers, check robots.txt separately. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not block live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is a stated policy from your site, not proof of what a bot did. Perplexity-User and Bytespider have been reported to ignore robots.txt, so logs and vendor docs matter. Only Googlebot documents JavaScript rendering. Client-side-only content may be an undocumented risk for other AI crawlers.

Use the free AI visibility checker if you want to see whether the right crawlers can reach and read a page.

Sources worth checking

Use primary sources when a rule affects inbox placement or search visibility.

• SPF: RFC 7208. DKIM: RFC 6376. DMARC: RFC 7489.
• BIMI: BIMI Group and Google Workspace BIMI setup.
• Sender rules: Google sender guidelines and Microsoft Outlook sender requirements.
• AI crawlers: OpenAI crawler docs, Anthropic crawler docs, Perplexity crawler docs, Google AI feature docs, Applebot docs, and Common Crawl CCBot docs.