Best Practice for Custom Sender Email Domain in ServiceNow (External SMTP vs. DNS Authentication)

Shiny-Syslabo · 3 weeks ago

Hi geniuses, I need your help!

We are currently working on a ServiceNow App Engine implementation and looking into changing the sender email address for outgoing emails.

Instead of the default @Service-Now.com, we want to use our client's custom domain.

We are considering the following two patterns and would love to hear your thoughts on which is the best practice, along with any real-world case studies or lessons learned.

Pattern A: Routing through the client's SMTP server

Approach: Disable the default ServiceNow SMTP server and route all outgoing emails through the client's own mail server.

Pattern B: Modifying the "From" address and updating the client's DNS

Approach: Keep using the default ServiceNow SMTP server, but change the "From" and "Reply-to" headers to the client's custom domain.
DNS Updates: To prevent spoofing/spam flags, we planned to add ServiceNow’s SPF record to the client’s DNS.
Current Test Result for Pattern B: We tested changing the "From" address. The emails are delivered, but they trigger a warning in the recipient's inbox saying "Sender could not be verified" (or showing "via service-now.com").
(Note: We are not network/DNS experts, but we understand we need to make further DNS adjustments to resolve this warning.)

Our Questions:

Do you have any experience or case studies implementing Pattern A or Pattern B in your past projects?
Which approach is generally recommended as the best practice?
For Pattern B, what specific DNS configurations (SPF, DKIM, DMARC, etc.) are required to completely get rid of the "Sender could not be verified" warning?

Any advice, pros/cons, or gotchas you could share would be highly appreciated!

Thank you in advance!

GlideEdward · 3 weeks ago

Have direct experience with this. When started working at that org, it was a greenfields implementation that had pattern A configured.

I strongly recommend pattern B, especially if your client's email service is M365 / Exchange Online due to the daily email hard sending limits.

Ref:

Exchange Online limits - Service Descriptions | Microsoft Learn

Note that this is recipients not messages.

So for example, if your Service Desk group has 20 members, every time a notification is sent to that group, it counts as 20 recipients from the total. That's only 500 notifications allowed to the Service Desk per day before we even start thinking about end user notifications!!

Once that limit is hit, the emails just get eaten up by the mail server... no error messages, or bouncebacks.

We had 90 people in our SD group, so as you can imagine we had to migrate to pattern B ASAP!!

From memory, we had to do this:

1) Set up SPF

2) Set up DKIM

(ServiceNow documentation on this is excellent, so recommend you look up the KB articles on NowSupport for specific instructions)

3) Once that was done, DMARC passed with no issue

4) Note that you will need to ask your email admins to set up an email forwarder / transport rule to redirect mails sent to your @yourcompanydomain address back to the instance address. This is preferable to using the reply-to field as it means you can then publish the @yourcompanydomain address for 'New' emails for inbound actions / inbound email flows (if you allow such a thing).

Doing this also opens up the possibility of being authorised to send from multiple addresses @yourcompanydomain which can be configured on a per-notification basis. This can be very nice if you have multiple functions using ServiceNow (IT, HR, Facilities, etc...) who may want to have their own branding / contact emails.

I'd recommend opening up the conversation with your email admins ASAP as they are the experts in this domain, and will be doing most of the work needed to set it up for you.