How do I update my Gmail avatar with a logo after switching from SFMC to Braze?
Updated on 18 Oct 2026: We clarified how to preserve a Gmail BIMI logo during a Braze migration and verify profile-photo settings and authentication.
You do not update the Gmail avatar inside SFMC or Braze. The sender logo Gmail shows is controlled by Google profile data, cached contact data, or BIMI, depending on the recipient, the sending domain, and the type of Gmail surface being viewed. After a move from Salesforce Marketing Cloud to Braze, the practical answer is to authenticate the Braze sending domain correctly, then use BIMI if you want a brand logo to appear for broader Gmail recipients.
Treat this as two separate jobs. First, confirm that the new Braze sending setup passes SPF and DKIM, with DMARC passing for the visible From domain. Second, decide whether you are trying to change a Google Account profile image or implement a verified brand logo. Those paths look similar in the inbox, but they are different systems.
Direct answer
For a marketing sender moving from SFMC to Braze, set up BIMI on the domain used in the visible From address. Gmail requires DMARC at enforcement and a VMC or CMC certificate containing a compliant logo. A Google profile photo can still help for Workspace-to-Gmail cases, but it is not a reliable way to control campaign sender logos from Braze.
- Braze can authenticate and send the mail, but it does not own the Gmail avatar.
- A Google profile photo can show in some Gmail contexts, especially when the sender is a real Workspace mailbox.
- BIMI is the sender-domain path for verified logos in Gmail and other mailbox providers that support it.
Which Gmail image are you trying to change?
The hard part is that people call several different Gmail images an avatar. Before changing DNS or asking Braze support for help, pin down which image is missing. Gmail can show a sender initial, a Google Account photo, a contact image saved by the recipient, or a BIMI logo. Only the BIMI logo is tied to email authentication. A logo in an email signature or SFMC Content Builder is message content and does not set the sender avatar.
|
|
|
|
|---|---|---|---|
Some Gmail and Workspace surfaces | No | Update the Google Account or Workspace profile photo. | |
BIMI logo | Supported inbox brand indicators | No | Publish BIMI after DMARC reaches enforcement. |
Contact photo | Recipient-owned contact cards | No | You cannot centrally update a recipient's saved contact. |
Campaign sending identity | Partly | Use a branded From domain and correct authentication. | |
Previous campaign infrastructure | No | Retire old records only after Braze is stable. |
Common Gmail logo sources and what controls them.
If the issue is an animated profile image rather than a static brand logo, use the animated Gmail picture guidance instead. BIMI logos are static, and Gmail profile images behave differently across Google-owned surfaces.
Google profile photo
This is useful when the sender address is a real Google Workspace account, such as newsletter@example.com with a mailbox. Sign in to that Google Account, open Personal info, choose Profile picture under Basic info, upload the image, crop it, and save it. Check the photo visibility setting for recipients outside your organization.
If Google says "Your profile picture is managed by your organization", an administrator must enable Photo under Directory > Users > More options > Allow users to edit profile. This also applies if you are the only user and administrator. Then update the photo from the sender's Google Account. See Google's profile-editing instructions.
An administrator-uploaded photo is visible within your organization and to external Google Chat contacts. It does not establish a campaign logo for external Gmail recipients. Google explains these profile-photo visibility limits.
- Profile photos apply mainly to Google Account and Gmail contact surfaces.
- Manage the photo in Google, not in Braze or SFMC.
- Profile-photo display is inconsistent for bulk marketing mail.
BIMI logo
This is the domain-based route for verified brand display. It depends on authentication, DNS, certificate status, and mailbox-provider support.
- BIMI supplies brand indicators in supporting mail clients, including Gmail.
- Manage BIMI through DMARC, BIMI DNS, hosted certificate files, and the logo embedded in the certificate.
- Meeting the prerequisites makes the sender eligible; Gmail still controls whether the logo appears.
What changes after the SFMC to Braze move
A platform migration changes the infrastructure behind your mail. It does not automatically change Google's cached sender image or an existing Google Account profile photo. What changes is the sending domain setup, the DKIM keys, the return-path domain, the IP or shared pool behavior, and the reputation history Gmail now sees for the new stream.
Braze sending domain settings showing SPF, DKIM, and DMARC authentication status.
If you changed the visible From domain during the move, Gmail sees a different sender domain. For example, mail.example.com and news.example.com can have different authentication, DMARC reporting, BIMI records, and reputation. Keep the visible From domain stable where you can. When you need a new subdomain, warm it carefully and verify whether it inherits the organizational domain's BIMI record or has its own record.
- The domain after the @ in the visible From address is the identity Gmail users see.
- Braze has its own DKIM setup. Do not assume SFMC keys carry over.
- Bounce handling changes during ESP migration, so test DMARC results after DNS changes.
- Logo display does not replace good sending hygiene, engagement, and complaint control.
Use Braze's migration guide for cutover planning and Google's BIMI requirements for current Gmail logo eligibility. Keep the Gmail avatar decision separate from the ESP migration checklist.
Keep an existing BIMI logo during the migration
Because BIMI is tied to the visible From domain, switching email platforms alone does not require a new logo certificate. Keep an existing BIMI record and PEM URL when the domain and logo are unchanged, the certificate is valid and covers the sender domain, and Braze messages pass DMARC.
- Preserve the existing BIMI record during DNS changes. If SFMC manages a delegated DNS zone, coordinate the replacement zone before removing that delegation.
- For a new From subdomain, check its default._bimi record and the organizational domain fallback. A subdomain BIMI record takes precedence over the organizational record.
- Confirm certificate expiry and domain coverage before reusing a VMC or CMC. Ask the issuer to confirm coverage for a changed sending domain.
- If the brand logo itself changes, get the certificate reissued with the new embedded logo. Replacing a separately hosted SVG does not change the logo inside the PEM.
The BIMI Group's domain guidance explains record inheritance. Compare the existing SFMC message and a new Braze message using the same visible From domain before changing a working BIMI record.
Gmail BIMI requirements for Braze senders
BIMI is the right mechanism when the goal is a brand logo beside marketing mail sent through Braze. Gmail supports BIMI, but it checks more than the logo. Your mail must pass DMARC, the domain's DMARC policy must use quarantine or reject, and Gmail requires a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). A VMC adds the Gmail verified checkmark. A CMC supports logo display without requiring a registered trademark, but it does not add the verified checkmark. See Google's certificate requirements.
BIMI readiness thresholds
Use these states to decide whether logo work should start or whether authentication work comes first.
Not ready
p=none
DMARC exists only for reporting and does not request enforcement.
Authentication review
Sources verified
Legitimate SFMC and Braze sources must pass DMARC before policy enforcement.
BIMI eligible
p=quarantine or reject
DMARC requests enforcement for all affected mail without the historic pct tag.
DMARC passes when SPF or DKIM passes and its authenticated domain matches the visible From domain under the applicable DMARC mode. Both mechanisms do not have to supply that match. For Braze, configure both and verify matching DKIM on the actual message. Relaxed mode permits the same organizational domain; strict mode requires an exact domain match. These rules are defined in RFC 9989.
The order matters. Do not start by uploading a logo, because a perfect SVG still fails when the From domain does not pass DMARC consistently. Check the authentication base first, then add the visual layer. RFC 9989 made pct historic, so new DMARC records should omit it. Under older handling, an omitted pct value already means the policy applies to 100 percent of affected mail. If an existing record still contains pct, do not leave it below 100 for BIMI.
DMARC and BIMI records to aim forDNS
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com Host: default._bimi.example.com Type: TXT Value: v=BIMI1; l=; a=https://e.co/vmc.pem
Replace the example domains, reporting address, and PEM URL with your own values. The empty l= in this certificate-based BIMI example is intentional.
Do not skip enforcement
A monitoring-only DMARC record is not enough for Gmail BIMI. Move carefully, but reach enforcement before expecting Gmail to show the logo.
- Use quarantine or reject, not none.
- Omit the historic pct tag. Without it, older receivers treat the policy as applying to all affected mail.
- Use a VMC or CMC that matches the logo and domain requirements.
Suped's DMARC reporting platform collects DMARC reports during parallel sending. Use reported source IPs and DKIM domains to compare SFMC and Braze traffic and identify domain-matching failures before enforcement. Suped also tracks SPF and DKIM results, so the team can verify the new Braze setup without reading raw aggregate XML.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Prepare a Gmail-compatible BIMI logo
For Gmail, the certificate file is the deployment asset. A VMC or CMC PEM contains the verified logo, and Google's certificate-based BIMI example leaves l= empty while a= points to that PEM file. The logo submitted to the certificate authority still has to meet SVG Tiny Portable/Secure requirements.
- Use SVG Tiny PS with baseProfile set to tiny-ps and version set to 1.2.
- Set absolute width and height values of at least 96 pixels. Do not use percentages.
- Center the logo in a square and use a solid background because transparency can display unpredictably.
- Remove scripts, animation, and external references. Google recommends a file size of 32 KB or less and a desc element for accessibility.
Host the PEM over public HTTPS with a valid TLS certificate. Include the full mark certificate chain supplied by the issuer. Do not put it behind a login, an IP allowlist, or a regional access rule that can block Gmail's fetch. Confirm that the URL returns the certificate file directly before publishing the BIMI record. See Google's file requirements.
Update Braze authentication and publish BIMI
The safest sequence is to migrate the authentication cleanly, prove that Gmail sees the new mail as legitimate, then publish BIMI or validate the existing record. This sequence separates DNS correctness from mailbox-provider display timing.
- Decide the visible From domain Braze will use for campaigns.
- Add Braze's required DNS records for DKIM, bounce handling, and tracking.
- Send real mail and confirm SPF and DKIM pass, with DMARC passing through DKIM that matches the visible From domain.
- Move DMARC to quarantine or reject only after legitimate sources are accounted for. Keep an existing enforcement policy when the Braze setup passes.
- Prepare the BIMI SVG and get a VMC or CMC for Gmail support, or confirm that the existing certificate remains valid for the sending domain.
- Publish or verify the BIMI TXT record for the sender domain and host the PEM over HTTPS.
- Test in Gmail on the web and mobile, then compare Google Workspace and any other mailbox providers your subscribers use. Logo-display rules differ by provider.
Before changing DMARC policy, review the sending domain with Suped's Domain health checker. Check Braze's exact DKIM selector separately and confirm DMARC passes on a real message; a domain-only lookup cannot prove that outgoing mail is correctly signed.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The most common migration mistake is leaving the old SFMC sender setup in place and adding Braze on top without checking the total DNS state. Keep one SPF record per domain. SPF produces permerror when evaluation exceeds its limit of 10 DNS lookup-causing terms, including nested includes, as defined in RFC 7208. DKIM can fail when selectors point to retired infrastructure, and DMARC can report unexpected third-party sources after the first real campaign sends.
Minimal DNS checklisttext
Visible From: newsletter@example.com Braze DKIM: verified for example.com Bounce domain: verified for the Braze stream DMARC: p=quarantine or p=reject after legitimate sources pass BIMI: new or existing record valid under DMARC enforcement
Do not remove the SFMC DNS records until you know that no active mail stream still uses them. That includes transactional jobs, triggered journeys, preference-center messages, and one-off operational sends that were not part of the main migration plan.
Testing in Gmail after the change
Testing has two layers. First, inspect the actual authentication results in the message. Second, check the visual behavior in Gmail over time. Google says a new BIMI logo can take up to 48 hours to appear after the DNS record is added. Gmail also applies its own display checks, so technical eligibility does not guarantee that every message will show the logo. A failing DMARC result does prove the setup needs work.
Send a real Braze test message. In Gmail on the web, open the message menu next to Reply and choose Show original. Check the Authentication-Results added by Gmail for spf=pass, dkim=pass, and dmarc=pass. Compare the DKIM signing domain with the visible From domain. Google explains how to check authentication.
You can also inspect the headers with our Email tester before waiting on Gmail's avatar surfaces. This gives you a faster answer than refreshing the inbox repeatedly.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
How to interpret test results
- If authentication passes, check the BIMI record, certificate validity, public PEM access, and Gmail display behavior.
- If DKIM fails, fix the Braze DKIM selector or DNS target before changing BIMI.
- If DMARC fails, confirm that a passing SPF or DKIM domain matches the visible From domain under its DMARC mode.
- If Gmail shows the old logo, check recipient contacts, cached images, and whether the From domain changed.
Check the DKIM-Signature header for an l= body-length tag. Google's BIMI troubleshooting guidance says external sending systems must not use that tag. Ask Braze support to review the signing configuration if it is present. This DKIM tag is separate from the l= logo field in a BIMI TXT record.
Test with a fresh Gmail account that has never saved your sender as a contact. Then test with a long-time subscriber account. If only the existing account shows an old image, check its saved contact photo and allow for Gmail caching. Compare the same newly sent message in both accounts before changing DNS again.
Also check whether you are sending from a group address, alias, or no-reply identity that has no Google profile photo. A Workspace profile image can help for some person-to-person contexts, but a marketing platform send still needs the domain authentication route.
Where Suped fits into the migration
Suped's product gives the team a shared view of DMARC authentication by source during the cutover. Use it to watch SFMC and Braze in parallel, confirm that each legitimate source passes DMARC for the visible From domain, and catch unexpected senders before moving DMARC to enforcement. Aggregate DMARC reports do not show which avatar Gmail displayed.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Automated issue detection and guided fix steps help route each failure to the DNS owner or Braze administrator who can correct it. Alerts also make it easier to spot an old SFMC stream that resumed after the planned cutover.
- Track SFMC and Braze side by side until the old sources disappear.
- Review DMARC data before moving the domain to quarantine or reject.
- Check the SPF lookup chain when old SFMC and new Braze records overlap.
- Give each failed source a named owner and a cutover decision.
Gmail logo checklist after the migration
Final checklist
- Use the same visible From domain your subscribers recognize.
- Confirm Braze passes SPF and DKIM, with DMARC passing for the visible From domain.
- Publish or preserve BIMI under DMARC enforcement and verify certificate validity.
- Test fresh and existing Gmail accounts to separate contact and cache behavior from configuration issues.
