BIMI Email: What It Is, How It Works, and How to Set It Up

BIMI, short for Brand Indicators for Message Identification, is an email standard that lets a sender publish a brand logo for use beside authenticated messages in supporting inboxes. BIMI email does not place a logo in every email client automatically: the sender must pass DMARC, publish a valid BIMI DNS record, host a compliant logo, and meet each mailbox provider’s display requirements.

What is BIMI email?

BIMI email is an inbox-branding and email-authentication framework. It gives a domain owner a way to tell participating mailbox providers which logo represents mail sent from that domain. The mailbox provider—not the sender’s email platform—decides whether to retrieve and show that logo next to an individual message.

The important distinction is that BIMI is not an image embedded in an email template. An embedded image travels inside the message and is controlled by the sender’s HTML. A BIMI logo is published separately through DNS and hosted on the public web. A receiving mailbox provider checks the sender’s identity, evaluates the BIMI policy, and may render the logo in the inbox list, message view, or another brand surface.

In plain language, BIMI connects three things:

1. A real sending domain that can authenticate its messages.
2. A public logo file associated with that domain.
3. A mailbox provider’s validation process for deciding whether the logo should be shown.

That design matters because a sender cannot simply upload the logo of another company and expect it to appear. BIMI sits on top of DMARC, which requires aligned authentication. Depending on the provider, a sender may also need an independently validated mark certificate proving its right to use the logo. (bimigroup.org)

BIMI is sometimes described as a logo standard, but that description is incomplete. Its practical purpose is to make trustworthy email more recognizable while giving organizations an incentive to deploy and enforce domain-based anti-spoofing controls.

Why BIMI matters for deliverability and campaign performance

BIMI is not a direct deliverability lever in the same way as list quality, complaint rate, authentication alignment, or sending reputation. Publishing a BIMI record does not guarantee inbox placement, and it does not override spam filtering. If a message is unwanted, poorly authenticated, or sent from a domain with a weak reputation, mailbox providers can still place it in spam or reject it.

What BIMI can do is strengthen the visible connection between an authenticated sender and its brand. In an inbox where recipients see many similarly formatted messages, a familiar logo can make a legitimate sender easier to identify. That may be especially useful for transactional messages, renewal notices, shipping updates, security alerts, receipts, and recurring campaigns where recognition reduces hesitation.

BIMI depends on authentication—not the other way around

DMARC is the foundation of BIMI. DMARC checks whether the domain visible in the From: header aligns with a domain that passes SPF or DKIM. For BIMI eligibility, the DMARC policy must be enforced rather than set to monitoring-only mode.

For example, a monitoring policy like this is not sufficient for BIMI at providers that require enforcement:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A policy that can satisfy BIMI’s enforcement requirement is more like:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com

Or, for the strongest enforcement posture:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com

Google’s BIMI troubleshooting guidance states that the DMARC p value must be quarantine or reject, and that pct must be 100; p=none and partial enforcement do not qualify. The BIMI Group also calls for an enforcement policy at the organizational domain and subdomains. (support.google.com)

This means the real value of a BIMI project is often indirect: it pushes a sender to inventory every stream that uses its domain, configure aligned SPF and DKIM, address unauthorized senders, and move DMARC from observation to enforcement. Those are foundational deliverability improvements whether or not a logo ultimately appears.

Recognition can support healthier recipient behavior

A visible brand indicator may help recipients distinguish expected mail from a lookalike phishing message. That does not make BIMI a complete anti-phishing solution—attackers can still use unrelated domains, compromised accounts, deceptive display names, and social engineering—but it raises the bar for impersonating a protected domain.

For campaign teams, the secondary benefit is clarity. If recipients consistently recognize the sender before opening, they may be less likely to mark a legitimate recurring campaign as spam simply because they do not recognize it. But that outcome is conditional on the basics: consent, useful content, sensible frequency, functioning unsubscribe flows, and a clean audience.

Do not build a business case that assumes a universal open-rate increase. Logo display varies by mailbox provider, recipient application, message type, reputation, and provider policy. Treat BIMI as a trust and brand-consistency investment, then measure its effect carefully instead of assuming it changes performance everywhere.

Is BIMI a metric or a rate?

No. BIMI is not a rate, score, or calculated deliverability metric. There is no standard “BIMI rate” comparable to bounce rate, delivery rate, click-through rate, or spam complaint rate.

The closest useful operational measurements are implementation and exposure metrics. They help answer whether BIMI is technically healthy and whether it is appearing where you expected it to appear.

Useful BIMI measurements to track

A practical BIMI monitoring plan can include:

