top of page
Search

A Technical Deep Dive: How BIMI Actually Works Behind the Scenes

BIMI is often presented as a visual feature — a logo appearing in the inbox.



But behind that simple outcome lies a strict technical chain involving DNS, cryptography, authentication alignment, and certificate validation.



This article explains how BIMI actually works, step by step, from the moment an email is sent to the moment a mailbox provider decides whether a logo can be displayed.




1. BIMI in the email authentication stack



BIMI does not replace existing email authentication standards.

It sits on top of them, as an additional trust layer.


At a minimum, BIMI depends on:


  • SPF (Sender Policy Framework)

  • DKIM (DomainKeys Identified Mail)

  • DMARC (Domain-based Message Authentication, Reporting & Conformance)



If any of these fail or are misaligned, BIMI will not activate.


Think of BIMI as the final reward for correct authentication hygiene.



2. Step-by-step: what happens when an email is sent


Let’s follow a BIMI-enabled email from sender to inbox.


Step 1: Email is sent



An email is sent from mail.example.com with:


  • a visible From: header (e.g. @example.com)

  • a DKIM signature

  • a sending IP authorised by SPF



Nothing BIMI-specific happens yet.



Step 2: SPF and DKIM validation


The receiving mail server (e.g. Gmail) checks:


  • SPF: Is the sending IP authorised to send mail for the domain?

  • DKIM: Is the message cryptographically signed, and does the signature validate?


Both checks must pass and align with the From: domain.


Step 3: DMARC evaluation (critical for BIMI)



DMARC ties SPF and DKIM together.


For BIMI eligibility, DMARC must meet three conditions:


  1. SPF or DKIM must pass

  2. Alignment with the From: domain must be correct

  3. The DMARC policy must be set to:

    • p=quarantine or

    • p=reject



Example DMARC record:

_dmarc.example.com IN TXT

"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; adkim=s; aspf=s"


If the policy is p=none, BIMI stops here.

No logo will ever be displayed.



3. BIMI DNS lookup: where the logo lives



If DMARC passes with enforcement, the mailbox provider performs a BIMI DNS lookup.


The lookup is done on:

default._bimi.example.com


A valid BIMI TXT record looks like this:

default._bimi.example.com IN TXT

"v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"



Record components explained:



  • v=BIMI1

    Protocol version (mandatory)

  • l= (location)

    URL of the BIMI-compliant SVG logo

    Must be:


    • HTTPS

    • publicly accessible

    • served with correct MIME type


  • a= (authority)

    URL of the Verified Mark Certificate (VMC) or CMC

    Optional in theory, but required by Gmail for logo display


If the DNS record is missing, malformed, or unreachable, BIMI fails silently.


4. SVG Tiny P/S: why the logo format matters


Mailbox providers will only fetch and render logos in SVG Tiny Portable / Secure (SVG Tiny P/S) format.


This format is intentionally restrictive to prevent:


  • embedded scripts

  • external references

  • tracking elements

  • malicious payloads



Key requirements:


  • square aspect ratio

  • no gradients or filters

  • no external fonts

  • no <script> or <foreignObject> elements


If the SVG does not strictly comply, the logo is rejected.


This is one of the most common failure points in BIMI deployments.


5. Certificate verification: VMC and CMC


When the a= parameter is present, the mailbox provider retrieves the certificate.


Two types exist:



Verified Mark Certificate (VMC)


  • Requires a registered trademark

  • Issued by a trusted Certificate Authority

  • Confirms legal ownership of the logo


Common Mark Certificate (CMC)


  • Allows prior-use logos

  • Lower assurance level

  • Not supported by all mailbox providers


The mailbox provider verifies that:


  1. The certificate is valid and not expired

  2. The logo hash in the certificate matches the SVG served at l=

  3. The domain in the certificate matches the sending domain



If any of these checks fail, the logo is not displayed.


6. Provider-specific logic (important nuance)



Not all mailbox providers implement BIMI in exactly the same way.


Examples:


  • Gmail: requires a VMC for logo display and may show a verified checkmark

  • Yahoo: supports BIMI but may display logos without checkmarks

  • Apple Mail: supports BIMI with different UI placement



The technical validation chain is the same, but the visual outcome differs.


This is why BIMI success should be validated across multiple inboxes.




7. Common technical failure scenarios



From real-world deployments, the most frequent issues are:


  • DMARC still set to p=none

  • SPF misalignment with the From: domain

  • DKIM signing with a subdomain not aligned to DMARC

  • Invalid SVG Tiny P/S formatting

  • BIMI DNS record published on the wrong domain

  • HTTPS certificate issues on logo hosting

  • Expired or mismatched VMC



BIMI is unforgiving by design — but predictable once understood.


8. Testing and validation workflow


Before going live, technical teams should:


  1. Validate SPF, DKIM, and DMARC alignment

  2. Test DMARC enforcement on low-risk traffic

  3. Validate the SVG with a BIMI-compatible validator

  4. Check DNS propagation for the BIMI record

  5. Verify certificate accessibility and expiry

  6. Test delivery in Gmail, Yahoo, and Apple Mail



There is no “partial success” in BIMI — either the chain validates end-to-end, or it doesn’t.


9. Why this complexity is intentional


BIMI’s strictness is not accidental.


It exists to:


  • prevent logo spoofing

  • ensure only legitimate brands gain visual trust

  • align security incentives with user experience



By forcing technical excellence, BIMI raises the baseline for the entire email ecosystem.


10. How Bimimi.io simplifies the process



At Bimimi.io, we abstract this complexity without hiding it.


We help technical teams:


  • audit SPF, DKIM, and DMARC alignment

  • move safely from p=none to enforcement

  • validate and host BIMI-compliant SVG logos

  • obtain and manage VMC or CMC certificates

  • publish and test BIMI DNS records



So your logo appears because the chain is correct, not because of trial and error.


Conclusion: BIMI is deterministic, not magical



BIMI is not a black box.

It is a deterministic system built on DNS, cryptography, and policy enforcement.


When every component is correctly implemented, the result is simple:


  • a verified logo,

  • a trusted sender,

  • and a visible signal of authenticity in the inbox.



Understanding how BIMI works behind the scenes is the key to deploying it reliably — and at scale.



Learn more about technical BIMI implementation at:

 
 
 

Comments

bottom of page