A BIMI logo appears inside supported recipient email clients, not only on webmail. In practice, I expect it to show in Gmail apps, Yahoo Mail apps, Yahoo and AOL webmail read views, Apple Mail on iOS 16, iPadOS 16, macOS Ventura 13 or later, and iCloud.com when the sender and receiving mailbox both meet the BIMI requirements.
The exact placement changes by client. Mobile apps often show the logo in the message list, beside the sender or subject. Webmail more often shows it inside the opened message, near the sender identity. Apple Mail is best checked in the opened message or expanded header area, because list-view display is not the same across accounts and operating system versions.
- Gmail: Look in the Gmail mobile app list view and inside opened messages. Gmail also shows a verified checkmark for eligible VMC-backed senders.
- Yahoo: Look in Yahoo Mail mobile list view, mobile read view, and desktop webmail read view. AOL follows the same Yahoo Inc. mailbox family pattern.
- Apple Mail: Look in Apple Mail on current Apple operating systems and iCloud.com. The sender and the mailbox provider both need to meet BIMI requirements.
- Unsupported clients: Do not expect BIMI display in Outlook, Microsoft 365 mail interfaces, Samsung Mail, or every native mail app.
The short answer by email client
The most useful way to answer the placement question is by separating the mailbox provider, the app, and the view. BIMI is not a sender-side badge that travels unchanged through every email app. The receiving platform authenticates the message, checks DNS, applies its own policy, and then decides where the logo is shown.
|
|
|
|
|---|---|---|---|
 Gmail | List and read | Read view | Needs certificate |
 Yahoo/AOL | List and read | Read view | Volume matters |
 Apple Mail | Read view | iCloud.com | OS version |
