Email Relay in Salesforce: Setup, Best Practices, and Deliverability Guide

Introduction

Email deliverability issues can create major friction for organizations that rely on Salesforce for customer communication. Many teams turn to email relay in Salesforce because it offers stronger control over outbound email performance. According to a 2023 industry study, only 47 percent of organizations achieve a 95% delivery rate for transactional emails, which means more than half face avoidable gaps in reliability.

When key messages fail to land, customers miss updates, teams lose trust in the system, and business processes slow down. This is why many organizations turn to email relay in Salesforce. It routes all outbound emails through their own mail server, which improves control, visibility, and compliance without changing how users work.

For teams scaling their Salesforce usage, improving email deliverability directly impacts customer experience, conversion rates, and compliance posture. Implementing a Salesforce email relay setup ensures your emails originate from your verified domain, strengthening authentication signals like SPF, DKIM, and DMARC.

In this guide, we explain how email relay works, why it matters, and how to configure it using clear steps supported by actionable insights and credible research.

What is email relay in Salesforce?

Email relay in Salesforce routes Salesforce-generated emails through your own SMTP or mail server instead of Salesforce’s default mail servers. In simple terms, Salesforce creates the email, and your mail server delivers it. This gives your team more control over deliverability, security, and branding.

Email relay acts as a bridge between your Salesforce org and your company-owned email infrastructure. You continue using Salesforce templates, workflows, automation, and MassMailer-driven processes, while your relay server manages the final delivery. Using email relay in Salesforce also helps strengthen domain authentication and improve overall inbox placement by sending messages from your verified domain.

How Salesforce Email Relay Works (SMTP Routing Explained)

Here is the sequence Salesforce follows when sending an email through your relay server:

1. Salesforce generates the email: Salesforce creates the message when a workflow rule, Flow, Apex process, user action, or MassMailer-powered send triggers an outbound email event.

2. Salesforce connects to your SMTP relay server: Salesforce reaches your mail server using the SMTP host, port number, TLS setting, and optional authentication details you configure in Email Relays. This is the core step that enables email relay in Salesforce to pass messages to your own infrastructure.

3. Your mail server applies your organization’s security and routing policies: Your server reviews the message using filtering rules, logs the event, checks for policy issues, and determines the correct route for delivery.

4. Your mail server delivers the email to the final recipient: The server sends the message to the recipient’s mail provider, ensuring delivery aligns with your organization’s communication and compliance standards.

5. Your domain authentication strengthens trust signals: SPF, DKIM, and DMARC validate the message and help mailbox providers recognize it as legitimate, improving inbox placement over time when using Salesforce email relay.

Why organizations use SMTP relay with Salesforce

Teams adopt email relay in Salesforce for several reasons that tie directly to security, visibility, and performance:

1. Stronger control over deliverability: You manage sending IPs, domain reputation, and authentication instead of relying only on Salesforce’s shared infrastructure. Using SMTP relay in Salesforce also helps stabilize inbox placement by aligning messages with your trusted domain.

2. Consistent branding and sender identity: Messages appear as if they come directly from your organization’s domain. This builds trust for transactional, account, and lifecycle communication.

3. Compliance and audit requirements: Regulated industries often must route email through central gateways with retention, archiving, and logging controls. Email relay ensures Salesforce emails meet these governance requirements.

4. Unified organizational security posture: Security teams prefer email relay because it centralizes filtering and inspection. A peer-reviewed academic study cites Deloitte PLT and reports that 91 percent of cyber-attacks begin with a phishing email, reinforcing the need for consistent outbound protection.

5. Advanced analytics and integration options: Relay logs and SIEM tools give deeper visibility. You can pair email relay with MassMailer for enhanced deliverability, analytics, and sending control on top of your existing mail server.

When organizations want greater control, stronger security, and more predictable delivery, email relay in Salesforce becomes the foundation that supports reliable, policy-aligned communication at scale.

Key requirements before configuring email relay in Salesforce

