Why is my animated sender logo not showing in Gmail for new subscribers?
Updated on 10 Oct 2026: We added Google profile visibility checks and refined the Gmail recipient tests and BIMI enforcement guidance.
An animated sender logo in Gmail is a Google profile-picture behavior, not a BIMI logo. When new recipients see a default avatar while existing recipients still see the GIF, check profile visibility, cached account data, and saved contact images. Gmail controls which sender image appears and does not provide a sender-side setting that guarantees animation.
That makes this a Gmail avatar and recipient-state issue first, then a BIMI and authentication issue second. DMARC monitoring shows authentication patterns by sending source and visible From domain. Check the individual message's received headers to verify its DMARC result.
For BIMI logo eligibility, use authenticated mail, a static BIMI SVG, and a stable From identity. Treat animation as an undocumented Gmail behavior. It can remain visible for some existing recipients, but senders cannot guarantee it for every new subscriber.
Why Gmail differs by recipient history
When an existing Gmail recipient sees animation but a first-time recipient does not, test Gmail's profile lookup and recipient state before changing DNS. Google documents that a Gmail profile picture is the Google Account picture and that changes can take time to appear across Google products. A recipient can also retain an older picture or name in saved contacts. These are diagnostic possibilities, not proof of a Gmail rule for new subscribers.
- New subscribers: A fresh inbox shows how Gmail handles the sender without prior message history or a saved contact.
- Existing subscribers: They can retain an older profile picture because account data and saved contacts do not update every view at once.
- Confirmation emails: Compare their exact From address and authentication results with the newsletter; a different sending stream alone does not establish the cause of an avatar change.
- Gmail behavior: The Gmail interface decides what to show, and email headers or DNS cannot require an animated avatar.
Do not treat animation as a supported requirement
BIMI logos are not animated GIFs. Profile visibility, saved contacts, and cached account data are checks to investigate when Gmail sender avatars differ. A GIF that still animates for one recipient does not prove that new subscribers will see the same result.
Gmail profile avatar versus BIMI
Two logo paths often get mixed together. A Google Account picture can appear next to messages sent to Gmail users, and this is where observed GIF behavior comes from. Brand Indicators for Message Identification (BIMI) uses DNS to let supporting mailbox providers consider a verified brand logo for authenticated mail. BIMI animation limits matter here because BIMI requires static SVG artwork and excludes animation.
Google profile avatar
- Source: The Google Account picture associated with the exact sender address.
- Format: Some senders have observed animated GIF profile pictures in Gmail inbox rows.
- Control: Sender control is limited because Gmail decides when to fetch and display it.
- Risk: Recipient history and saved contacts can produce different results.
BIMI logo
- Source: A DNS TXT record at the BIMI selector for the From domain.
- Format: A static SVG Tiny PS logo with no scripts, animation, or external references.
- Control: The domain publishes the assertion, but Gmail still decides whether to display it.
- Risk: Gmail suppresses logos when authentication, certificate, hosting, or artwork requirements fail.
Gmail sender icons showing a generic avatar and a branded logo.
That distinction changes the fix. A Google profile GIF is not repaired with another DNS tag. Keep the sender identity stable and stop depending on animation. A BIMI failure requires checks of DMARC enforcement, SPF or DKIM domain matching, BIMI DNS, SVG formatting, certificate status, and public file hosting. A website favicon or a logo in the email body or signature does not set Gmail's built-in sender icon.
What Gmail requires for BIMI
Gmail requires a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC), plus DMARC enforcement and correctly hosted BIMI files. A VMC is tied to a verified trademark and can produce Gmail's verified checkmark. A CMC provides a path for an eligible logo that is not a registered trademark, but it does not produce that checkmark. See Google's BIMI setup requirements.
- Enforcement policy: Use p=quarantine or p=reject for the organizational domain and its subdomains; avoid sp=none. Keep t unset or t=n rather than requesting test handling.
- DMARC pass: Each message needs a passing DKIM signature or SPF result whose domain matches the visible From domain under DMARC rules.
- Mark certificate: Host a current, unrevoked VMC or CMC in a complete PEM chain at a public HTTPS URL and publish that URL in the BIMI a tag. Check that the file loads without login.
- Static artwork: Use SVG Tiny PS with absolute dimensions of at least 96 by 96 pixels. Center the logo in a square; a solid background and a file no larger than 32 KB are Gmail compatibility recommendations.
- Display decision: Meeting the requirements makes the message eligible. Google says a logo can take up to 48 hours to appear after publishing the BIMI record, but that is not a guarantee of display for every recipient.
DMARC enforcement and legacy pct settings
RFC 9989 replaced RFC 7489 and made pct historic. Omit pct from new records, and leave testing disabled with t unset or t=n. Gmail's published BIMI guidance still specifies pct=100; if an older record includes pct, do not use a value below 100. Omitting it also means 100 under legacy DMARC rules. The policy version remains v=DMARC1. Apply enforcement to the organizational domain and subdomains as described in the BIMI implementation requirements.
Diagnose missing Gmail sender logos
Split recipients into fresh Gmail inboxes and inboxes that already received mail from the exact sender. If only fresh recipients miss the animated logo, that is a reason to investigate profile visibility, saved contact data, or cached account data. It does not prove the cause or show that the sending platform removed an email asset.
Gmail sender logo lookup with profile caching and BIMI authentication checks.
|
|
|
|---|---|---|
Possible cached avatar | Existing recipients see it, first-time recipients do not | Retest with fresh Gmail inboxes |
Saved contact | One recipient sees an old or custom image | Retest without a saved contact |
From changes | Confirmation and campaign differ | Use one sender identity |
Profile mismatch | Generic avatar appears | Check the exact Google Account |
Profile visibility | Internal recipients see a photo, external recipients see initials | Check photo audience and Workspace profile settings |
Gmail client or display area | A picture appears in a contact card but not the sender icon | Compare the same view in Gmail web and the Gmail app |
BIMI gap | No BIMI brand logo | Validate DMARC, BIMI, and the certificate |
Authentication gap | No BIMI logo on messages that fail DMARC | Fix SPF or DKIM domain matching |
Checks when new Gmail subscribers see a different sender logo.
Compare a consumer Gmail account with a Google Workspace inbox as a separate variable. Workspace directory data can supply an internal profile image that an external Gmail recipient does not have, so internal logo display does not prove that BIMI works externally.
Check Google profile visibility and Workspace settings
A photo visible to coworkers is not proof that a new external subscriber can see it. Google's Workspace photo guidance says an administrator-added photo is visible to the organization and external Google Chat contacts. Users who change their own photo can choose its audience. The Admin console accepts JPEG or PNG profile photos.
- Open the Google Account associated with the visible From address, then Personal info > Profile picture. Confirm the intended image there; a mailing-platform account photo does not configure Gmail's sender icon.
- Under Personal info > Your profiles > See profiles > Profile discovery settings, review whether the photo is shown to people who have not interacted with the account. If a photo audience control is available, choose Anyone for external testing.
- For Google Workspace, have the administrator review Directory > Users > More options > Allow users to edit profile. Photo and Profile Discovery permissions control whether the sender can edit these settings.
- Test sender aliases separately. Confirm the actual From address in the received message instead of assuming that an alias has the same external avatar as the primary account.
Google's profile discovery guidance explains why photo visibility can differ before and after interaction. Workspace profile editing is controlled by the administrator, and Profile Discovery editing is unavailable for Workspace for Education. These settings affect photo visibility; they do not promise GIF playback.
Test new and existing Gmail recipients
Keep the test controlled. Use one From address, one sending domain, and a consistent subject pattern across at least two recipient groups. One group has never received the sender and has no saved contact. The other group has a known history with the sender. Send a confirmation-style message and a normal newsletter message, then compare the sender icon in the Gmail message list. Keep the Gmail client and display area consistent: compare the inbox sender icon separately from the opened message, hover card, or contact card. Repeat in Gmail web and the Gmail app as separate tests.
- Fresh inboxes: Use Gmail accounts that have never received mail from the sender and do not have it in contacts.
- Known inboxes: Use Gmail accounts that previously displayed the animated avatar.
- Stable From: Do not change the username, display name, or domain during the test.
- Separate streams: Test confirmation messages and campaign messages independently.
- Record results: Capture the sender icon, recipient history with the sender, contact state, Gmail client and version, display area, and authentication results. In Gmail web, open the message, then More next to Reply > Show original. Compare SPF, DKIM, and DMARC results and the authenticated domains with the visible From domain.
Recipient test matrixtext
Recipient group: fresh Gmail Message type: confirmation Contact saved: no Record: avatar type, Gmail client, display area, and authentication results Recipient group: fresh Gmail Message type: newsletter Contact saved: no Record: avatar type, Gmail client, display area, and authentication results Recipient group: known Gmail Message type: newsletter Contact saved: record yes or no Record: avatar type, Gmail client, display area, and authentication results Recipient group: known Gmail Message type: confirmation Contact saved: record yes or no Record: avatar type, Gmail client, display area, and authentication results
If fresh Gmail inboxes do not show animation while known inboxes still do, investigate profile visibility, contacts, and cached account data. This test narrows the possibilities without proving which Gmail mechanism caused the difference. If neither group shows animation, verify that the sender's Google Account still has the intended picture, then use a static logo fallback.
What Google documents
Google says a Gmail profile picture is the Google Account picture, can appear next to sent messages, and can take time to update across Google products. Its profile-picture guidance does not promise GIF animation or consistent display in every sender icon. Its message-header instructions explain where to find Show original for the authentication comparison.
Check DMARC and BIMI records
After the recipient-state test, check email authentication. Gmail's BIMI path requires DMARC enforcement and a message that passes DMARC through DKIM or SPF domain matching. The BIMI record then needs valid static artwork and a current VMC or CMC hosted in a complete PEM chain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Example DMARC recorddns
Name: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com;
Example BIMI recorddns
Name: default._bimi.example.com Type: TXT Value: v=BIMI1; l=https://example.com/bimi.svg; a=https://example.com/vmc.pem
Publish the BIMI value as one TXT record and replace the example URLs with your public SVG and certificate files. Check BIMI lookup and certificate coverage for the actual visible From domain, including newsletter subdomains. Confirm that the PEM chain and any referenced SVG remain accessible over HTTPS. Google's BIMI troubleshooting guidance also advises against the DKIM body-length tag l=; it is separate from the BIMI l= logo URL.
After DNS changes, check the DMARC record separately with a DMARC checker because one syntax mistake can invalidate the record. For the broader logo setup, follow the BIMI setup path as a static brand-logo program rather than an animated avatar project.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Authentication is a prerequisite for BIMI eligibility, but it does not force Gmail to render a GIF or any logo. Test authentication and the recipient's displayed sender icon separately.
Monitor the parts you control with Suped
Suped is our DMARC reporting and email authentication platform. Use it to review DMARC policy, SPF and DKIM results, and sending sources while diagnosing missing Gmail sender logos.
The Suped workflow
- Find failures: Use automated issue detection to spot broken DMARC, SPF, and DKIM patterns.
- Map sources: Map each sending source to its expected From domain, then test newsletter and confirmation messages separately in Gmail.
- Stage policy: Use Hosted DMARC to manage enforcement changes without repeated manual DNS edits.
- Watch changes: Use alerts to catch new authentication failures or undocumented sending sources.
Use Suped's aggregate reports to compare sending sources and DMARC results before changing policy. Aggregate reports do not contain the recipient's displayed avatar or subscriber history, so pair them with the Gmail screenshots and headers collected in the test.
Avoid changes that obscure the cause
Changing several sender variables at once makes this harder to diagnose. Gmail avatar behavior already depends on recipient state and interface decisions. Keep the mail stream stable, change one item at a time, and avoid fixes that weaken authentication while chasing a visual result.
Common mistakes
- Rotating senders: Changing usernames or domains creates a different Gmail sender identity.
- Forcing GIFs: BIMI does not provide an animated GIF logo path in Gmail.
- Ignoring DNS: p=none does not meet Gmail's BIMI enforcement requirement. Avoid reduced legacy pct settings and leave testing disabled for a BIMI deployment.
- Overreading one test: One Gmail inbox does not show how fresh recipients, saved contacts, and Workspace directory users behave.
Keep the Google Account picture current and the mail stream stable while testing. For BIMI, use static artwork and DMARC enforcement, then confirm the result in the recipient's Gmail client.
Views from the trenches
The following Email Geeks reports describe individual tests in December 2024. They do not establish a current Gmail rollout or a rule that first messages never show a profile picture.
Best practices
Test first-time Gmail recipients separately to compare sender history with cached avatar data.
Keep the same From address and domain while checking profile images, BIMI, and DNS state.
Use a static BIMI SVG for logo eligibility; animation is not guaranteed for new recipients.
Common pitfalls
Assuming one Gmail inbox proves the cause overlooks contacts, photo visibility, and client views.
Changing the sending username during tests adds a variable to Gmail's profile image lookup.
Expecting BIMI to animate wastes time because mailbox logos are based on static artwork.
Expert tips
Send a confirmation and a normal campaign to each test inbox and compare the avatar state.
Record screenshots by sender history and Gmail client so display differences stay traceable.
Check DMARC results and the visible From domain before investigating missing BIMI sender logos.
Marketer view
Marketer from Email Geeks says Google Workspace recipients can still see the animated sender logo when the profile image was already known.
2024-12-13 - Email Geeks
Marketer view
Marketer from Email Geeks says a fresh signup can show the default Gmail avatar on the confirmation email and the animated logo on the later newsletter.
2024-12-13 - Email Geeks
Choose a static fallback for new subscribers
Keep the From address stable and confirm the exact Google Account picture and photo visibility. Use a recognizable static first frame in any profile GIF so the logo remains legible if Gmail displays a still image. For Gmail's BIMI path, use a static SVG and a VMC or CMC, then retest the same messages with fresh recipients after each change.
Frequently asked questions
The dated reports above describe animated Google Account pictures for some senders and recipients, but Google does not document guaranteed GIF playback in Gmail's sender icon. New subscribers can see a default or static avatar even when existing recipients still see animation.
No. BIMI uses static SVG Tiny PS artwork and excludes animations. Gmail also requires a VMC or CMC, so logo eligibility requires compliant artwork and correct authentication.
Compare the exact From address and authentication results with the newsletter, then check the recipient's contact state and Gmail view. BIMI uses the From domain, so check that domain and its certificate coverage rather than assuming a display-name change explains the logo.
No. DMARC evaluates authentication and domain matching; it does not control Gmail's animated avatars. DMARC enforcement is a requirement for BIMI, which uses a static logo.
Check the exact Google Account picture and its visibility, then compare a first-time Gmail recipient with no saved contact against a known recipient. Use the same From address, domain, Gmail client, and display area, then record the sender icon and received authentication results.
