Spam filtering and inbound action approach

[Jonathan F]

If you are not familiar with how ServiceNow marks spam, you can review these articles to get caught up:

• Email Spam Scoring and Filtering
• Designate trusted and untrusted email domains
• Sender Policy Framework

At our company, it has been a common practice to generate tickets on older systems by emailing an inbox. As we have moved these request processes into ServiceNow (Catalog Items added to our Service Portal), my team's customers have been consistently adamant about maintaining this ability rather than retraining their user bases to go to our Service Portal. We have a long term goal to change this email heavy culture to a Service Portal culture and get to a small number of inbound actions, but in the meantime we have over 100 Inbound Actions that generate various Incidents to specific teams or RITMs.

Our current approach to ensure that the right emails get to the right people is to set up a Contact in Exchange that instead of routing to an inbox domain controlled by our company, it routs to [instancename]@service-now.com. This is often better than using a regex in the email subject or body, because it's easy to have typos and it could get confusing as to which inbound should be triggering at the time.

The uncovered issue: I uncovered that our emails to ServiceNow using this method are sporadically getting caught by the spam filter. It turns out that according to the standardized Sender Policy Framework (SPF), a mismatched domain between the email address listed and the actual recipient of the email looks suspicious and will consistently trigger the Spam Assassin codes SPF_FAIL or SPF_SOFTFAIL. Most emails aren't suspicious looking enough to trigger the spam filter, but some of them have enough other small dings to the "suspicion score" that they are caught by the spam filter.

I have two related questions on this topic:

1. It looks like if we add our own domain to the trusted email domain list, I think it won't filter it out as spam. I tried it out in dev and noticed that the added headers (including X-ServiceNow-Spam-Status) for filtering spam are still added to the email, but it has been a challenge to figure out the secret sauce to consistently build a suspicious enough looking email to get over the 6.2 score threshold, so I can't demonstrate that this change actually resolved the issue. Can somebody confirm that adding our own domain to the trusted email domain list will ensure that the email spam filter will ignore the headers and never filter out these emails as spam?
2. Does somebody have a better approach for creating 100 different rules that doesn't rely on this trick of routing multiple Contacts to the instance's email address? We could start to move teams that are particularly having this problem to the new method.

Thanks!

[ServiceNow Tec2 · Accepted solution]

This has been resolved by ServiceNow Technical Support. Please refer to KB0549426 (HI login required) for more information.