The direct answer is that Gmail, Google Workspace mailboxes, Yahoo Mail, AOL, Apple Mail with supported Apple platforms, iCloud Mail, Fastmail, La Poste, GMX, Web.de, Zoho Mail, Onet Poczta, Zone, Zoner, KDDI, NTT docomo, and some Cloudmark-backed environments support BIMI in some form. Microsoft Outlook, Outlook.com, Hotmail, Exchange Online, and Microsoft 365 mailbox receiving do not currently render standard BIMI logos for normal inbound mail.
The important caveat is that BIMI support is not a simple app checklist. I treat BIMI as receiver behavior first, then client behavior second. Gmail can render a BIMI logo in Gmail, Apple Mail can render BIMI in supported Apple environments, and Fastmail can add BIMI information during receiving. A generic email app pointed at an unsupported mailbox does not create BIMI support by itself.
- Best coverage: Plan for Gmail, Yahoo Mail, AOL, Apple Mail, iCloud Mail, and Fastmail first.
- Biggest gap: Do not expect BIMI logos to appear in Outlook or Microsoft 365 mailboxes.
- Real blocker: Most failed BIMI projects fail before the client decision, usually at DMARC enforcement, SVG format, certificate, or sender reputation.
The current BIMI support list
The cleanest public reference for receiver adoption is the BIMI provider chart, which lists supported, considering, and unsupported providers. I use it as a starting point, then I still test with real mailboxes because each receiver has its own certificate, policy, reputation, and client-display rules.
|
|
|
|
|---|---|---|---|
 Gmail | Supported | VMC or CMC | VMC adds the checkmark. |
 Yahoo Mail | Supported | Usually optional | Reputation matters. |
 Apple Mail | Supported | VMC or evidence | Requires supported Apple paths. |
 Fastmail | Supported | Optional | Receives and sends BIMI. |
AOL | Supported | Usually optional | Follows Yahoo ecosystem behavior. |
GMX and Web.de | Supported | Varies | Regional support. |
 Zoho Mail | Supported | Varies | Listed by BIMI Group. |
 Outlook | No | N/A | No normal rendering. |
