Hi everyone! I have a Salesforce Flow that sends confirmation emails. My Email Alert, Org-Wide Email Address, and email settings are configured correctly, but email delivery is intermittent: sometimes emails arrive, sometimes they don't.
I checked the Salesforce Email Logs, and failed messages show a DKIM authentication error (550-5.7.30).
Has anyone experienced this issue? How can I fix it? I appreciate your help.
I appreciate your help! Thank you!
#Flow #Email Deliverbility
Hi Trailblazer Community,
We have been experiencing intermittent email delivery failures to Gmail recipients from Salesforce Marketing Cloud (SFMC) since 15 August 2026. The issue affects multiple sending domains and appears sporadically.
Issue description
We are observing the following symptoms:
Investigation completed so far
We are trying to establish whether this is related to the sending IP infrastructure, reverse DNS configuration, DNS resolution inconsistencies, or another underlying issue.
Questions for the community
We would appreciate insights from anyone who has resolved a similar issue, particularly where SPF, DKIM and DMARC configurations appeared correct but Gmail continued to report PTR-related delivery failures.
Thank you in advance for your help.
#Marketing Cloud #Marketing Cloud Engagement #Email Deliverbility #MC Domain Verification
Forum Ambassador
I will check with @Salesforce Deliverability group, and see if someone there - possibly @Michael Wright
could have some suggestions for dealing with this issue.
However I am surprised that support assured you that everything was fine - since you have clear evidence from your own monitoring and bounce data view, that Gmail reports issues on the sending end. I will try and push the support to open a so-called GUS Investigation for these deliverability issues - if not done already. These investigations are managed by Salesforce deliverability team, and are often more helpful than the work done by their regular support.
I'vs noticed unusually high held rates across some of our email sends, although the issue appears to be intermittent. Has anyone experienced something similar, and if so, could you please share what may have caused it and how it was resolved?
I’m also seeing an increase in “View in Browser” clicks. Could these two issues potentially be related?
#Marketing Cloud #Email Deliverbility #Email
Forum Ambassador
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.
Hi, we recently identified two challenges related to email attachments sent from Salesforce and would like to understand how others are handling similar situations.
When an employee sends an email to a customer with an attachment, the file is also automatically uploaded to our Experience Cloud site. However, attachments larger than 35 MB are processed through Content Delivery, which generates a
public link to the file. This creates a security concern, as anyone with access to the link can potentially view and download the document.
We also face email delivery issues with large attachments. Many email providers, including Outlook, enforce attachment size limits of around 25 MB. As a result, emails containing attachments between 25 MB and 35 MB may
fail to be delivered to the recipient, even though they appear to have been sent successfully from Salesforce. In many cases, employees are unaware that the customer never received the email.How do you manage large file sharing with customers while maintaining security and ensuring reliable delivery?
We'd be interested to hear about your best practices and any Salesforce-native or third-party solutions you've implemented.
#Email Deliverbility #Email Attachment #Salesforce Admin
@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.
Hi! I was wondering if anyone else was experiencing this. We have been getting a much lower than normal open rate the past two monthly sends. We used to average between 40-50% open rate but have now dropped to 29% for each send (august & september). I first thought it was our subject line but don't think that's the cause anymore. Our delivered emails remain the same so no drop in that.
I did research on the Gmail update that happened in July that penalizes larger lists and prioritizes engagement. We do have a lot of unengaged subscribers which I am thinking could be the cause of this. Would it be worth cleaning out these subscribers to see if this fixes the issue? Any other recommendations or think this may be something else?
#Marketing Cloud #Email Deliverbility
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:
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.
3. On spam rate specifically check for a silent causeSince 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:
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:
A few weeks ago I posted that I've been experience a lower than usual open rate falling from around 42% to 29%. Someone suggested I look into Google Postmaster for information on spam rate and deliverability. I got this to work and started investigating but can't determine what I should do. I provided information below. Thanks! Edit: It is important to note that I use the same template and sending method (a data extension for every monthly send so nothing has changed here)
Deliverability analysis:
"A significant percentage of your messages have delivery errors, typically a result in sudden increase in sending volume or issues with your infrastructure. The errors are causing a delivery delay for the affected messages."
Recommended action: Check the STMP logs for your outgoing email. Reduce sending rate and check the SMTP bounce message for more details and instructions.
Delivery Errors for recent sends
Error type: reject, reason: suspected spam, percentage: 7.32%
Error type: reject, reason: suspected spam, percentage: 71.53%
Error type: reject, reason: suspected spam, percentage: 0.69%
Spam rate:
July: 0.04%
August: 0.08%
September: 0.03%
I was also told to run it through Senderscore for my IP address and it came back with a high score of around 90 so it shouldnt be the IP address.
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:
https://support.google.com/mail/answer/9981691I'm changing the Chatter sender address in Setup > Chatter > Email Settings to a shared mailbox that I don't personally receive mail at. A client monitors the mailbox.
Saving the field sends a verification email to the new address. My client clicked the link and saw a confirmation that verification succeeded. She was then redirected to a Salesforce login screen, prepopulated with my username. She tried to login using her own credentials and was rejected. Her failed attempts don't appear in her Login History at all.
Setup continued to show "Requested new email address isn't valid until verified."
Here's what I have tried and ruled out so far:
What's blocking the verification?
#Chatter #Verification Email #Email Deliverbility
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):
https://salesforce.stackexchange.com/questions/439845/why-does-the-chatter-sender-address-stay-unverified-after-the-mailbox-owner-clic/439846#439846
Whenever an internal user assigns a task for community user ,email notifications are not getting triggered. Even there are no records in email log files.
what could be the issue here?
#Salesforce Developer #Salesforce Admin #Email Deliverbility
Hi,
When emails are sent from cases, don't receive any out-of-office messages or failed email messages. In one case there was a typo error in the email address, but didn’t receive an error message like the one you get when you send an email incorrectly in Outlook. Can Salesforce capture and display Out-of-Office responses or email bounce-back messages for emails sent from Cases? Are there any email settings, Email-to-Case configurations, or deliverability options that need to be enabled to receive these notifications?
Thanks.
#Salesforce Admin #Salesforce Developer #Service Cloud #Case Management #Email Deliverbility #Email
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 all, hoping to get some real-world input on an Email Relay / deliverability issue we've been chasing.
The problem:
Our org has Salesforce configured with an Email Domain Filter (catch-all, */*) routing all outbound mail through an Email Relay pointed at our Google Workspace SMTP relay service. We've started getting persistent 550-5.7.1 "Invalid credentials for relay" bounces — root cause is that Salesforce sends from a large, rotating pool of outbound IPs, and our relay's IP allowlist can't keep up. This affects everything from Opportunity Update Reminders to account-transfer notifications, not just bulk sends.
Our Current setup:
Questions for the community:
Appreciate any first-hand experience — trying to land on something maintainable rather than another band-aid.
#Email Deliverbility
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.
salesforce.com, 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!
