How do I update my Gmail avatar with a logo after switching from SFMC to Braze?
Michael Ko
Co-founder & CEO, Suped
Published 20 Apr 2025
Updated 15 May 2026
11 min read
The short answer: switching from SFMC to Braze does not give you a Gmail avatar setting to update inside Braze. If you mean the profile image attached to a Google Workspace mailbox, update the Google Account profile picture. If you mean the logo that appears beside marketing emails in recipients' Gmail inboxes, set up BIMI on the sending domain and make sure DMARC, SPF, and DKIM pass correctly for mail sent through Braze.
I split this problem into two separate jobs because Gmail uses more than one source for sender images. A Google Account profile photo can help with Gmail-to-Gmail or Workspace mail. A verified brand logo for broad marketing email display depends on authentication, DNS, and Gmail's BIMI handling. The SFMC-to-Braze move mostly affects the second job, because your authenticated sending source changed.
The older Google+ era workaround is gone. Google now documents profile pictures as Google Account images, and its Gmail profile picture help page says changes can take up to 24 hours. That path is useful for a mailbox avatar. It is not the same as getting your logo to show reliably on high-volume Braze campaigns.
The direct answer
What to update
Update the Google Account image only when the sender is an actual Google mailbox. For Braze marketing mail, update the authenticated sending setup and BIMI DNS records for the visible From domain. The logo is not controlled by SFMC or Braze after the message reaches Gmail.
Mailbox avatar: Use the Google Account or Workspace profile picture controls.
Marketing logo: Use BIMI, a valid mark certificate path, and passing domain authentication.
Migration task: Replace SFMC authentication assumptions with Braze's current sending-domain DNS.
Testing rule: Send a real message to Gmail and inspect the authentication results.
The practical order is simple. First, confirm which address appears in the From header in Braze. Second, make sure Braze has authenticated that domain with DKIM and the required bounce or return-path setup. Third, confirm your DMARC policy is at p=quarantine or p=reject. Fourth, publish the BIMI record that points to the correct logo certificate file. Then wait for DNS and Gmail caching before judging the result.
Braze has written about Gmail verified logos, and the important point for a migration is that the logo work sits on top of DMARC, SPF, and DKIM. Braze can send the email, but Gmail decides whether to show the logo.
Google profile picture
Best for: A person or shared mailbox sending through Google.
Scope: Mostly Google account surfaces and some Gmail recipient views.
Control point: Google Account or Google Workspace profile settings.
BIMI brand logo
Best for: Marketing mail from Braze, SFMC, or another email platform.
Scope: Mailbox providers that support BIMI and accept your certificate.
Control point: DNS, DMARC policy, logo certificate, and sending authentication.
Why the SFMC to Braze move matters
Moving from Salesforce Marketing Cloud to Braze changes the mail infrastructure behind your campaigns. Your visible From address can stay the same, but the DKIM signature, bounce domain, sending IPs, and DNS records change. Gmail will not care that the brand name stayed the same if the new mail stream fails authentication or no longer passes DMARC domain matching.
The most common mistake is looking for an avatar upload inside Braze. That makes sense if you remember the old account-photo model, but it misses how Gmail treats high-volume brand email now. A Braze migration has a real deliverability checklist, and the logo is downstream of that checklist.
Braze sending-domain settings showing authentication records for email setup.
In Braze, confirm the exact sending domain you are using for campaigns, journeys, transactional messages, and any regional subaccounts. If the brand sends from news.example.com but BIMI sits only on example.com, you need to understand which organizational domain Gmail evaluates. If Braze signs DKIM with a platform-owned domain instead of your domain, DMARC can fail even when SPF or DKIM technically passes.
This is also a good moment to read Braze's migration guidance because sending-domain work should be treated as part of the migration, not as a cosmetic task after launch.
The logo decision tree
Decision path for Gmail profile photos and BIMI logos after moving to Braze.
If the sender address is a Google Workspace mailbox, update the account image first. That is the fast path and it is worth doing for sales, support, founder, and shared inbox mail. The limitation is scope: contacts, recipient settings, Gmail caching, and the sending route can affect what people see.
If the sender address is a marketing From address used in Braze, treat the logo as a BIMI project. Gmail currently expects strong authentication and a certificate path for BIMI display. A VMC is used for registered trademarks. A CMC can cover some non-registered marks where the issuer accepts proof of use. Gmail's checkmark behavior differs by certificate type, so do not assume every BIMI display gets the same visual treatment.
Goal
Where to act
What changes
Google mailbox
Google Account
Profile image
Braze campaign
DNS and Braze
Auth and BIMI
Old SFMC setup
DNS audit
Retire records
Logo proof
Certificate issuer
VMC or CMC
Use this table to decide which path to run first.
For a deeper setup checklist, use a dedicated BIMI implementation guide after the Braze authentication records are passing.
Step-by-step setup after moving to Braze
I use this order because it prevents a lot of false debugging. If DMARC fails, the BIMI record does not matter. If DKIM signs with the wrong domain, the logo certificate does not fix that. If the logo file is wrong, a perfect DMARC policy still will not make Gmail show it.
List senders: Export every Braze From address, reply-to address, sending domain, and subdomain.
Verify DKIM: Publish the Braze-provided DKIM records and confirm the signing domain matches your brand domain.
Verify SPF: Make sure the envelope sender or return-path domain is authorized for the new Braze mail stream.
Set DMARC: Move the relevant organizational domain to p=quarantine or p=reject when legitimate sources are passing.
Prepare logo: Create a square SVG Tiny PS logo that meets the certificate issuer and Gmail requirements.
Publish BIMI: Add the BIMI TXT record on the correct selector, usually default.
Test Gmail: Send a production-like email and inspect the Gmail original message headers.
Do not jump straight to p=reject because a logo project has momentum. First, inspect DMARC reports until the Braze stream, Google Workspace stream, transactional mail, and support systems are visible and passing. Suped's DMARC monitoring workflow is useful here because it groups sources, flags authentication issues, and gives steps to fix them instead of leaving you with raw XML.
For Gmail, plan around the certificate file. A standalone logo URL can be useful for some BIMI checks, but Gmail and several other mailbox clients expect the certificate-backed path. If your brand does not have a registered trademark, read the current issuer requirements for CMC eligibility before spending time on a VMC path. The related question of whether you need a VMC for Gmail depends on the logo proof you can provide and the visual treatment you need.
Authentication checks before you chase the avatar
The fastest way to waste a week is to refresh Gmail waiting for a logo when the message is failing DMARC. Check the boring parts first. A Gmail avatar problem after an ESP migration is often a domain-authentication problem with a visual symptom.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Start with a full domain health check for the From domain and the subdomains Braze uses. You want to know whether the visible From domain has a valid DMARC record, whether SPF is near the lookup limit, and whether DKIM records exist for the selectors Braze actually uses.
Do not assume old SFMC records help
SFMC records that authenticated the old mail stream do not authenticate Braze mail. Leaving unused includes, old DKIM selectors, and retired bounce domains in DNS can also make audits harder.
SPF risk: Old includes can push you past the 10 DNS lookup limit.
DKIM risk: A passing DKIM signature from the wrong domain does not satisfy DMARC.
BIMI risk: A valid logo record still fails the Gmail display test when DMARC is weak.
When DKIM is the likely issue, use a focused DKIM checker on each selector. Braze often gives specific selector records during sender-domain setup. A selector typo can make the record look present in your notes but absent to receivers.
BIMI readiness thresholds
Use these thresholds to decide whether to keep testing the logo or fix authentication first.
Ready
p=quarantine or reject
Authenticated Braze mail passes DMARC under an enforcement policy.
Needs staging
p=none or mixed
Sources are visible but some legitimate streams still fail.
Blocked
DMARC fail
Braze mail fails DKIM or SPF domain matching.
Unknown
No data
No aggregate reports or test headers have been reviewed.
How to test what Gmail is seeing
Test with a real Braze send, not only a design preview. The message needs to leave through the same infrastructure, with the same From domain and headers, that your subscribers receive. Gmail's message details and original headers tell you whether SPF, DKIM, and DMARC passed.
Use Suped's public email tester when you need a fast, human-readable report from a live message. Send the Braze test to the generated address, then compare the report with what Gmail shows in the original message view.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After the technical pass is clean, test the display over time. Gmail caches sender images and does not guarantee immediate logo refreshes. A 24-hour wait is normal for account profile pictures, and BIMI changes can also lag because DNS, certificates, and mailbox-provider caching are involved.
Use fresh mail: Old messages often keep old visual treatment and are bad proof.
Check contacts: Recipient contact photos can override what the sender expects to see.
Compare accounts: Test personal Gmail, Workspace Gmail, and mobile Gmail separately.
Save headers: Keep the Gmail original message output for before-and-after proof.
If the logo shows in Yahoo but not Gmail, treat that as a Gmail-specific BIMI requirement issue, usually certificate related. If it shows in one Gmail account but not another, check contacts, cached images, Workspace policies, and whether the message was routed the same way.
Where Suped fits
Suped is the practical DMARC platform for this job because the logo question depends on several moving parts that live outside Braze. Suped brings DMARC, SPF, DKIM monitoring, hosted DMARC, hosted SPF, SPF flattening, blocklist (blacklist) monitoring, and deliverability checks into one workflow. That matters during a migration because you need to know which sender broke, not only that a logo did not appear.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For most teams, Suped is the best overall choice when Gmail logo display is part of a broader authentication project. Record parsing is only one part of the job. Suped detects issues, shows the sources involved, gives steps to fix them, and can alert you when failures spike after a platform change.
Manual DNS checking
Good for: One-time record confirmation before a launch.
Weak spot: It misses changing source behavior after the migration.
Team burden: Someone has to read headers, XML reports, and DNS manually.
Suped workflow
Good for: Ongoing migration monitoring across domains and senders.
Strong point: It connects failures to sources and gives fix steps.
Team fit: MSPs and multi-brand teams can manage many domains in one place.
The other useful part is after launch. A logo that works on Monday can disappear after a sender change, broken DNS edit, certificate update, or new subdomain. Real-time alerts and weekly summaries turn that into an operations task instead of a visual mystery.
Common causes when the logo still does not show
If everything looks correct and Gmail still shows initials, work through causes in this order. The order matters because the first failures are objective, and the later ones depend on Gmail display behavior.
Symptom
Likely cause
Fix
DMARC fail
DKIM mismatch
Fix sender DNS
No checkmark
CMC path
Confirm certificate
Old image
Gmail cache
Wait and retest
One user only
Contact photo
Test clean inbox
Yahoo works
Gmail rules
Check VMC or CMC
Most logo-display failures come from authentication, certificate, or cache issues.
Do not overlook reputation. BIMI is not an inbox-placement tool, but Gmail can still choose not to show a brand image in some situations. Authentication is the gate. Recipient-side display behavior is the final decision. If your migration also changed volume, cadence, or complaint rates, fix those issues alongside the logo setup.
If you need a wider sender-logo primer, the sender logos guide covers Gmail and Yahoo differences in more detail.
Views from the trenches
Best practices
Separate Google profile images from BIMI so each team fixes the correct control point.
Test Braze mail with the same From domain and routing used for real subscribers.
Move DMARC to enforcement only after all legitimate senders are visible and passing.
Keep header samples before and after migration so logo issues have clear evidence.
Common pitfalls
Treating Braze as the place to upload a Gmail avatar delays the real DNS work and tests.
Leaving SFMC SPF includes in DNS can hide lookup-limit problems during migration testing.
Assuming Yahoo BIMI behavior means Gmail will show the same logo creates confusion.
Judging results from old inbox messages misses Gmail caching and contact overrides.
Expert tips
Use a clean Gmail inbox for display tests, then compare it with a known contact view.
Confirm DKIM domain matching before paying for logo certificate work or SVG edits.
Document the exact selector and From domain used by each Braze message stream early.
Monitor DMARC reports for several days after launch before calling the setup stable.
Marketer from Email Geeks says the old Google+ avatar route is gone, so teams should treat new Gmail brand-logo work as a BIMI and authentication project.
2024-02-13 - Email Geeks
Marketer from Email Geeks says Google Workspace profile images can still help for mailbox-to-mailbox use, but they do not reliably control bulk marketing sender logos.
2024-06-21 - Email Geeks
What to do next
If this is a Google mailbox avatar, update the Google Account picture and wait up to 24 hours. If this is a Braze marketing sender logo, do not spend time searching for a hidden avatar setting. Confirm Braze authentication, move DMARC to enforcement when the data supports it, publish BIMI with the correct certificate path, then test with fresh Gmail messages.
Suped is useful when the migration has more than one domain, sender, or team involved. It gives you the DMARC reporting view, SPF and DKIM diagnostics, hosted options for DNS-heavy records, and alerts when a new source starts failing. That is the difference between guessing why Gmail kept the initials and knowing which part of the chain failed.
Working checklist
Profile photo: Use Google settings for real Google mailboxes.
Braze mail: Authenticate the sending domain and verify DMARC pass.
BIMI logo: Publish the selector record and use a valid VMC or CMC path.
Final proof: Test fresh Gmail deliveries after DNS and image caches have time to settle.
Google mailbox
Braze campaign
Old SFMC setup
