#Email Deliverbility20 personnes en discutent

It is important to disctinguish between bounce rates (hard/soft)  - which is specific to a send, and held status, which is specific to a subscriber. Are you referring to bounce rates on your latest sends? And if so - are these soft bounces? 

If you query Bounce data view, you will be able to see additional details about the bounces, and why they have occurred. If the bounce rates have spiked recently, it might be a deliverability issue - but without additional information, than what is in your original post, it is hard to tell.

@Vincent Laplanche This is a common challenge for businesses working with large files, especially when those files need to be shared through a public-facing Experience Cloud site. 

One approach is to offload the files to a system built specifically for document storage and security. Instead of storing and delivering the files through Salesforce, you can keep them in SharePoint while Salesforce continues to manage the customer and business data. 

Customers can log in to Experience Cloud and access the appropriate SharePoint files through secure links and controlled permissions. These links can be locked down, so only the required permissions are given to those who need it, instead of the public links you are experiencing currently. 

sFiles connects Salesforce and SharePoint for exactly this type of use case. It supports file uploads, links, and access directly within Experience Cloud, so the files remain available to both your internal Salesforce users and external customers without being stored in Salesforce. 

An additional benefit is reduced Salesforce file-storage usage, which can become very expensive when large files are uploaded regularly. 

@Taylor Thomas

Good that rules out the most common silent failure cause, so this now points toward reputation/engagement rather than authentication. With 65k/123k on Gmail, you're well past the bulk sender threshold, so their spam-rate and engagement bar applies fully to you. 

1. Gmail Postmaster Tools - do this first, it's the actual source of truth Everything above is inference from opens; Postmaster gives you Gmail's own view: 

• Spam rate - this is the one that matters most. Gmail wants this under 0.10%, and anything approaching 0.3% risks bulk filtering. Marketing Cloud's own complaint tracking undercounts this people who just hit "report spam" without unsubscribing don't always show up the same way in MC's complaint metrics.
• Domain/IP reputation High/Medium/Low/Bad bucket, tracked daily
• Delivery errors and feedback loop data
• Needs domain verification (TXT record) if not already set up, this alone is worth doing regardless of the current issue, since you'll want the historical trend once you have it.

2. Segment your engagement report by ISP before doing anything else

If open rate dropped roughly evenly across Gmail/Yahoo/Outlook, that points more toward content/list fatigue than a Gmail specific inbox placement issue. If it's disproportionately Gmail, that confirms reputation/spam rate as the driver. This one check tells you which of the two paths below to prioritize. 

Since authentication passes, a spam rate creep is the next most likely explanation for exactly this symptom (delivered flat, opens down). Things that quietly push spam rate up: 

• A list merge/import around July/Aug that added lower-quality or older contacts
• No visible/working one-click unsubscribe (Gmail requires the List Unsubscribe header AND that it actually works within 2 days) if someone can't easily unsubscribe, they hit "report spam" instead
• Content changes (new sender name, new link domains, more images) that shifted spam filter scoring independent of reputation

4. Sunset flow before mass suppression

Once you know the spam rate and whether it's Gmail specific, then move to hygiene but sequence it: 

• Re-engagement send to 90+ day unengaged (low risk subject line ask if they still want these)
• Suppress non responders after that, rather than a single large deletion a sudden big cut can itself cause a short-term reputation dip right when you're trying to recover

Hi Taylor, 

Two different signals here: Spam Rate (0.03–0.08%) = user complaints on delivered mail — that's fine. "Suspected spam" delivery errors (71.53%!) = Gmail rejecting/deferring mail at SMTP before it's even delivered. That's your open-rate drop right there — rejected mail can't be opened. 

Since template/process are unchanged, likely causes: 

1. List engagement decay — reusing the same DE monthly means unengaged/dead Gmail addresses pile up over time. Gmail's filtering is engagement-based, so this alone can trigger a spike even with zero content change. Prune addresses with no opens/clicks in the last 3–6 sends. 

2. Auth drift — SPF/DKIM/DMARC can silently break (DNS changes, key rotation, lookup limits) without touching the email. Check a recent header via Google's Messageheader tool. 

3. Check Postmaster's own Domain/IP reputation graphs (not SenderScore — different data source) for a Gmail-specific drop to Medium/Low. 

4. Tracked/redirect links in the template can carry their own reputation issues independent of content — test them via Google Safe Browsing/VirusTotal. 

Start with #1, it's the most common cause of this exact pattern. 

Reference:

A Salesforce Case directed me to the solution: 

Since Summer '26, these verification links are session-bound to the admin who initiated the change. 

The EmailChangeVerification service requires the same logged-in session for sending the verification AND clicking the verification link in the resulting email. When a different user clicks the link, the token mismatch triggers Device Activation, which blocks the verification from completing. That also explains the missing Login History entries: Device Activation intercepts before the login is processed.

I sent a new verification email and asked the mailbox owner to forward the verification email back to me. I then logged in and clicked the link.

Salesforce confirmed this is Working As Designed, and no fix is planned.