Fastmail | Read view | Read view | Provider rules |
La Poste | List and read | List and read | Regional use |
Outlook | No BIMI | No BIMI | Different logo systems |
Common BIMI display locations by client family.
Gmail mobile inbox list with sender logo circles beside messages.
The key caveat is that a logo visible in one account does not prove it is visible everywhere. A Gmail user reading mail in the Gmail app and the same user reading that mailbox through Apple Mail are separate tests. I log those as separate results because the client and the mailbox provider both affect display.
Why the same BIMI setup appears in different places
BIMI gives the receiver a standardized way to find the sender's preferred logo, but it does not force the receiver to render the logo in a specific pixel location. The receiver still controls whether the logo appears at all, whether it is shown in list view, whether it is shown in read view, and whether any additional verified marker appears.
Mobile app behavior
- List view: Many mobile apps have a sender icon slot beside each message, so BIMI often appears there.
- Read view: Opened messages usually have a sender identity area where the same logo can appear.
- Device state: App version, OS version, and account type change what the recipient sees.
Webmail behavior
- Message list: Some webmail inboxes use compact rows and do not show BIMI beside every subject.
- Read view: The opened message is the most reliable webmail location to check first.
- Policy layer: The mailbox provider still applies reputation, volume, and certificate rules.
The BIMI Group overview explains the receiver-side flow: the mailbox provider authenticates the message, checks DNS for a BIMI record, and then uses the brand logo with the message display when its criteria are met.
That receiver choice is why BIMI troubleshooting should not stop at DNS. I check DMARC, the BIMI record, the logo file, the certificate, the message headers, the app view, and the web view before I call a test failed.
The technical path behind the logo
Before any client can show a BIMI logo, the message needs to pass the sender identity checks that BIMI depends on. The sender publishes a BIMI TXT record in DNS. The receiving provider checks the message, confirms DMARC enforcement, retrieves the logo and certificate where required, then makes a display decision.
Flowchart showing how a BIMI logo reaches a supported email client.
DMARC and BIMI DNS exampledns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; pct=100; " "rua=mailto:dmarc-reports@example.com" ) default._bimi.example.com. 3600 IN TXT ( "v=BIMI1; " "l=https://assets.example.com/bimi.svg; " "a=https://assets.example.com/vmc.pem" )
- DMARC policy: Use p=quarantine or p=reject with full enforcement, not monitoring-only policy.
- Authentication: The message needs SPF or DKIM to pass in a way that matches the visible From domain.
- Logo file: The SVG needs to follow BIMI constraints and be reachable over HTTPS.
- Certificate: Gmail and Apple require a certificate-backed setup for display. Yahoo can show self-asserted BIMI when other conditions pass.
- Receiver policy: The mailbox provider applies reputation, sending volume, cache state, and abuse protections.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
I start with domain health rather than logo display because the display layer is the last step. A clean BIMI record cannot overcome a monitoring-only DMARC policy or a sender source that fails the visible-domain match.
What to expect in Gmail, Yahoo, and Apple Mail
Gmail is strict. It requires DMARC enforcement and certification through a VMC or CMC path. The Google's BIMI setup documentation is clear that Gmail displays supported BIMI logos with messages and shows a checkmark next to VMC-verified senders. I test Gmail in the mobile app first because the list view makes logo display obvious.
Yahoo Mail and AOL are often more visible for mobile-list testing. Yahoo's sender guidance says BIMI logos show in message list and read view experiences in mobile apps, and in read message views on desktop webmail. It also applies reputation and bulk-sending expectations, so a technically correct record on a tiny or low-reputation stream still fails to render.
Apple Mail support changed after the early BIMI adoption period. Apple Mail supports BIMI on iOS 16, iPadOS 16, macOS Ventura 13 or later, and iCloud.com. I still treat Apple as its own test target because Apple Mail, iCloud mail routing, and third-party accounts inside the Mail app do not always give the same result.
Do not confuse BIMI with profile photos, contact images, or proprietary brand icons. A logo in a circular sender avatar slot proves only that a logo is displayed. To prove BIMI, check the BIMI DNS record, the certificate requirement for that receiver, and the authentication result in the message headers.
For a broader client-by-client view, I keep a separate compatibility note for BIMI client support. The placement question and the support question are related, but they are not identical.
How I test logo placement
A useful BIMI test plan has two jobs: prove the DNS and authentication setup works, then prove the logo renders in real recipient clients. I do not treat a single Gmail inbox screenshot as a complete pass because one client view is one data point.
- Record setup: Confirm DMARC enforcement, BIMI DNS, SVG availability, and certificate status before sending tests.
- Send seeds: Send normal production-style messages to Gmail, Yahoo, AOL, iCloud, Fastmail, and any regional clients that matter to your audience.
- Check views: Inspect mobile list view, mobile read view, desktop webmail list view, and desktop webmail read view separately.
- Save evidence: Capture the client, account type, app version, OS version, timestamp, and message headers.
- Wait on cache: Give receivers several days after changing the SVG, certificate, or DNS record before drawing conclusions.
|
|
|
|---|---|---|
Gmail app | List | Logo avatar |
Gmail web | Read | Logo and check |
Yahoo app | List | Brand logo |
Apple Mail | Read | Certified sender |
A compact BIMI placement test matrix.
This matrix also stops false negatives. If Yahoo mobile shows the logo but Gmail web does not, that points to a Gmail-specific requirement such as the certificate path, not a universal BIMI failure. If Gmail app shows a logo that does not match your BIMI SVG, that points to profile or cached sender imagery.
Where Suped fits in the workflow
Suped's product fits before and during BIMI testing because BIMI depends on DMARC staying correct over time. Suped brings DMARC monitoring, SPF, DKIM, alerting, and issue detection into one place, so I can see which sources are ready for a BIMI rollout and which sources still break the visible-domain match.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For most teams, Suped is the best overall DMARC platform for the work that comes before logo display: finding failing sources, staging policy changes, checking DNS, and keeping authentication healthy after the first BIMI launch. The free plan is useful for early validation, and the hosted options matter when DNS access is slow or spread across teams.
- Hosted policy: Suped's hosted DMARC helps teams move through enforcement without repeated manual DNS edits.
- Record checks: The DMARC checker catches policy mistakes before you start testing BIMI clients.
- Health checks: The domain health checker gives a broader read on SPF, DKIM, and DMARC readiness.
BIMI is the visible outcome. Suped is where I want the prerequisite problems to surface before a marketing team spends time comparing app screenshots.
Common reasons the logo still does not appear
A missing BIMI logo usually has a specific cause. I work through these in order because changing the logo or certificate first often masks the real issue.
- Weak policy: A domain still using p=none does not satisfy BIMI enforcement requirements.
- Bad source: One sending platform fails SPF or DKIM against the visible From domain.
- Invalid SVG: The logo is not in the BIMI-safe SVG profile or is blocked by HTTPS hosting issues.
- Certificate gap: Gmail and Apple display depends on the required VMC or CMC evidence path.
- Receiver cache: Some receivers hold old logo or DNS state for days, especially after recent changes.
For Gmail-specific certificate questions, I use a separate checklist for VMC for Gmail. For a full deployment sequence, the BIMI setup steps page covers the DNS, logo, and certificate order.
Views from the trenches
Best practices
Test mobile list view and open message view because providers place BIMI differently.
Use DMARC enforcement before BIMI testing, not after the logo fails to render in clients.
Keep a simple client matrix with account, app, device, view, and test date for retests.
Common pitfalls
Treating a Google profile image as BIMI hides real DNS or certificate problems during tests.
Checking only Apple Mail list view misses logos that appear inside opened message headers.
Changing the SVG repeatedly during receiver caching makes troubleshooting harder than needed.
Expert tips
Use one distinctive test SVG version so you can tell BIMI apart from cached avatars.
Wait several days for Yahoo-style caching before assuming a correct record failed.
Record screenshots from each client because support differs across app and web views.
Marketer from Email Geeks says Yahoo Mail on iOS displayed the BIMI logo in the mobile app, confirming that app testing matters.
2022-02-23 - Email Geeks
Marketer from Email Geeks says Gmail displayed the BIMI logo inside the iOS app, so webmail is not the only valid test target.
2022-02-23 - Email Geeks
The practical answer
The BIMI logo appears wherever the receiving email client chooses to render it after authentication, DNS, certificate, and provider policy checks pass. For Gmail and Yahoo, that includes mobile apps and webmail, with mobile list views often being the easiest place to see it. For Apple Mail, check current Apple operating systems and iCloud.com, especially the opened message identity area.
I would not judge BIMI by one inbox. The right answer is a small matrix: Gmail app, Gmail web, Yahoo app, Yahoo web, Apple Mail, iCloud.com, and any regional mailbox provider your audience uses. If DNS is correct but one cell is blank, troubleshoot that receiver's requirements rather than rebuilding the whole BIMI setup.
