Send through External Email Services
Send through External Email Services is a Salesforce Setup feature that lets an org route outbound emails (transactional, automated, and Send Email from records) through a third-party email service like Amazon SES, SendGrid, Mailgun, or Postmark instead of the built-in Salesforce email infrastructure.
Definition
Send through External Email Services is a Salesforce Setup feature that lets an org route outbound emails (transactional, automated, and Send Email from records) through a third-party email service like Amazon SES, SendGrid, Mailgun, or Postmark instead of the built-in Salesforce email infrastructure. The feature gives the customer direct control over deliverability, tracking, sender reputation, and compliance with the same gateway their other applications already use.
The feature is particularly relevant for customers with strict deliverability requirements (financial services confirmations, healthcare notifications, government communications) or for those who have invested in a third-party email infrastructure and want a single sending platform across all their applications. Once configured, the outbound email flow goes Salesforce → external service → recipient, with the external service handling MX routing, sender authentication, suppression lists, and delivery analytics. The Salesforce UI for sending email looks the same; the change is entirely in the delivery path.
How external email routing changes Salesforce email behavior
The standard Salesforce email path versus external
Without the feature, every outbound email from Salesforce (Email Alerts, Send Email Quick Actions, Apex sendEmail calls, Marketing Cloud Triggered Sends) leaves the org through Salesforce-operated mail servers. The servers handle TLS encryption, SPF and DKIM signing if configured, queue management, and bounce processing. With Send through External Email Services enabled, the same outbound emails are handed off to the chosen external service via SMTP or API. The external service applies its own queuing, retry, signing, and analytics, then delivers to the recipient. The recipient sees the email as coming from the external service's IP addresses, not Salesforce's.
Why customers route email externally
Three primary reasons drive this choice. First, deliverability: customers with dedicated IP addresses on an external service that they have warmed up over years have higher inbox placement than the shared Salesforce sending infrastructure for some recipient domains. Second, compliance: an external service with detailed audit logs, dedicated IPs, and certified content handling (HIPAA, PCI) gives compliance teams visibility they cannot get from Salesforce alone. Third, consolidation: a customer already operating Amazon SES or SendGrid for other applications can avoid having two separate email reputation stories to manage by routing Salesforce traffic through the same provider.
Setup and authentication
Configuring Send through External Email Services requires Salesforce-side and external-service-side work. On the external service, the customer provisions a sending account, configures the sender domain (acme.com), and verifies ownership through DNS records. SPF, DKIM, and DMARC records are set up to authenticate emails sent from the customer's domain through the external service's IPs. On the Salesforce side, the feature is enabled in Setup and credentials for the external service are configured (typically SMTP credentials with TLS or API credentials with an API key). The customer can route all outbound mail through the service or specific categories (just transactional, or just marketing).
Sender authentication: SPF, DKIM, DMARC
When email leaves the external service on behalf of the customer's domain, the recipient's mail server validates the sender through SPF (does the sending IP match the customer's SPF record), DKIM (is the email signed with a key the customer published in DNS), and DMARC (does the alignment between SPF, DKIM, and the From domain meet the customer's stated policy). Misconfigured records mean recipient mail servers may flag or reject the messages. Most external services provide step-by-step guidance on configuring DNS for their service. The customer's email or DNS administrator typically owns the configuration, with the Salesforce admin coordinating to ensure the feature works end-to-end.
Bounce handling and suppression lists
The external service manages bounces and suppression lists on its side. A hard bounce on the external service adds the recipient to the service's suppression list, preventing future sends to that address. Salesforce does not automatically know about external service suppressions; integration tooling can sync suppression lists back to Salesforce's email opt-out fields if required. For high-volume customer-facing email, this sync is important: without it, Salesforce continues to attempt sends to addresses the external service is silently suppressing, wasting throughput and producing misleading analytics.
Cost and licensing considerations
Routing email externally has cost implications on both sides. Salesforce charges a per-message fee for the Send through External Email Services feature in some editions. The external service charges its own per-message or volume-tier fees. The combined cost can be higher or lower than the standard Salesforce sending infrastructure depending on volume and the chosen service. For low-volume orgs, the standard Salesforce path is usually more cost-effective. For high-volume customer-facing senders (millions of messages per month), the external service can be cheaper at scale because of better volume pricing. Run the cost math against actual sending volume before assuming a particular answer.
Monitoring and diagnostics across two systems
With external routing, troubleshooting deliverability problems requires checking two systems. Salesforce shows that an email was queued for the external service; the external service shows the delivery status, bounce reason, and any suppression. Mature deployments build dashboards that combine both sources, presenting a unified view of outbound email per recipient, per template, and per time period. Without unified observability, debugging a bounced approval email or a delayed customer notification means jumping between Salesforce Email Logs and the external service's console, which slows down resolution and frustrates support teams.
When external routing is the wrong answer
Not every org benefits from routing email externally. Low-volume orgs send fewer messages per month than the volume tier where external services become cost-effective. Customers without an existing investment in an external email service add operational complexity for marginal benefit. Internal-only email (notifications to Salesforce users) does not benefit from the deliverability gains because corporate mail servers accept Salesforce's standard email without trouble. Sandboxes complicate the picture further: routing sandbox email externally means real DNS configuration in a non-production environment, which is rarely worth the effort. The right time to enable Send through External Email Services is when the customer has hit a real deliverability problem with the standard Salesforce path, when they already operate an external email service for other applications, or when regulatory requirements drive the need for the external service's audit and compliance features. Without one of those drivers, the standard path is usually the right answer because it requires no additional infrastructure to maintain.
Common deliverability problems that drive the decision
Three specific deliverability issues most often drive customers to route externally. Inbox placement at major consumer ISPs (Gmail, Outlook, Yahoo) where shared Salesforce IPs may share reputation with other customers sending high volume. Compliance audit requirements where the customer needs detailed per-message logs that the standard Salesforce path does not provide in sufficient depth. Geographic deliverability where local ISPs in specific markets (India, China, Brazil) have stricter rules that an external service with local infrastructure handles better than the standard Salesforce path. Diagnosing which problem a customer faces is the right starting point before deciding whether external routing solves it. Sometimes the answer is to fix SPF/DKIM/DMARC configuration on the standard path rather than routing externally. The external service helps if the bottleneck is sending IP reputation; it does not help if the bottleneck is the content of the messages or the recipients' explicit opt-outs.
Configure Send through External Email Services
Setting up external email routing spans Salesforce-side, external-service-side, and DNS configuration. The workflow below covers the standard sequence for routing Salesforce outbound mail through Amazon SES; the steps are similar for other services with provider-specific differences in the credential setup.
- Provision the external service and verify the sender domain
Sign up for the external service (Amazon SES, SendGrid, Mailgun, Postmark, etc.) if not already in use. Configure the customer's sender domain in the service and complete domain verification through DNS records. Set up the recommended SPF, DKIM, and DMARC records pointing at the service's infrastructure. Test the configuration by sending a sample email from the service's console and confirming delivery to the inbox without spam-folder placement.
- Generate credentials for Salesforce
In the external service, create the SMTP credentials or API key Salesforce will use to authenticate to the service. Note the SMTP endpoint, port, username, and password (or API base URL and key). Save these securely; they will be entered into Salesforce in the next step. For higher security, generate credentials with the minimum scope needed (typically just send-email permission on the verified sender domain).
- Enable the feature in Salesforce Setup
From Setup, search for Send through External Email Services and enable the feature. Enter the credentials from the external service. Choose which categories of email to route externally (typically all outbound) and configure any fallback behavior (what happens if the external service is unreachable). Save and run a test send from the Salesforce email composer or anonymous Apex to confirm end-to-end delivery through the external service.
- Set up bounce sync and monitoring
Configure the external service to send bounce notifications back to Salesforce, either through the service's webhook or through periodic suppression-list export. Build a script or Flow that updates the Salesforce email opt-out fields based on the external bounce data. Set up a dashboard combining Salesforce Email Logs with the external service's delivery analytics for unified observability. Document the configuration in the org's integration runbook and assign an owner for the ongoing operational responsibility.
- Misconfigured SPF, DKIM, or DMARC records cause emails to be flagged as spam or rejected. Verify DNS records before enabling the feature in production.
- Bounces handled by the external service do not automatically sync back to Salesforce. Build the sync explicitly or maintain two divergent suppression lists.
- Cost can increase or decrease depending on volume. Run the math against actual sending patterns before assuming the external service saves money.
- Reply-to handling differs by service. Configure the external service's reply-to behavior to route replies back to Salesforce if inbound capture is needed.
- Sandbox environments may not have the external service enabled. Sandbox testing requires either separate external service credentials or accepting that sandbox sends route through Salesforce's standard path.
Trust & references
Cross-checked against the following references.
- Send through External Email ServicesSalesforce Help
Straight from the source - Salesforce's reference material on Send through External Email Services.
- External Email ServicesSalesforce Help
- Email Deliverability SettingsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which area of Salesforce would you typically find Send through External Email Services?
Q2. What is the primary benefit of Send through External Email Services for Salesforce administrators?
Q3. Why is understanding Send through External Email Services important for Salesforce admins?
Discussion
Loading discussion…