The use-case is: your customer has a long established e-mail address for incident creation and, when implementing ServiceNow, they want this address to be used for inbound email actions and as the "from" address for for system generated emails.

ServiceNow provides the built-in capability to configure your own smtp, imap or pop-3 servers for email. That process is well documented but, with some organizations you will undoubtedly encounter security related issues or at a minimum firewall rules that will prevent you from making a successful connection without the involvement (not to mention approval) of network teams and security teams. Most organizations will restrict the protocols required to make these connections (though you might get lucky and everything will be in the cloud) and finding the right people and the right information could be a challenge.

So, what can you do? The answer is surprisingly simple.

In ServiceNow, go to System Mailboxes > Email Accounts and open the record for "ServiceNow SMTP"

Most of the fields will be greyed out, but the Email user label and From fields will be editable.

Modify the Label to be the "display name" of the email account you will be using and modify the From field to be the email address and update the record.

That would be all you would need to do in ServiceNow itself.

The next step is to have the administrator for the mailbox that the customer wants to use go into their system and configure a redirect so that all email sent to that account is automatically redirected to the email address for your instance. There can be some confusion between "redirect" and "forward" but, the primary requirement here is that the message should be sent to ServiceNow with the original sender header information intact (the message should appear to have come from the original sender and not the first recipient email account). If a "FW:" is added to the message then it won't work seamlessly.

For example, if the customer is using Office 365 an administrator can set this configuration.

A user who has rights to manage the mailbox can also set this configuration.

Using this method (rather than a simple forwarding rule which might remove the original sender from the header) will ensure that the information on the original sender is available to ServiceNow when processing inbound email actions. This allows the incident (or whatever record) to be opened under or matched against the user's record. ServiceNow should accomplish this automatically, unless you've customized the way you are setting the caller.

If you encounter issues, add some logging to your inbound action and check the values of email.from and email.origemail and if email.from is not the expected address, but email.origemail is, then the forwarding rule is not working as expected. You can either resolve the issue with the rule, or you could re-write your process to look up and set the caller based on email.origemail.

On the outbound side all emails from the instance should appear to come from the address that you set and, if a user clicks reply, the email should go to the configured address (not back to the instance email address). I've seen situations where configuring email like this will result in the emails being filtered as spam; of course, I've seen the out-of-the-box address register as spam as well, but it's worth considering if you find users do not see emails arriving in their inbox. This can also result in delays in receiving email if your span filter throttles back bulk senders as, well, ServiceNow can spit out a lot of email in a very short time for a production instance.

There are some potential drawbacks to this approach; forwarding is notoriously difficult to trace when something goes wrong. Messages can disappear into the void never to be seen again with no explanation. If you have strict contractual requirements around email ingestion / response then you might be better served figuring out the smtp / pop3 configuration details.

Some of this seems obvious in hindsight but, I thought this might be worth sharing.

If you found this article helpful or useful, please be kind and click appropriately. If you found it really useful, you could always use the 3-dot menu to bookmark it for later!

Michael Jones - Proud member of the CloudPires team!