Before we configure email relay in Salesforce, we need to make sure our domain, mail server, and Salesforce environment are fully prepared. These prerequisites help us avoid delivery failures, authentication issues, or unexpected limits during setup.

1. Domain authentication and sender reputation

To successfully configure email relay in Salesforce, our sending domain must have valid SPF, DKIM, and DMARC authentication and a stable reputation. This ensures mailbox providers trust messages routed through our SMTP relay.

• We need a strong authentication foundation before routing Salesforce emails through our mail server. This protects our domain, improves trust signals, and reduces the chance of messages being flagged as suspicious.
• We verify our sending domain: We send email from a domain our organization owns and controls. This gives us full authority over DNS and improves overall deliverability.
• We configure SPF for our sending path: Our SPF record authorizes the servers that send mail for us, which can include Salesforce or our SMTP relay. This prevents spoofing and strengthens domain trust.
• We enable DKIM signing: Salesforce supports DKIM signing, and our relay can sign messages as well. DKIM helps mailbox providers verify that our messages have not been altered.
• We align our DMARC policy with SPF and DKIM: A DMARC policy helps us receive reports, enforce alignment, and protect our domain from abuse. We start with a relaxed policy, then tighten it when our authentication passes consistently.
• We monitor domain and IP reputation: We track blocklists, complaint rates, and bounce patterns. Research shows that strong authentication combined with ongoing monitoring improves inbox placement.

Strong authentication is the foundation of successful email relay in Salesforce. When SPF, DKIM, and DMARC work together, our emails gain credibility, and deliverability improves across all channels.

2. Mail-server prerequisites, SMTP ports, and TLS settings

Your SMTP relay must allow Salesforce IPs, support TLS, and accept the correct port (commonly 587) to ensure a successful Salesforce email relay connection.

• Our SMTP relay server must be ready to receive traffic from Salesforce and support the security level we choose. This ensures a stable and secure handoff between Salesforce and our relay.
• We allow Salesforce IP ranges on our mail server: Our firewall must allow inbound SMTP from Salesforce so our org can connect to the relay reliably.
• We confirm the correct SMTP ports: Port 587 with TLS is a common choice for secure relay. Some servers support port 25 or 465. We match our settings with what our provider supports.
• We select a TLS mode that matches our server capability: Salesforce supports several TLS modes. Using a verified TLS certificate improves security and helps ensure message integrity.
• We verify SMTP authentication support: If our organization requires authentication, our relay must support PLAIN SMTP authentication so Salesforce can use it.
• We prepare for capacity and logging: Our relay needs enough throughput to handle Salesforce traffic, and logging should be enabled so our IT or security teams can troubleshoot or audit activity.

A ready and secure SMTP relay server prevents connection issues during setup. When ports, TLS, authentication, and firewall rules are correct, Salesforce can hand off messages to our relay without interruption.

3. Salesforce edition limitations and sending-volume considerations

Salesforce email relay does not bypass platform email limits, so understanding edition features and daily send caps is essential before enabling SMTP relay.

• Salesforce supports email relay in several editions, but our org still has built-in limits. We check these details early so we can design a setup that works with our organization’s volume and compliance needs.
• We confirm feature availability in our edition: Email relay is supported in most business editions, such as Enterprise and Unlimited. We verify this in Salesforce help or with our admin.
• We understand that Salesforce email limits still apply: Even when we use email relay, Salesforce enforces its usual daily send limits. Relay affects the delivery path, not the platform limits.
• We check our mix of transactional and bulk messages: Many organizations use Relay for transactional emails, but use a specialized tool like MassMailer when they need high-volume sending.
• We review bounce handling and reply routing: Some environments prefer bounces to be managed at the mail server level. Others integrate bounce data into Salesforce for visibility. We choose the model that fits our workflow.
• We plan for sandbox and production differences: Using separate relay settings for sandbox environments helps us test safely without affecting real customers.

Understanding Salesforce limits and email-volume patterns ensures we choose the right relay strategy. When our edition, limits, and use cases align, the configuration process becomes much more predictable.