• DMARC alignment pass rate: the percentage of mail that passes aligned SPF or DKIM under DMARC.
• Authenticated-stream coverage: the share of legitimate sending services included in your SPF, DKIM, and DMARC program.
• BIMI record resolution: whether default._bimi.yourdomain.com returns the intended TXT record from public DNS.
• Logo and certificate availability: whether the SVG and, where used, PEM certificate URLs return successfully over HTTPS.
• Mailbox-provider display observations: screenshots or seed-list observations by provider and app.
• Inbox placement and engagement trends: monitored separately from logo display, because BIMI does not cause inbox placement by itself.

If a team wants a simple internal indicator, it might calculate a BIMI-ready sending share:

BIMI-ready sending share =
(messages sent from domains with enforced DMARC and valid BIMI configuration ÷ all messages sent) × 100

For example, assume a company sends 1,200,000 messages in a month. Of those, 1,050,000 come from its primary domain with aligned SPF or DKIM, an enforced DMARC policy, and a working BIMI record. The remaining 150,000 messages come from an older subdomain with DMARC set to p=none.

(1,050,000 ÷ 1,200,000) × 100 = 87.5%

Its BIMI-ready sending share is 87.5%. That does not mean 87.5% of recipients saw a logo. It means 87.5% of message volume was sent from a domain with the organization’s intended technical prerequisites. Provider support, message reputation, certificate requirements, and recipient app behavior still affect actual logo display.

How BIMI works behind the scenes

BIMI works through a sequence of identity checks and lookups. Although each mailbox provider can apply its own policies, the overall flow is straightforward.

1. A sender delivers a message

The sender uses a visible address such as updates@example.com. The domain that matters most to the recipient is example.com, because it appears in the From: header.

The message should also include valid SPF and/or DKIM authentication. For DMARC to pass, at least one of those mechanisms must align with the visible From: domain according to DMARC alignment rules.

2. The receiver evaluates DMARC

The recipient’s mailbox provider checks the DMARC record for the visible sender domain or its organizational domain. It verifies that SPF or DKIM passes with alignment and evaluates the domain’s DMARC policy.

For BIMI, an enforcement policy is the key threshold. A sender that is still at p=none may be collecting reports and monitoring abuse, but it has not instructed receivers to quarantine or reject unauthenticated impersonation attempts. That is why p=none does not meet common BIMI requirements.

3. The receiver looks up the BIMI assertion record

The standard location for the default BIMI DNS record is:

default._bimi.example.com

The DNS record type is TXT. The record includes a version tag, a logo location tag, and optionally an authority or evidence-document tag.

A common record with a hosted SVG logo and an evidence document looks like this:

v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=https://assets.example.com/bimi/brand-certificate.pem

The tags have specific jobs:

• v=BIMI1 identifies the record as BIMI version 1.
• l= points to the logo, generally an SVG file.
• a= points to the PEM-formatted evidence document, such as a VMC or CMC, when one is used.

The BIMI Group documents the default record location and the v=, l=, and a= pattern. Google’s setup guide similarly describes a BIMI TXT record containing the SVG or PEM URL and gives default._bimi as the host naming convention. (bimigroup.org)

4. The receiver fetches and validates the referenced assets

The receiver can retrieve the logo and certificate material from the published HTTPS URLs. It checks whether the files are reachable and conform to the provider’s requirements.

A problem here can prevent display even if DNS is correct. A URL that redirects unexpectedly, returns a 403 Forbidden, uses an expired TLS certificate, serves an HTML error page in place of the SVG, or is blocked by a restrictive firewall is not a usable BIMI asset.

5. The mailbox provider decides whether to show the logo

Passing the technical checks is necessary, but not always sufficient. A mailbox provider can use its own criteria for display. Yahoo, for example, says it considers a valid BIMI SVG record, DMARC enforcement, bulk-mail context, and sufficient sender reputation and engagement. It also notes that a logo is not displayed for personal email in its implementation. (senders.yahooinc.com)

That final decision explains why BIMI should never be treated as a sender-controlled inbox feature. Senders publish the assertion. Receivers determine the rendering.

BIMI DNS record syntax and implementation details

A BIMI record belongs in your public DNS zone, not in your email content, SMTP configuration, or API request. Most DNS platforms present this as a TXT-record form with fields such as record type, host/name, value/content, and TTL. The labels differ by provider, so confirm how your DNS host appends the root domain before saving the entry.

The default record

For example.com, create a TXT record at:

default._bimi.example.com

Some DNS dashboards automatically append example.com. In that case, entering the full hostname could create the wrong record. Your provider may instead expect only:

default._bimi

The record value can be formatted without extra spaces:

v=BIMI1;l=https://assets.example.com/bimi/logo.svg;a=https://assets.example.com/bimi/brand-certificate.pem

Spaces after semicolons are often seen in documentation for readability, but use the exact value format required by your DNS interface. DNS systems may split long TXT strings internally; that is usually normal when the resolved record reconstructs the intended text.

Google’s current guide uses TXT as the record type, default._bimi.<domain> as the host, and shows a one-hour TTL example. It notes that provider field names can vary and that DNS and display changes can take time to propagate. (support.google.com)

Self-asserted records versus certificates

A self-asserted BIMI record points to a logo but leaves the evidence-document field empty:

v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=;

This is valid BIMI syntax, but it does not guarantee broad display support. The BIMI Group notes that self-asserted records have limited support and that many providers require evidence documents for each logo. (bimigroup.org)

A record that references a certificate typically looks like this:

v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=https://assets.example.com/bimi/brand-certificate.pem

The exact certificate type and acceptance criteria depend on the issuing authority and receiving mailbox provider. A Verified Mark Certificate (VMC) has historically been associated with a registered trademark. A Common Mark Certificate (CMC) is another evidence-document option designed for situations where a logo may not fit the conventional trademark route or where permitted logo variations are needed.

Do not purchase a certificate before confirming that your logo, legal ownership, target mailbox-provider support, and brand-use requirements are ready. The certificate is not a substitute for a working DMARC deployment.

BIMI selectors

BIMI also supports selectors, which can allow a domain owner to publish different BIMI records for different brand contexts. The default selector is default, but selector-based records can support controlled logo changes, brand variations, or testing plans where mailbox-provider behavior permits them.

Selectors should be used carefully. They add another variable to troubleshooting and may not produce consistent display behavior across receivers. Start with a clear default record, then introduce selectors only when there is a specific operational or brand reason to do so. (bimigroup.org)

Logo requirements: why an ordinary SVG may fail

One of the most common BIMI mistakes is assuming that any file ending in .svg is automatically compatible. BIMI logo files must meet a defined profile and mailbox-provider requirements. The BIMI Group’s implementation guidance calls for an SVG Tiny PS version of the official logo. (bimigroup.org)

SVG files made for web pages often include features that are inappropriate for a security-sensitive identity indicator. Examples can include scripts, external references, raster image links, unsupported metadata, fonts that do not travel with the file, animations, or layout behavior that renders unexpectedly at inbox-icon sizes.

Prepare the logo as a controlled production asset

Treat the BIMI logo as a production asset rather than a casual export from a design application. Before publishing it, verify that it:

• Uses the required BIMI-compatible SVG profile.
• Has a square or icon-friendly composition that remains recognizable at small sizes.
• Does not rely on external images, scripts, or remote font files.
• Is served over HTTPS from a stable, publicly accessible URL.
• Is not protected by login, IP allowlisting, bot challenges, signed URLs, or short-lived access tokens.
• Matches the logo embedded in the associated mark certificate when a certificate is used.

A logo that looks perfect in a browser can still fail BIMI validation. Browsers are forgiving rendering engines; BIMI validation is intentionally more restrictive.

Avoid brand-design surprises

The logo used for BIMI is often displayed in a small circular or square treatment chosen by the mailbox provider. Fine taglines, long wordmarks, tiny legal symbols, low-contrast details, and thin line art can become unreadable.

Ask the brand team for a simplified, recognizable mark rather than forcing a full horizontal lockup into a tiny icon space. This is not merely a design preference. If recipients cannot recognize the indicator at inbox size, the trust and recognition value of BIMI is lost.

Common reasons a BIMI logo does not appear

A missing logo is not necessarily evidence that BIMI is broken. It may mean the recipient’s app does not support BIMI, the provider has not chosen to render the logo for that message, or a technical prerequisite is failing.

1. DMARC is not enforced

The most frequent blocker is a domain using p=none, pct below 100, or inconsistent subdomain policy. A sender may have valid SPF and DKIM records yet still be ineligible for BIMI because DMARC remains in monitoring mode.

Fix this by completing your DMARC rollout deliberately. Review aggregate reports, identify every authorized sending source, repair alignment failures, configure subdomain handling, and only then move to full quarantine or reject enforcement. Do not change a DMARC policy blindly on a domain with unknown senders; legitimate mail can be disrupted.

2. SPF or DKIM passes but does not align

Authentication is not just a checkbox. A message can pass SPF for an unrelated return-path domain or pass DKIM with a third-party platform domain, while still failing DMARC alignment with the visible From: domain.

