Considerations for Setting Up Email Relay

Bounce Management with Email Relay

To use Bounce Management, your email server must allow the relaying of email sent from Salesforce with a salesforce.com domain.

Use Email Relay and Bounce Management with care as it can cause Sender Policy Framework (SPF), a common email security standard, to fail to validate. The Salesforce bounce management feature relies on setting each outgoing email's return path, the envelope from address, to an address at bnc.salesforce.com. SPF works by extracting the domain in the return path to find a set of authorized IP addresses.

When you use Email Relay and Bounce Management, the IP address of your relay doesn’t match the authorized IP addresses for the domain (bnc.salesforce.com). This mismatch results in a SPF soft failure. It doesn’t mark your message as invalid, but it reduces your deliverability.

There are two solutions:

• Establish a DMARC policy for your domain, and use Salesforce's DKIM signing feature to sign outgoing mail. With this combination, your mail passes a DMARC check even though it doesn’t pass SPF.
• Turn off bounce management in Salesforce.

Deliverability Settings and Email Relay

When email relay is enabled in Salesforce, companies don’t always need all the Salesforce Email Deliverability settings from Setup. Some of these settings modify the envelope-from address of emails sent from Salesforce. The header From address remains set to the sender's email address. The return-path in the headers is also modified. This change in the email headers may affect email delivery to your email server because the modified return-path includes a Variable Envelope Return Path value (VERP).

• Example of a standard return-path: <name@domain.com>
• Example of a VERP return-path: <name@domain.com__x@x.bnc.salesforce.com>

Disable these email deliverability options when using email relay.

• Turn off Enable compliance with standard email security mechanisms.
• Consider turning off Activate Bounce Management.

After disabling the settings, outbound email sent from Salesforce to your relay server shows the envelope-from and the return-path as <name@domain.com>.

Securing Your Email Relay

Follow these suggestions to make sure that your mail relay is secure and that you relay only the mail that you intend to.

• Include only the IPs that you want to use to relay mail for ours and any others in your relay’s allowlist.
• Only relay mail that’s sent using your mail domain.
• Enforce TLS. Optionally set it to TLS required or required and verify the hostname on the certificate.
• Have your relay verify the hostname on our certificate.
• Look for a header - X-SFDC-LK and makes rue that it has your orgid in it. Only relay mail from Salesforce if it has the proper orgid.
• Use DKIM signing in Salesforce and only relay mail if the DKIM signature passes.
• Enable SMTP authentication between Salesforce mail servers and your email relay host. Test this feature in a sandbox to make sure that it works as expected. Some email services don’t support SMTP authentication for email relays.

Copying Sandbox with Email Relay

When you copy a sandbox, Email Relay data is copied to the sandbox org. This data includes authentication data stored on an Email Relay record, such as IsRequireAuth, Password, and Username. If you don’t want production authentication data in your sandbox copy, modify the Email Relay in Setup.

Alternatively, you can execute this sample Apex code in your Sandbox Developer Console to remove authentication data from the EmailRelay records.

System.debug('Executing sandbox postcopy update for EmailRelay');
// Query all EmailRelay objects with non-empty credentials and reset.
List<EmailRelay> relays = [SELECT Id FROM EmailRelay WHERE IsRequireAuth = true OR Username != null];

for (EmailRelay relay : relays) {
  relay.IsRequireAuth = false;
  relay.Username = null;
  relay.Password = null;
}

update relays;
System.debug('Updated ' + relays.size() + ' EmailRelay objects');