Step by step: configure email relay in Salesforce

To configure email relay in Salesforce, we create an Email Relay record, enter our SMTP server details, set up domain filters, and run structured deliverability tests. After configuration, Salesforce routes outbound email through our own mail server instead of its default infrastructure.

1. Enable email relay in Salesforce setup

Salesforce Setup provides the main interface for enabling email relay. We begin by opening Setup, then searching for Email Relays in Quick Find. We select New Email Relay, then enter the SMTP Host (domain or IP) of the mail server we want Salesforce to use. This can be an internal server, such as smtp.yourcompany.com, or a cloud provider like smtp-relay.gmail.com.

Next, we select the port, usually 587 for TLS or 2,5 depending on our mail environment. Salesforce then asks us to choose a TLS mode: Off, Preferred, Required, or Required Verify. If our mail server requires credentials, we enable SMTP Authentication and add the appropriate username and password. We then save and activate the relay entry.

This step connects Salesforce to our server, but it does not yet determine which emails should use the relay path. Domain routing comes later.

2. Add SMTP host, port, and TLS settings

Next, we confirm that our SMTP settings match our mail server’s configuration. These details determine whether Salesforce can connect securely and deliver email without interruptions.

We often use a configuration pattern like this:

Key points to ensure a stable connection:

• Salesforce uses the selected TLS mode to establish the connection. Preferred attempts TLS but falls back to plain SMTP.
• Required blocks email delivery if the server does not support encryption.
• Required Verify validates the server certificate’s common name and is ideal when your server presents a valid certificate.
• Salesforce IP ranges must be allowed through the firewall. Blocking them prevents any connection from Salesforce.
• Your SMTP relay must support the authentication mechanism Salesforce uses, such as PLAIN, or the login will fail.

When these values align with our mail server’s capabilities, Salesforce maintains a stable, secure connection without handshake failures or intermittent drops. These settings prepare Salesforce for a secure connection, and the next step determines which outbound messages will use this relay.

3. Create email domain filters for sender and recipient control

Email domain filters determine which Salesforce emails should pass through the SMTP relay. This routing layer ensures that only approved sender or recipient domains use the relay, which helps maintain consistent delivery, compliance, and policy alignment.

We open Setup, search for Email Domain Filters, and select New Domain Filter. We enter the Sender Domain, such as “**.yourcompany.com”, to ensure that only messages from our approved domains use the relay. If we want all outbound emails to route through the relay, we set the Recipient Domain to *. We then map this filter to the relay configuration created earlier.

Domain filters also let us apply different routing paths for different use cases. For example, organizations often send transactional messages through a high-deliverability relay while keeping internal notifications on a corporate SMTP server.

Domain filters allow Salesforce to route outbound messages consistently and ensure that only approved traffic uses the relay.

4. Test deliverability and validate routing

Testing confirms that the Salesforce email relay is functioning correctly before we rely on it for production traffic. We open Setup, search for Test Deliverability, and send a test message. This verifies that Salesforce can connect to the relay and that authentication and TLS negotiation succeed.

When we receive the test email, we review the email headers to confirm that the message passed through our SMTP relay host and that the TLS handshake completed as expected. We also check our mail server logs to verify that Salesforce connected from an allowed IP range and that our relay applied the intended filtering and security rules.

During initial rollout, we monitor bounce patterns, spam-folder placement, and server response time. Tracking baseline data before and after enabling relay helps us identify improvements or early issues quickly.

Deliverability testing confirms secure routing, validates relay behavior, and ensures that Salesforce SMTP relay works reliably under real sending conditions.

Outbound email routing and SMTP server integration

When we enable email relay in Salesforce, we shift the final delivery step to our SMTP server. Salesforce still creates the email, but the actual send happens from our infrastructure. This routing step influences security, compliance, and overall deliverability.

1. Salesforce SMTP relay vs standard Salesforce delivery

Salesforce can send email directly from its own mail servers or through our SMTP relay.
With standard delivery, Salesforce handles everything inside its infrastructure. This option is simple and requires little configuration.