Fix this by configuring custom sending domains in every email platform. For a transactional API service, that usually means authenticating your domain, using aligned DKIM, and setting an aligned return-path or envelope-sender domain where supported. Review actual delivered message headers, not only dashboard status indicators. The email API reference and setup guides can help you map your sending domain configuration to the messages recipients receive.

3. The BIMI TXT record is published at the wrong hostname

A record at _bimi.example.com, bimi.example.com, or default._bimi.mail.example.com will not necessarily answer the lookup for mail sent from example.com. The ordinary default location is default._bimi.example.com.

Fix this by querying public DNS after publication and comparing the exact hostname and resolved value to the intended configuration. Also check whether your DNS interface appends the root domain automatically.

4. The SVG file is inaccessible or incompatible

The SVG URL might return a non-200 status, redirect to a blocked asset host, expose an access-denied page, or contain unsupported SVG features. A cached CDN configuration can also keep serving an outdated file after a redesign.

Fix this by testing the URL from outside your corporate network, reviewing its HTTP response, and validating the file against BIMI-specific SVG requirements. Google recommends verifying that the SVG and PEM files are publicly accessible and that the SVG meets BIMI image requirements. (support.google.com)

5. The VMC or CMC is missing, invalid, expired, or mismatched

Some providers require a certificate-backed assertion to display a logo. Problems can include an expired certificate, an incorrect PEM URL, omitted intermediate certificate material, or a mismatch between the certificate’s validated logo and the SVG being served.

Fix this by working with the issuing authority, confirming the PEM file is publicly reachable, and reviewing the exact certificate-chain requirements. Plan renewal dates as part of your normal domain and certificate calendar.

6. The mailbox provider or recipient app does not support the scenario

BIMI is not universally rendered across every mailbox, desktop client, mobile app, or message type. A logo may show in one provider’s mobile app but not in another provider’s web interface. Yahoo explicitly documents its own display conditions, including sufficient reputation and engagement. (senders.yahooinc.com)

Fix this by testing across the providers that matter to your audience rather than using one recipient inbox as the final verdict. Keep a test matrix with sender domain, recipient provider, app, date, message type, DMARC result, and observed logo behavior.

7. Sender reputation or engagement is weak

Mailbox providers can decline to render brand indicators for mail they do not trust or that recipients do not engage with. BIMI is not a way to decorate a poor sending program into the inbox.

Fix the underlying program: send only to opted-in recipients, remove invalid addresses, suppress long-term inactive contacts where appropriate, make opt-out easy, control frequency, and investigate complaints. Before a campaign launch, use an email address verification tool to reduce avoidable invalid-recipient traffic and protect the reputation on which BIMI display may depend.

How to set up BIMI safely, step by step

A successful BIMI rollout should be treated as an email-identity project with contributions from deliverability, engineering, security, legal, brand, and DNS owners.

Step 1: Inventory all legitimate email streams

List every system that sends as your domain or a subdomain: product email, billing, customer support, marketing automation, CRM workflows, recruiting platforms, help desks, monitoring tools, and employee mail.

For each stream, record the visible From: domain, return-path domain, DKIM signing domain, estimated volume, owner, and whether the mail is still needed. This inventory is essential before moving DMARC to enforcement.

Step 2: Establish aligned SPF and DKIM

Authorize legitimate SPF senders while keeping the record within DNS lookup limits. Enable DKIM for every sending platform and prefer DKIM alignment because it is generally more resilient across forwarding and routing scenarios than SPF alone.

Then inspect delivered headers from actual test messages. Look for spf=pass, dkim=pass, and most importantly dmarc=pass with alignment to the visible From: domain.

Step 3: Deploy DMARC in stages

Begin with reporting if necessary, but do not confuse monitoring with BIMI readiness. Use aggregate reports to discover unknown sources and failures. Progress from p=none to p=quarantine and then, when your mail ecosystem is understood, to p=reject if appropriate for your organization.

Ensure pct=100 before expecting BIMI eligibility at providers that require it. Also evaluate the sp= tag if subdomains send mail or could be abused.

Step 4: Create and host the BIMI-compatible logo

Work from an approved source logo. Produce a BIMI-compatible SVG Tiny PS asset, simplify the composition for small-scale display, and host it at a durable HTTPS URL under infrastructure your team controls.

Do not use a campaign-specific URL that will be removed in a few months. BIMI is associated with domain identity, so its assets should have the same stability expectations as your DMARC and DKIM records.

Step 5: Obtain a VMC or CMC when needed

Review the requirements of the mailbox providers most important to your audience. If certificate-backed BIMI is necessary for the display coverage you want, begin the legal and certificate-validation process early.

