Salesforce SMTP Email Relay and Authentication

The use of an Email Relay inside of Salesforce can solve a lot of issues. If you’re not familiar with Email Relay servers, it’s a simple concept. Using an Email Relay allows you to channel all email traffic sent from a system (Salesforce in our case) out through one point. You might be wondering why you would want to do this, and there are a ton of reasons.

Why use an Email Relay

• Performing some type of centralized operations on outgoing emails like virus scanning or company branding
• Archiving for compliance regulations (Salesforce does support this natively but only with a single email address)
• Filtering for inappropriate content
• Avoid being flagged as Email Spoofer

Email spoofing

That last item, Email Spoofing, is sometimes a big problem and leveraging an Email Relay is one of the Salesforce recommended ways to avoid this. Basically other systems, that route or receive emails, can deny your emails on the basis that it might appear to have not originated as is stated. This can and does happen. Think about a solution in which you leverage the apex Messaging class to send emails. If an email is sent using a “from” address that has a different domain than the one it actually originates on, say from another company owned domain, you will most likely encounter DMARC errors and failed deliveries. By centralizing the outgoing email through an Email Relay you are now positioned to leverage other tools such as MX, SPF, and DKIM technologies to help align yourself to industry email security standards. As a side note, you can use this tool for investigations.

No SMTP Authentication

There is a problem however with using an Email Relay in Salesforce. As per the documentation – “Email Relay uses your company’s email server to send email from Salesforce.”  Salesforce assumes that the Email Relay is a corporate server under your control and because of this assumption it provides no mechanism for authentication. The configuration, and all available fields, are located by performing a Quick Find on Email Relay Activation. You can see in this figure that authentication fields are missing:

This limitation complicates using external providers. Those external email relay providers need to know who’s communicating with them and this is accomplished by authentication. In fact, there is a long standing request by the community to provide this feature with this Idea post: Support Authentication for SMTP Relaying

How to handle the Authentication issue

In the meantime there are email relay providers that are still capable of functioning with Salesforce. Some providers have a proprietary solution that bypasses authentication while others allow management of an authorized senders list (a difficult solution to scale).  Lastly, as a side note, keep in mind that many of these providers also expose an API which can be accessed in an authenticated manner. This is a good solution from a programmatic point of view but is lacking as a direct replacement for an org wide SMTP Email Relay service. Since we’re talking about emails, one other tool I should point out are Email Log Files. Salesforce provides an easy way to get the email logs for the last 30 days of activity. This is important because these logs contain a lot of diagnostic data and can be a life saver when trying to diagnose issues. Simply Quick Find on Email Log Files.

Using an Email Relay with your Salesforce instance is not required but does have its advantages. Perform your due diligence, weigh the pros and cons, and make an informed decision if this feature is right for your organization.