When we use SMTP relay, Salesforce hands the message to our mail server first. Our mail server applies filtering, logging, and policy checks before sending the email. This model gives us control over routing paths, message inspection, and domain alignment. It also helps large organizations maintain consistent email governance across all systems.

SMTP relay gives us more control and visibility, while standard sending prioritizes simplicity.

2. Routing Salesforce emails through internal or cloud mail servers

Once the relay is active, we can route messages through an internal server or a cloud provider. Microsoft’s SMTP relay guidance shows how business applications send mail through Microsoft 365 using allowed IPs or authentication, which aligns with how Salesforce connects.

Google Workspace’s relay guidance shows a similar model using smtp-relay.gmail.com, where systems send through a managed gateway with domain controls. 

We map Salesforce domain filters to these relays so each message follows the right path, whether it is internal, external, or tied to a specific business unit. Routing through internal or cloud relays keeps Salesforce aligned with existing email-governance workflows.

3. Monitoring and logging mail-server activity

After routing is configured, monitoring ensures reliable and secure delivery. Gartner notes that email remains a major attack vector, which makes visibility critical.

Effective monitoring includes:

• Checking mail-server logs for connection attempts and TLS status
• Sending relay logs to a SIEM for central analysis
• Tracking bounce and delivery patterns
• Setting alerts for abnormal volume or authentication failures

Strong monitoring confirms stable routing, exposes deliverability issues early, and supports organizational security requirements.

Best practices for secure and reliable email relay in Salesforce

To keep email relay in Salesforce secure, reliable, and high-performing, we follow a few practical best practices that focus on reputation, security, and scale.

1. Maintain a strong domain reputation and deliverability

Solid domain reputation keeps our Salesforce SMTP relay traffic out of spam folders.

• Use dedicated sending domains, or subdomains, for system-generated email.
• Keep lists clean by removing invalid, bounced, and unengaged addresses regularly.
• Monitor bounce, complaint, and open rates inside Salesforce and in our mail server.
• Align “From” addresses with authenticated domains that use SPF, DKIM, and DMARC.
• Avoid sudden high-volume spikes; ramp up gradually when we add new flows or campaigns.

2. Enforce TLS and server-level security

Security controls on the relay protect both our data and our reputation.

• Set TLS to Required, or Required Verify, when our certificate supports it.
• Restrict relay access to Salesforce IP ranges and specific service accounts.
• Rotate SMTP credentials on a regular schedule and store them securely.
• Keep the mail server patched, monitored, and backed up.
• Review relay usage with security teams so policies, controls, and alerts stay current.

3. Optimize configuration for larger-scale outbound email

As Salesforce usage grows, our email relay settings must support that scale.

• Separate high-volume, application-driven email from day-to-day user email where possible.
• Use domain filters to route different brands, regions, or functions through tailored relays.
• Add queueing or rate limits on the mail server to handle bursts safely.
• Use reporting tools, including MassMailer analytics, to track volume, delivery, and engagement over time.
• Test changes in a sandbox or staging environment before applying them to production.

These practices help us maintain consistent, secure, and reliable email delivery when we use Salesforce SMTP relay as part of our overall email infrastructure.

Common issues and troubleshooting

Most problems with email relay in Salesforce fall into three buckets: authentication or TLS failures, messages blocked or delayed, and unexpected bounce behavior. If we look at symptoms through that lens, we can usually fix issues quickly.

1. Authentication or TLS failures

When Salesforce cannot hand off to our SMTP relay, we often see errors in email logs or Salesforce delivery reports. We can check for:

• Incorrect SMTP host or port in the Email Relay settings.
• TLS is set to Required or Required Verify while the server does not support that level yet.
• A certificate that does not match the hostname we configured.
• Missing firewall rules that allow Salesforce IP ranges.
• SMTP authentication is enabled in Salesforce, but disabled or misconfigured on the relay.

Once we align host, port, TLS, and auth, most connection errors disappear.

2. Emails are delayed, blocked, or landing in spam

