Have you noticed that some emails sent from ServiceNow never reach their destination? There are many reasons why it may seem like your emails are disappearing into cyberspace but sometimes the issue and the solution are simple.
A reason could be as simple as the emails being sent from your instance are being blocked by the end recipient's SPAM filter solution. If this is the case, depending on the configuration of the instance, a customer can guarantee that the emails arrive at their destination by whitelisting the source destinations of the emails.
An instance can be configured to send emails in two different ways.
- When a customer uses ServiceNow infrastructure for their SMTP configuration. This means that all SMTP traffic will be sent from ServiceNow Relay's located in each one of our DataCenters.
- When a customer uses their own SMTP server to relay emails to there instance users.
I will address how to whitelist emails sent from ServiceNow’s own email infrastructure.
Identify if an instance is configured to use the ServiceNow email infrastructure:
If you are using email accounts plugin it will be defined on the server field on the active SMTP record as relay, it should look like this:
If you are not using the email accounts plugin you can check the email property glide.email.server is set to relay. Also make sure your infrastructure is configured to industry standard.
When we are using ServiceNow email infrastructure we need to consider the fact that the emails will be sent from the domain service-now.com even though we set the SMTP default account username to be in a different domain (glide.email.user).
The issue here is that most email servers will consider this as Spoofing. The emails are coming from a different domain than the one we set the client to send from (@mycompanydomain.com), and will result in blocked emails. To make sure this email reaches its destination we need to whitelist the source of this emails to allow delivery to its recipients.
Whitelisting the IP's from ServiceNow’s relay servers would not be effective. It would result in a redundant email infrastructure that is constantly changing. Meaning that the IP addresses would be changing on a regular basis, without any pre warning from ServiceNow team.
To ensure emails from ServiceNow to be delivered at all times even when the infrastructure changes, we should be whitelisting based on the SPF records for service-now.com. If you speak with your email admin they can whitelist based on SPF records. If your admin is not able to do so, your only alternative would be to whitelist based on the SPF records the service-now.com resolves to; however, this is a bad practice, and it is strongly not advisable, and should only be used as a last resort.
In case you are not able to whitelist based on SPF you can get the IP's addresses from resolving the SPF record service-now.com and all sub SPF records, you can get this information from any web resource that resolves SPF records available on the Internet. I would suggest Sender Policy Framework (SPF) Record Lookup - SPF Check - MxToolBox.
To get your SPF records from MxToolBox:
- Go to Sender Policy Framework (SPF) Record Lookup - SPF Check - MxToolBox
- Type service-now.com in the Domain name box and click SPF record lookup.
- Once you click the button, you will need make sure you note down all the IP addresses
- Repeat steps from 1 through 3 for all entries that have type include _spfinc1.service-now.com, _spfinc2.service-now.com
- Write down the IP's for all of the sub SPF records that are not already recorded on step 3.
For more information on this workaround can be found in Enabling Email Delivery Using SPF Records to Whitelist ServiceNow Email Servers (KB0535456).
Once you gather all the IP's this will be the IP's you would have to whitelist. I do not recommend this method though, this is not good practice. If you can, please please please whitelist based on SPF records. Whitelisting on SPF records is good practice as it is not subject to change like using IP addresses.