This is often the slowest part of implementation because it may require documentation of trademark or mark rights, confirmation of domain control, review by a mark-verifying authority, and coordinated work between legal, brand, and IT teams.

Step 6: Publish the BIMI TXT record

Add the record at the correct default hostname. Example:

Host: default._bimi.example.com
Type: TXT
Value: v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=https://assets.example.com/bimi/brand-certificate.pem

Use the exact URLs that you have tested. Do not point production DNS at a staging host, short-lived CDN path, or file that requires authentication.

Step 7: Validate, send, and monitor

After DNS propagation, validate the published TXT record and send tests to a controlled set of recipient accounts. Inspect message headers for DMARC results, test the SVG and PEM URLs, and record display behavior by provider.

Then monitor after launch. Re-check BIMI after changes to DNS, email vendors, DKIM selectors, brand assets, certificate renewals, CDN rules, or DMARC policy. BIMI is not a one-time switch; it is part of ongoing email identity operations.

BIMI, VMC, CMC, DMARC, SPF, and DKIM: what each one does

These terms are often grouped together, but they solve different parts of the email-trust problem.

The sequence is important. SPF and DKIM establish technical authentication. DMARC evaluates aligned authentication and publishes an abuse-handling policy. BIMI builds on that enforced identity posture to make a logo available to participating inboxes. A VMC or CMC can add evidence that connects the logo to the domain owner where the receiving provider requires it.

Practical BIMI strategy for transactional and campaign senders

The best BIMI strategy is not “add a logo everywhere.” It is “protect the domains that recipients rely on most, then make their identity consistent.”

Use stable domains for important mail

If receipts come from example.com, product alerts from notify.example.com, and marketing campaigns from mail.example.net, recipients have to learn multiple identities. That fragmentation makes authentication, reputation, DMARC reporting, and BIMI management harder.

Consolidate where practical. When separate domains or subdomains are necessary, configure each intentionally and make the brand relationship clear. Remember that mailbox providers may prefer BIMI and DMARC at the organizational-domain level even where subdomains are honored. (senders.yahooinc.com)

Separate reputation, not identity accountability

Many organizations use subdomains to isolate different mail streams, such as notify.example.com for application messages and news.example.com for promotional mail. That can be a sound reputation-management practice. But each subdomain needs its own authentication and policy plan.

Do not assume the parent domain’s BIMI readiness automatically fixes a poorly authenticated subdomain. Validate the exact domain that appears in the From: header for every stream you care about.

Make brand changes a controlled deployment

A logo update can involve the SVG asset, certificate evidence, CDN cache, DNS record, and internal approval chain. Treat it like a production release.

Keep a rollback version of the previous asset. Document the URLs and certificate dates. Test the new logo in a non-disruptive way where possible, then schedule the DNS change with enough time for cache expiration and monitoring.

What BIMI cannot do

BIMI is useful, but it is easy to overstate its role.

BIMI cannot guarantee that:

• Your messages land in the inbox.
• Every recipient sees your logo.
• A recipient trusts the message content.
• A phishing attacker cannot imitate your brand using another domain.
• A poor sender reputation is repaired.
• Open rates, clicks, or revenue increase by a fixed percentage.

It also cannot correct broken email architecture. A domain with misaligned third-party senders, weak permission practices, high complaints, or inconsistent branding needs those issues solved directly.

The right mental model is that BIMI makes verified identity more visible in inboxes that support it. It complements a mature deliverability program; it does not replace one.

FAQ

What does BIMI stand for in email?

BIMI stands for Brand Indicators for Message Identification. It is a standard that lets eligible senders publish a brand logo for display by participating mailbox providers next to authenticated messages.

Does BIMI improve email deliverability?

Not directly. BIMI does not bypass spam filters or guarantee inbox placement. Its biggest deliverability benefit is indirect: implementing it requires enforced DMARC and disciplined authentication, both of which help protect a domain from spoofing and improve email identity hygiene.

Do I need DMARC for BIMI email?

Yes. For common BIMI implementations, DMARC must be enforced with p=quarantine or p=reject and pct=100. A monitoring-only p=none policy does not meet those requirements. (support.google.com)

Do I need a VMC or CMC for BIMI?

It depends on the mailbox provider. BIMI syntax allows a self-asserted logo record, but support is limited at many providers. A VMC or CMC provides evidence associated with the logo and is required by some providers for logo display.

Why is my BIMI logo not showing?

Check the recipient app’s BIMI support, DMARC enforcement and alignment, the exact DNS hostname and record value, public availability of the SVG and PEM files, certificate status, logo compatibility, and your sending reputation. Even a correct implementation can be subject to mailbox-provider display rules.