If email relay in Salesforce appears to work, but users or customers do not see messages, we review:

• Message headers to confirm that our relay actually handled the message.
• SPF, DKIM, and DMARC results for our sending domain.
• Reputation or blocklist status for the relay IP address.
• Volume spikes from new automations or bulk sends.
• Local filtering rules in the recipient’s mailbox or gateway.

Small changes to reputation, authentication, or volume patterns often restore inbox placement.

3. Bounce-handling behavior

When we use Salesforce SMTP relay, bounces can surface in different places. We decide whether the source of truth is Salesforce or our mail server, then:

• Review Salesforce bounce reports for system-level patterns.
• Review relay logs for repeated hard bounces from the same domains.
• Remove or suppress invalid addresses promptly.

Clear ownership for bounce data keeps our email relay in Salesforce stable and predictable over time.

Email Relay vs alternative Salesforce email options

Email relay in Salesforce gives us control over how emails leave our organization, but it is not always the only or the best sending method. Choosing between relay, built-in Salesforce sending, or a dedicated delivery platform depends on how much control, scale, and optimization we need.

When to use Relay instead of Salesforce’s built-in sending

We use email relay in Salesforce when we want to manage our own sending IPs, apply our organization’s security policies, and maintain consistent logging across every outbound message. Relay is also useful when we want Salesforce emails to route through our corporate SMTP system, including cases where messages should appear in employee Sent folders.

It fits best when we already operate a reliable mail server and want Salesforce email to follow the same compliance and delivery standards as our internal email traffic.

Relay is the stronger option when we need predictable control, policy enforcement, and consistent routing for Salesforce-generated email.

When a dedicated email-delivery platform is a better fit

A dedicated platform is a better match when scale, optimization, and analytics matter more than SMTP control. These platforms support high-volume sending, advanced personalization, and stronger deliverability features without requiring us to manage mail-server infrastructure.

Tools like MassMailer extend Salesforce with native bounce-handling, suppression rules, and deeper reporting that help teams run large transactional or marketing workflows more efficiently.

A delivery platform is the better choice when our priorities include scale, advanced features, and data-rich visibility rather than managing email infrastructure.

How MassMailer complements Salesforce email relay

Salesforce email relay gives us control over routing, security, and compliance. MassMailer adds the scale, analytics, and automation features that Salesforce alone cannot provide. Together, they create a dependable and flexible email-delivery setup.

Advanced sending controls and analytics

MassMailer allows high-volume sending from Salesforce while still using the organization’s SMTP relay. This keeps IP reputation stable and adds deeper performance insights.

MassMailer provides:

• Real-time open, click, and bounce analytics
• automated suppression and bounce handling
• advanced template and content tools
• link-tracking and engagement reporting
• scheduling controls for large sends

This combination improves inbox placement because the relay stabilizes delivery, and MassMailer strengthens targeting and monitoring.

Support for high-volume, compliant email delivery

MassMailer helps teams scale outbound email without straining internal mail servers. The platform supports global compliance rules, applies suppression logic, and manages retries for slow receiving servers. Teams can segment domains, schedule batches, and maintain consistent branding through centralized templates.

Many growing SaaS companies use MassMailer with Salesforce Relay to keep deliverability strong as volume increases. This combination gives us a stable, secure way to extend Salesforce email relay without adding operational complexity.

Conclusion

Configuring email relay in Salesforce helps us improve security, strengthen domain reputation, and maintain consistent control over every outbound message. When we set up authentication, routing, and testing correctly, Salesforce SMTP relay becomes a reliable part of our email infrastructure.

MassMailer enhances this setup by adding analytics, compliance controls, and high-volume sending capabilities that Salesforce does not offer on its own. This gives us a scalable, data-driven way to manage communication while still using our organization’s relay policies.

If we want to ensure that our Salesforce email relay is configured for performance, compliance, and growth, a short readiness review can help surface gaps early.

If we want Salesforce email relay to perform at its best, now is the right time to assess our configuration and strengthen our sending foundation.