Blog

Getting your face into people’s inboxes

Aleksej DixBy Aleksej Dix··8 min read

You set up BIMI, the logo shows up next to your domain in Yahoo and maybe in Gmail. Now look at the mail you send as a human. The photo next to your name is sometimes present, sometimes not, and no single setting controls it. That is because the photo next to a human sender is not BIMI. It comes from five separate mechanisms that no standards body owns, and several of them raise questions under European data protection law. This is the real map.

The map

One table, five clients. Each column says who picks the photo and what the privacy shape of the call is.

ClientMechanismWho sets the photoPrivacy shape
GmailGoogle Account profile photoThe account holder (must toggle visibility to Anyone)Server-side, EU to US, DPF-covered
Apple MailLocal Contacts → Branded Mail → BIMI → monogramRecipient’s Contacts, or sender via Apple Business Connect or BIMILocal or server-side depending on tier
Outlook / M365Contacts → Exchange / Entra ID photoRecipient’s Contacts or sender’s IT adminIntra-tenant only, no external data flow
FastmailGravatarEmail address owner via gravatar.comClient sends hash of recipient’s email to US, ePrivacy open question
Proton MailServer-side favicon proxySender’s domain faviconServer-side, anonymized, recipient IP hidden
Yahoo MailStylized initials + BIMI if presentYahoo for initials, sender for BIMIServer-side BIMI, no third-party call for initials

The Gmail Workspace visibility trap

Worth calling out because it burns every Workspace team eventually. Google Account profile photos default to a visibility of Your organization and People you interact with. External Gmail recipients who never chatted with the sender in Google Chat are neither. They see nothing. The user, not the admin, has to set visibility to Anyone in Google Account → About me (Google Help). Admins cannot enforce this centrally. If your team uploaded headshots and your face is not showing up in customer inboxes, this is almost always why.

Apple Business Connect Branded Mail, in passing

Apple shipped a non-BIMI verified-logo mechanism with iOS 18.2 on 11 December 2024. It is domain-level like BIMI, not personal, so it does not solve what this post is about. It is worth knowing because many teams confuse it with BIMI and because it avoids the VMC cost and trademark prerequisite. The BIMI academy article covers it in detail.

Gravatar: old, niche in mail, load-bearing in dev tools

Gravatar was founded in 2007 and acquired by Automattic later that year. It is ubiquitous in developer tooling (GitHub, WordPress, Slack, OpenAI, phpBB). In mail clients specifically, Fastmail is the only major provider that uses it for inbox avatars. The lookup key was originally MD5 of the lowercased email, now SHA-256. Both remain brute-forceable for common formats. In October 2020, 167 million records were scraped and 114 million MD5 hashes cracked back into emails (Have I Been Pwned).

Register one if you also want coverage across developer surfaces. Know what you are signing up for, which the compliance section covers next.

The trust-versus-law tension

These mechanisms exist because recipients want to see who mail is from. Several of them also move personal data in ways that European frameworks specifically disallow. Three paragraphs, three ideas.

Hashing is not anonymization. GDPR Article 4(5) and Recital 26 classify hashed identifiers as pseudonymized data, still personal data, still in scope. Gravatar’s 2007-era design treats the hash as anonymization. The 2020 scrape empirically demonstrates that it is not: 114 million hashes went back to plaintext emails. Any avatar mechanism keyed on a hash of the recipient’s address is moving personal data, period.

Recipient-side third-party calls are the shape European frameworks punish. The problem is not the lookup. It is that the lookup originates on the recipient’s client, telling a third party about the sender-recipient pair on every render. ePrivacy Directive Article 5(3) treats storage and access on user terminals as a consent question close in spirit to cookies. Cross-border transfers to US services layer on an Schrems II analysis, which since July 2023 is simplified for DPF-participating US recipients (Google, Microsoft, Automattic all listed). Neither Directive nor Framework makes the client-side call disappear, they just attach legal mechanisms to it. A sender who chose Gravatar did not engineer the flow but chose a system that produces it.

Server-side lookups are the architectural answer. The three mechanisms that are compliance-friendly by design all share one trait: the heavy work happens on the server, not the recipient’s client. Proton’s favicon proxy fetches server-to-server. Apple Business Connect Branded Mail keys on the sending domain, not the recipient. BIMI itself is a DNS lookup plus an HTTPS fetch by the mail server, with zero per-recipient data flow. Swiss revDSG (effective 1 September 2023) rewards the same pattern. NIS2 (transposition deadline 17 October 2024) actively pushes essential entities toward DMARC enforcement, which in turn makes BIMI and Branded Mail the practical trust-signal stack. Compliance is not only a brake here; in one direction it pushes the right way.

The practical stack

No single action covers every inbox. Four layers, roughly thirty minutes each.

  1. Google Account photo with visibility set to Anyone. Covers Gmail-to-Gmail and Workspace-to-Gmail. Highest single-action ROI.
  2. Microsoft 365 profile photo. Covers Outlook inside your tenant and across federated tenants. Secondary unless your recipients are enterprise.
  3. Gravatar. Covers Fastmail and developer surfaces (GitHub, WordPress, Stack Overflow). Accept the privacy tradeoff.
  4. vCard with embedded photo on first contact. The only reliable way into Apple Mail and Outlook local Contacts photo slots.

For a business domain, layer BIMI and Apple Business Connect Branded Mail on top, which is a different problem covered in the academy article.

Two unresolved questions

  • Does any mailbox provider honor the BIMI avp=personal tag in production? A live test with a BIMI-enabled domain sending into Gmail, Yahoo, Apple Mail, and Fastmail would answer this empirically.
  • What does Yahoo Mail actually do for per-sender avatars beyond initials and BIMI? Yahoo’s public documentation is silent on the rest of the chain.

If you have not set up BIMI for your domain yet, the academy article walks the SVG, the DNS record, and the DMARC prerequisite. Or scan your domain and see which of the six email trust signals (DMARC, SPF, DKIM, BIMI, MTA-STS, provider) Sudory is already reading.

FAQ

Does BIMI show my personal photo next to my name in Gmail?

No. BIMI is domain-level, one logo per sending domain. The photo Gmail shows next to a human sender comes from a separate system, the sender’s Google Account profile picture. The active BIMI Internet-Draft adds an avp=personal preference tag in revision 12, but no major mailbox provider honors it in production as of 2026.

Is Gravatar a problem under GDPR?

It raises questions. The lookup sends a SHA-256 (historically MD5) hash of the recipient’s email address to a US service. Under GDPR Article 4(5) and Recital 26 a hashed identifier is pseudonymized data, still personal data. The 2020 Gravatar scrape cracked 114 million MD5 hashes back into addresses, which is the empirical case that hashing is not anonymization. The cross-border transfer leg is covered if the US receiver is a Data Privacy Framework participant (Automattic is listed). The ePrivacy Directive consent question is separate and unresolved in European case law.

Which avatar mechanisms are compliance-friendly by design?

Three. Proton Mail fetches favicons through an anonymizing server-side proxy. Apple Business Connect Branded Mail uses a server-side logo lookup keyed to the sending domain. BIMI itself performs a DNS lookup and a server-side HTTPS fetch by the mail server. The common trait is that the heavy lifting happens on the server, not the recipient’s client. The client never makes a per-sender call to a third party. That is the architectural pattern European frameworks reward.

Aleksej Dix
Aleksej DixFounder of Sudory

Founder of Sudory. Frontend engineer based in Zurich with 20+ years shipping production web apps; now building continuous compliance scanning and writing about the DNS and email-auth controls behind it. Co-founder of WebZurich.