Practical BIMI support matrix for senders planning logo display.
A useful November 2024 snapshot also calls out the same practical split: Apple, Fastmail, Gmail, La Poste, GMX, Yahoo Mail, Zoho Mail, and several regional providers support BIMI, while Microsoft remains the major unsupported receiver.
Gmail inbox view showing where a BIMI logo can appear.
Why support depends on the receiver
The phrase "email client support" creates confusion because BIMI is evaluated during mail receiving. The receiving mailbox provider checks authentication, DNS, the BIMI record, the logo file, evidence documents, and local policy. The app then displays what the provider makes available. That is why Apple Mail support is different from Gmail support, and why Outlook as an app does not solve the lack of Microsoft receiver support.
What the sender controls
- Authentication: SPF and DKIM must be configured so DMARC passes through the visible From domain.
- Policy: DMARC must be at enforcement, usually quarantine or reject at full coverage.
- Logo: The logo must be square, secure, and saved as BIMI-compatible SVG.
- Record: DNS must publish the BIMI selector and point to the logo.
- Evidence: A VMC or CMC is required by Gmail. Apple checks BIMI evidence documents.
What the receiver controls
- Rendering: The receiver decides whether to show the logo in its inbox UI.
- Policy checks: The receiver can apply extra local rules beyond the BIMI DNS record.
- Reputation: Some providers suppress logos when sender reputation or engagement is weak.
- Client path: The same account can behave differently across web, mobile, and desktop clients.
- Fallback: Unsupported providers fall back to initials, profile photos, or their own logo systems.
This is also why a BIMI record can be technically valid and still not show everywhere. Valid DNS proves the record exists. It does not force every receiver to render the logo.
Do not treat the app name as the answer
If a recipient reads a Gmail mailbox in Gmail, BIMI is in play. If a recipient reads a Microsoft mailbox in Outlook, BIMI is not in play for standard rendering. If a recipient reads a Fastmail mailbox in Apple Mail, Apple Mail can show BIMI because Fastmail can add the required BIMI information during receiving.
Provider notes that matter in testing
I separate providers by how they behave in a real rollout, not just whether their logo appears on a support chart. The practical questions are whether a certificate is required, whether the receiver expects reject instead of quarantine, and whether the logo appears across web and mobile clients.
- Gmail: Gmail and Google Workspace mailboxes support BIMI with a VMC or CMC. A VMC can add the Gmail verification checkmark; a CMC can support logo display without that checkmark.
- Yahoo and AOL: Yahoo Mail and AOL support BIMI. I plan Yahoo testing around strong DMARC and sender reputation because the record alone does not guarantee display.
- Apple Mail: Apple supports BIMI on iOS 16 or later, iPadOS 16 or later, macOS Ventura 13 or later, and iCloud.com, but both the sender and the email service path must meet Apple requirements.
- Fastmail: Fastmail supports BIMI for received and sent mail. It fetches the logo during receiving, then adds logo information to message headers.
- Microsoft: Outlook, Outlook.com, Hotmail, Exchange Online, and Microsoft 365 mailboxes do not render standard BIMI logos. See the deeper Outlook BIMI support breakdown if Microsoft audiences dominate your list.
- Regional providers: La Poste, GMX, Web.de, Onet Poczta, Zone, Zoner, KDDI, and NTT docomo matter when your recipient base includes those markets.
For Microsoft-heavy lists, I do not sell BIMI as an Outlook logo project. I sell it as a DMARC enforcement and brand-consistency project that pays off in Gmail, Yahoo, Apple, and Fastmail inboxes. Microsoft also has a Microsoft BIMI note for senders using Dynamics 365 Customer Insights, but that does not change Outlook receiver rendering.
The useful test is recipient-weighted
Export your subscriber or customer domains, group them by mailbox provider, then decide whether BIMI coverage justifies the certificate and setup work. If 70 percent of your engaged audience is Gmail, Yahoo, Apple, and Fastmail, BIMI has a clearer payoff than it does for a Microsoft-only B2B list.
What has to be in place before a logo can display
Before worrying about which client supports BIMI, check whether the sending domain is eligible. The domain needs passing SPF or DKIM, DMARC at enforcement, a compliant SVG logo, a BIMI TXT record, and usually a certificate file for the providers that matter most.
The fastest first check is a broad authentication scan. Suped's domain health checker is useful here because BIMI depends on the same SPF, DKIM, and DMARC foundation that protects the domain before the logo work starts.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A minimum-ready setup looks like this. The DMARC record is at enforcement, and the BIMI record points to the logo plus the evidence document when one is required.
DMARC TXT recorddns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com
BIMI TXT recorddns
Host: default._bimi.example.com Type: TXT Value: v=BIMI1; l=https://brand.example/logo.svg; a=https://brand.example/vmc.pem;
If you need to build the record without hand-formatting tags, use Suped's DMARC record generator for the policy record, then publish the BIMI record only after authentication is passing consistently.
A valid record is not the same as display
A DNS checker can confirm that the record exists and parses. The receiving provider still decides whether the message qualifies for logo display. That decision includes authentication results, certificate checks, reputation, client path, and local anti-abuse rules.
How Suped fits into BIMI readiness
BIMI is the visible result. The harder operational work is getting every legitimate sender through DMARC before moving to quarantine or reject. Suped's DMARC monitoring shows which services send mail for the domain, which ones pass authentication, and which failures need fixing before BIMI testing.
For most teams, Suped is the best practical DMARC platform for the work that comes before BIMI because it turns aggregate reports into actions. Automated issue detection, real-time alerts, DMARC policy monitoring, hosted SPF, hosted MTA-STS, SPF flattening, and multi-tenant reporting all support the same goal: reach enforcement without breaking legitimate mail.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
When DNS ownership is split across IT, marketing, and agencies, Suped's Hosted DMARC helps stage policy changes without turning every adjustment into a DNS ticket. That matters because BIMI needs enforcement, and enforcement is where weak sender inventories cause surprises.
- Source inventory: Identify every sending service before raising policy.
- Policy staging: Move from monitoring to quarantine or reject with evidence.
- Issue steps: Use clear fix guidance when SPF, DKIM, or DMARC fails.
- Alerts: Catch authentication regressions before BIMI display drops.
- Scale: Manage multiple domains in one place for MSPs, agencies, and larger teams.
A practical testing sequence
I test BIMI in a fixed order because it prevents chasing client issues before the domain is ready. If your priority is Gmail and Yahoo Mail, the Gmail and Yahoo setup path deserves separate planning because the Gmail certificate requirement changes the budget and timeline.
BIMI testing sequence from DMARC checks to mailbox display testing.
- Audit: List every platform sending mail with your From domain.
- Enforce: Move DMARC to quarantine or reject after legitimate mail passes.
- Prepare: Create a BIMI-compatible SVG and obtain the right certificate.
- Publish: Add the BIMI TXT record at the default selector.
- Send: Test with real Gmail, Yahoo, Apple, Fastmail, and Microsoft inboxes.
- Compare: Separate DNS success from actual logo display in each client.
- Monitor: Keep watching DMARC failures after the logo appears.
The most useful test matrix includes at least Gmail web, Gmail mobile, Yahoo Mail web, Yahoo Mail mobile, Apple Mail with iCloud, Apple Mail with Fastmail if relevant, Fastmail web, and Outlook. Outlook should be in the matrix precisely because it confirms the expected non-display path.
The practical answer
The email clients and providers that actually matter for most BIMI projects are Gmail, Yahoo Mail, AOL, Apple Mail, iCloud Mail, and Fastmail, with regional coverage through providers like La Poste, GMX, Web.de, Zoho Mail, Onet Poczta, Zone, Zoner, KDDI, and NTT docomo. Microsoft Outlook and Exchange Online remain the major unsupported gap.
BIMI is worth doing when your audience includes supported receivers and your domain is ready for DMARC enforcement. Start with authentication, not artwork. Once the domain is stable, the logo work becomes much more predictable, and the logo placement guide can help set expectations for what recipients will actually see.