This is documented in a KA (https://help.salesforce.com/s/articleView?id=005388172&type=1), but it's hard to find if you are working on Chatter verification, and it didn't come up in my AI-driven web searches.

The article is titled for Email-to-Case routing addresses and Organization-Wide Email Addresses, never mentions Chatter, and closes with "This behaviour is specific to routing address verification." Searching on the Chatter symptom won't surface it, and skimming it suggests Chatter isn't affected. 

I'm cross-posting this in Salesforce Stack Exchange for visibility (and in the hopes that it will be more likely that future AI-driven troubleshooting sessions find this content): 

One important nuance to add to Kundan's answer, because this trips people up on Cases specifically: 

Bounce Management (Setup > Deliverability) flags the Contact/Lead/Person Account record, not the Case. Even with it enabled you will not get a bounce badge on the Case's email message itself, and 'Return bounced emails to sender' delivers the bounce notice to the sending user's own inbox, not onto the Case timeline. It also only kicks in reliably when the recipient resolves to a Contact/Lead/Person Account email, a free-typed typo address that matches no record can bounce with nothing flagged in Salesforce at all. That is most likely why your typo case showed nothing. 

How OOO replies and bounce (NDR) messages actually behave: they are just inbound emails sent back to whatever From/Reply-To you used. If you send from the Case using your Email-to-Case routing address, those replies DO come back into Salesforce, but by default they usually create a brand-new Case rather than attaching to the original, unless threading matches them up (Lightning header-based Email-to-Case threading, or the legacy Ref ID token in the subject/body). So the first thing I would check: search for Cases created from the mailer-daemon or the recipient's mail server around that time. Your OOO and bounce messages are probably sitting there as separate cases. 

If what you actually need is a reliable per-message 'did this bounce?' status shown on the Case, native Case email sending does not expose that. For that, route sending through an external email service/relay that reports bounces via webhook (e.g. SendGrid, or Email Relay with a mail server that returns delivery status), or use Marketing Cloud / Account Engagement for tracked sends. Those give true delivered/bounced status per message. 

Quick checklist: 

1. Setup > Deliverability: Bounce Management ON (flags Contact/Lead recipients). 

2. Confirm you are sending with the Email-to-Case routing address as From/Reply-To so replies return to Salesforce. 

3. Verify Email-to-Case threading (Lightning threading or Ref ID) so OOO/bounce replies attach to the original Case instead of spawning new ones. 

4. For guaranteed per-message bounce status, use an external relay with bounce webhooks or MC/Account Engagement. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)

Hi Jaylen - really well-framed question, and the core of it is one architectural constraint: Salesforce Email Relay can't do SMTP AUTH (there's no username/password in the relay config), so the receiving relay has to trust Salesforce either by IP or by TLS certificate. Google Workspace's SMTP relay only offers IP allowlist or SMTP auth - no cert-domain matching - and since Salesforce can't authenticate, you're left maintaining the IP allowlist forever. That's why it feels like a treadmill: with Google as the relay target, it genuinely is a dead-end. 

Two maintainable exits: 

1) Drop the relay and send direct with full auth (my default recommendation). Configure DKIM keys in Salesforce (Setup > DKIM Keys), SPF with include:_spf.

, and a DMARC record. Direct sending with SPF + DKIM + DMARC alignment holds up well to Gmail/Outlook/Yahoo - it satisfies the 2024 bulk-sender requirements natively - and it removes the IP-allowlist maintenance entirely. On your Q1: deliverability direct is generally as good or better, because you drop a hop and stop inheriting a relay's reputation. 

2) If you must keep a relay for compliance, move the target from Google to Exchange Online and use the TLS-certificate connector method instead of IP allowlisting (your Q4). EXO inbound connectors can authenticate Salesforce by the domain on its TLS cert, which survives IP rotation - Google's relay can't do that. Salesforce's cert renews over time, but the domain EXO matches on has stayed stable, so it's held up as a maintainable approach. 

On Q2 (reasons to keep the relay): the legitimate ones are outbound archiving/journaling, DLP scanning, org-wide disclaimers, and 'all egress through one gateway' security policies. If none of those are mandated, you can safely drop it - Bounce Management, DKIM, and Email Security Compliance all work fine without the relay. The relay's real value is compliance/DLP, not deliverability. 

On Q3 (SendGrid/Mailgun/Postmark/SMTP2GO): heads-up - those authenticate via API-key SMTP AUTH, which (per the constraint above) Salesforce's relay can't supply. So they don't slot in cleanly as a Salesforce relay target unless they also offer IP-based acceptance, and you'd be back to the same problem plus shared-pool reputation risk on transactional mail. 

Net: for 'maintainable, not another band-aid' - go direct-with-DKIM if you don't have a hard archiving/DLP mandate, and EXO-with-TLS-cert if you do. Google-relay-plus-IP-allowlist is the one path that can't be made low-maintenance, because of the no-SMTP-AUTH limitation. 

Hope that helps you land it!

Yep, you're not the first to notice this! Check out @Michael Kolodner's post here: https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000pOw590AC https://www.freelikeapuppy.tech/post/unverifiable

There's also this Knowledge article: