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:
- IP allowlist maintenance — works but requires constant upkeep as Salesforce's IPs rotate.
Questions for the community:
- For anyone who's actually deactivated their Email Domain Filter and let Salesforce send directly. How has deliverability held up long-term, especially to Gmail/Outlook/Yahoo?
- Is there a real, common business reason to keep Email Relay active, can I run processes without it? (DLP scanning, compliance archiving, etc.) Anything that I should weigh before dropping it, beyond Bounce Management/Email Security Compliance features?
- For those using a third-party SMTP relay (SMTP2GO, SendGrid, Mailgun, Postmark, etc.) with Salesforce, any real experience with shared-IP-pool deliverability issues specifically for transactional CRM mail?
- Anyone running the TLS-certificate-domain method (vs. IP allowlist) on an Exchange Online connector for Salesforce specifically — has Salesforce's certificate stayed consistent for you over time?
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!
