19 June 2026 · 13 min read
BIMI is the feature that finally puts your brand logo next to your messages in the inbox, and it is also the feature most likely to disappoint you if you set it up without understanding what the major mailbox providers actually do with it. The specification is the same everywhere, but Gmail, Apple Mail and the rest each interpret it on their own terms. One shows a circular avatar, another shows a square one, a third may show nothing at all until you have jumped through an extra hoop that has nothing to do with your DNS record.
This guide is about the practical reality rather than the theory. We will look at what Gmail displays, what Apple Mail displays, what each one demands before it will show anything, where the Verified Mark Certificate fits in, and how to test your setup so you are not relying on a logo that only ever appears in your own head. If you have not yet published a BIMI record, the BIMI checker will show you exactly what is and is not in place today, and the BIMI product page explains the done-for-you path. This article fills in what happens between publishing the record and seeing the logo.
The one thing that gates everything: a reject-or-quarantine DMARC policy
Before any provider will even look at your BIMI record, your domain has to be enforcing DMARC. This is not a BIMI quirk; it is the entire point of BIMI. The logo is a reward for having locked down your domain against spoofing, and the lock is your DMARC policy.
In concrete terms, the domain in the visible From: address must be covered by a DMARC record with a policy of p=quarantine or p=reject. A policy of p=none will never trigger a logo anywhere, no matter how perfect the rest of your BIMI setup is. Gmail goes further and effectively wants p=reject, or at minimum p=quarantine with a high enforcement percentage; a pct value below 100 on a quarantine policy is treated by some receivers as not fully enforcing, and BIMI quietly stays off.
There is also an organisational-versus-subdomain wrinkle that catches people out. If you send from news.example.com but only example.com has a DMARC record, the subdomain inherits policy through the sp tag of the parent. That inherited policy still has to be quarantine or reject for the subdomain to qualify. If your parent record reads p=reject; sp=none, your subdomains are wide open and BIMI will not appear on mail sent from them. You can confirm what policy actually applies to a given sending domain with the DMARC checker, and the mechanics of inherited policy are covered in the subdomain policy article.
So the order of operations is fixed and there is no shortcut around it:
- Get SPF and DKIM aligned and passing for your real mail streams.
- Move your DMARC policy to
p=quarantineand thenp=reject, watching your aggregate reports the whole way. - Only then publish a BIMI record and pursue a certificate.
If you try to do BIMI first, you are building the roof before the walls. The safe route from none to reject without breaking legitimate mail is exactly what the done-for-you service and the staged guidance at /requirements are built around.
What the BIMI record itself looks like
A BIMI record is a DNS TXT entry published at a predictable location: the label default._bimi prefixed to your domain. For example.com that is default._bimi.example.com. The default part is the selector, and just as with DKIM you can run multiple selectors, but default is the one providers look for unless a message header points them elsewhere.
The record contains two tags that matter:
v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pemv=BIMI1is the version, and it must come first, exactly as written.l=is the HTTPS URL of your logo image. The image must be in a specific, restricted profile of SVG known as SVG Portable/Secure, abbreviated SVG Tiny PS or sometimes SVG P/S. An ordinary SVG exported from a design tool will almost never pass; it has to be a square, have atitleelement, use no external references, no scripts and no raster images embedded inside it.a=is the HTTPS URL of your certificate file, the Verified Mark Certificate or the newer Common Mark Certificate, served as a PEM bundle.
The l= tag alone is enough for the record to be syntactically valid, but on its own it will display in almost nowhere worth caring about today. The a= tag, pointing at a real certificate, is what unlocks the providers that actually matter. We will come back to why.
How Gmail displays BIMI
Gmail was the provider that made BIMI matter. When Google switched it on for general availability, it became realistic to expect a verified logo in front of millions of inboxes, and that is what moved BIMI from a curiosity to something brands chase.
Here is what Gmail actually shows and demands.
Gmail requires a certificate, full stop
Gmail will not display a BIMI logo from the l= tag alone. It requires a valid Verified Mark Certificate or Common Mark Certificate referenced in the a= tag. This is the single biggest reason people publish a BIMI record, see it pass a syntax check, and then never see a logo in Gmail. The record is fine; there is simply no certificate behind it, and Gmail treats no certificate as no logo.
A Verified Mark Certificate proves that the logo belongs to a trademark you own. A Common Mark Certificate, introduced later, covers logos that are not registered trademarks but have been in prior use, and Gmail accepts both. Either way, Gmail wants cryptographic proof that you are entitled to the mark, not just an image sitting on your web server.
Where the logo appears in Gmail
In Gmail, the verified logo replaces the circular sender avatar. In the message list it shows as a round badge to the left of the sender name and subject. Open the message and the same logo appears as the larger sender avatar at the top. On a verified message Gmail also surfaces a small verification indicator that, when tapped, tells the reader the logo has been verified, which is the trust signal you are really paying for.
Two display details trip people up. First, Gmail renders your square SVG inside a circular mask, so anything in the corners of your artwork gets clipped. Design for a circle even though the file is square. Second, the avatar slot is shared: if a contact has set their own photo, or if Google already has a strong avatar for that sender, what the user sees can vary. The logo is most reliable for cold, transactional and marketing mail where no personal contact photo exists.
Gmail's enforcement expectations
Gmail is the strictest of the mainstream providers on policy. Aim for p=reject on the sending domain. A p=quarantine with full enforcement can work, but anything that reads as partial enforcement, such as a reduced pct, risks suppressing the logo. Gmail also wants the authentication that DMARC sits on to be genuinely solid: the message must pass DMARC with the From: domain aligned, which in practice means a passing, aligned DKIM signature on every message, because forwarded or relayed mail that only passed via SPF will often fail alignment and lose the logo. If your DKIM is shaky, the DKIM checker is the fastest way to confirm it is signing and aligning correctly.
How Apple Mail displays BIMI
Apple added BIMI support across its Mail apps on iOS, iPadOS and macOS, and Apple's behaviour is meaningfully different from Gmail's in ways that change how you should think about the certificate decision.
Apple also requires a certificate
Like Gmail, Apple's BIMI support is gated behind a Verified Mark Certificate or Common Mark Certificate. Apple does not display logos from the l= tag alone in its standard BIMI handling. So the certificate is not a Gmail-only cost; the two providers that account for the bulk of consumer attention both insist on one. Budget for the certificate as a requirement, not an optional upgrade, if Gmail and Apple are your audience.
Where the logo appears in Apple Mail
Apple Mail shows the logo as the sender image next to the message in the list view, and within the open message at the top near the sender details. Crucially, Apple tends to render the mark in a rounded-square or squircle shape rather than the hard circle Gmail uses. The same square SVG file is used, but the cropping is gentler, so a logo that looks clipped in Gmail's circle may look fine in Apple Mail, and vice versa. Test in both.
Apple's display is also tied into the contact and sender model of the operating system. If the recipient has the sender saved as a contact with a photo, that photo can take precedence. As with Gmail, BIMI logos shine brightest on mail from senders the recipient has not personally saved.
A note on Apple's wider sender-image behaviour
Apple has its own broader system for sender images and brand indicators that does not always map one-to-one onto BIMI. The reliable, standards-based path you control is the BIMI record plus certificate; that is what this guide covers. Do not assume that because you have seen a logo next to some brand in Apple Mail, it arrived purely through BIMI. Stick to validating your own BIMI chain and you will get predictable results.
The certificate requirement, explained properly
The Verified Mark Certificate, VMC, is the part of BIMI that costs real money and real time, so it is worth understanding what you are buying.
A VMC is issued by a small number of certificate authorities and it certifies two things bound together: that a particular logo image corresponds to a trademark, and that your organisation controls both. To get one you typically need:
- A logo that is a registered trademark in a recognised jurisdiction, with the registration number to hand. (A Common Mark Certificate, CMC, relaxes the registered-trademark requirement and instead accepts prior-use evidence, which opens BIMI to organisations whose logo is not formally trademarked.)
- The logo converted to the strict SVG Tiny PS profile, matching the trademarked mark closely.
- An organisational validation process, similar in spirit to an extended-validation TLS certificate, where the CA confirms your organisation is real and that you are authorised to request the certificate.
The output is a PEM file that you host over HTTPS and reference in the a= tag of your BIMI record. The certificate embeds your logo, so the image a provider trusts is the one inside the certificate, which is why the file at your l= URL and the image inside the VMC must match.
Two honest caveats. First, the validation can take weeks, not days, because it involves trademark and organisation checks performed by humans. Second, the certificate has an annual cost and an expiry; if it lapses, your logos disappear from Gmail and Apple Mail at renewal time just as surely as if you had deleted the record. Treat VMC expiry like a TLS certificate expiry: monitor it, because nobody emails you a friendly reminder before the logos vanish from millions of inboxes.
Why your logo is not showing: the common failure list
When a BIMI logo fails to appear, it is almost always one of a short list of causes. Walk them in order.
- DMARC is not enforcing. The sending domain is on
p=none, or it is a subdomain inheritingsp=none. Fix the policy first. Confirm with the DMARC checker. - DMARC is enforcing but mail is not actually passing it. The policy says reject, but individual messages fail alignment, so they never qualify for the logo. Your aggregate reports tell you the true pass rate; the report analyser turns those XML files into a readable picture, and the reports-versus-inbox article explains why a passing report is not the same as a delivered inbox.
- No certificate. The record has only an
l=tag. Gmail and Apple both need thea=tag pointing at a valid VMC or CMC. This is the most common single cause. - The SVG is not in the Tiny PS profile. It is a normal SVG, or it is not square, or it has a script, an external reference or an embedded raster image. Providers silently reject it.
- The image inside the certificate does not match the hosted logo. The VMC was issued for one version of the mark and the
l=URL serves a different one. - The logo or certificate URL is not served cleanly over HTTPS. A redirect, a self-signed certificate, a
403, or a wrong content type on the SVG will all break fetching. - You are looking too soon. Providers cache. After you publish or fix a record, allow time for caches to expire before concluding it has not worked.
How to test your BIMI before you rely on it
Testing BIMI properly means testing the chain, not just the record. Do it in this order so each step rules out a layer.
Validate the record and the chain with a checker
Start with the BIMI checker. Paste your domain and it will confirm that a record exists at default._bimi, that the syntax is valid, that the l= URL resolves, and that an a= certificate is present and reachable. This catches publishing typos, missing tags and unreachable URLs in seconds, before you waste time hunting for a logo that was never going to appear.
Confirm the DMARC prerequisite separately
Because BIMI depends on DMARC, check that layer on its own with the DMARC checker. You are looking for p=quarantine or p=reject on the exact domain you send from, with full enforcement. If you send from a subdomain, verify the policy that actually applies to that subdomain rather than the apex.
Send real mail to real test inboxes
A checker validates structure; only a live message proves display. Create test accounts at Gmail and at iCloud, and send genuine mail from your production sending platform, not a hand-crafted test. The send path matters because BIMI hinges on DKIM alignment, and only your real platform reproduces that. Open the message in:
- Gmail on the web and the Gmail mobile app.
- Apple Mail on an iPhone or iPad and on macOS, signed into an iCloud account.
Check both the message-list avatar and the opened-message header in each. Remember the shape difference: Gmail crops to a circle, Apple to a rounded square. A logo that survives the circle will survive the square, so design to the tighter constraint.
Read the headers and confirm the verdict
In Gmail, open the message and use "Show original" to read the authentication results. You want to see DMARC pass with the From: domain aligned, because that pass is the precondition for the logo. If DMARC is failing on your own test send, BIMI is the least of your problems and you should return to SPF and DKIM. The SPF checker and DKIM checker isolate which underlying check is the weak link.
Test every sending stream, not just one
This is the step teams skip and regret. Your marketing platform, your transactional provider, your helpdesk, your invoicing system and your own mail server are separate streams, each with its own SPF and DKIM setup. BIMI can appear on mail from one stream and be missing from another because that stream is not aligning. Send a real message from each system you use and verify the logo on each. Ongoing, this is exactly what continuous monitoring is for: it watches your authentication and your BIMI record so that a silent break, an expired certificate or a misconfigured new stream is caught before your customers notice the logo has gone.
A realistic picture of where logos show up
It helps to set expectations honestly. With a fully enforced DMARC policy, a valid VMC or CMC, and a correct SVG, you can reasonably expect logos in Gmail and in Apple Mail across the major Apple devices. Several other providers, including some large consumer and business platforms, also support BIMI to varying degrees and on their own timelines, and the list grows over time. What you should not expect is universal coverage on day one across every mail client your recipients use; some clients render no logo at all, and that is normal.
The value is concentrated where attention is concentrated. Gmail and Apple Mail together represent an enormous share of consumer inbox views, so getting those two right is most of the prize. Treat anything beyond them as upside rather than a requirement.
The practical takeaway
BIMI is not a logo setting; it is the visible result of a properly authenticated domain. Gmail and Apple Mail will both reward you with a verified mark, but only after your DMARC policy is enforcing, your mail genuinely passes that policy with aligned DKIM, your logo is a real SVG Tiny PS file, and a Verified Mark Certificate or Common Mark Certificate sits behind the a= tag. Skip any one of those and the logo simply will not appear, usually with no error to tell you why.
So test the whole chain before you rely on it. Run your domain through the BIMI checker, confirm the DMARC prerequisite with the DMARC checker, then send real mail from every stream into Gmail and iCloud test accounts and look with your own eyes. If you would rather not assemble the SVG, the certificate and the enforced policy yourself, the done-for-you BIMI service handles the full path, and ongoing monitoring makes sure the logo that appears today is still there tomorrow.