- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 02:17 AM
The docs say that we need to define an email address such as acme+phishing@service-now.com as the forwarding address for the possible phishing emails.
https://docs.servicenow.com/bundle/london-security-management/page/product/security-incident-response/task/create-email-matching-rules.html
Can anyone clarify how/where exactly we do this? Is this just a pop3 account set up by admin in System Mailboxes > Administration > Email Accounts or is it one of the email addresses configured in Security Operations > Email Processing > Properties (if so, which one)?
Solved! Go to Solution.
- Labels:
-
Security Incident Response

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 08:36 AM
Hi Steve,
You are correct; in this case, the docs is referring to a newly defined email address would be introduced as a new 'pop3' account, setup by an admin in System Mailboxes > Administration > Email Accounts.
This configuration nicely separates the inbound emails ServiceNow receives, so that the logic you define for configurations like 1) SecOps Email Processing and 2) User Reported Phishing, can take advantage of this explicit mailbox.
This approach - i.e. having a dedicated ServiceNow mailbox for SecOps purposes, along with a corporate / enterprise mail account and forwarding rule that your tools and users interact with, is an effective solution and provides a higher level of assurance around email messages received in ServiceNow being handled as expected.
This approach is not necessarily mandatory to successfully use 1) SecOps Email Processing and 2) User Reported Phishing; it is strongly recommended to investigate using this approach and design.
You can still leverage your <instance@service-now.com> email address for 1) SecOps Email Processing and 2) User Reported Phishing, and attempt to build your filtering / logic around context within an email message subject, email message sender, etc - it is just not as effective as using an explicit mailbox that functionally handles SecOps related email messages.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 02:33 AM
Hi Steve,
please check the following procedure:
Create rules to validate user-reported phishing attacks
If I have answered your question, please mark my response as correct so that others with the same question in the future can find it quickly and that it gets removed from the Unanswered list.
Thanks you
Cheers
Alberto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 08:34 AM
Hi Alberto,
I am afraid you have not answered my question. I placed the same docs link in my original question that you provided in your answer!
Please note that I am asking where I need to set up the email address, that is mentioned in the docs article:
"Define an email address such as acme+phishing@service-now.com. The +phishing tag is supported by SMTP to enable filtering and your instance can receive emails sent to it."
My question is where do I define this?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 08:36 AM
Hi Steve,
You are correct; in this case, the docs is referring to a newly defined email address would be introduced as a new 'pop3' account, setup by an admin in System Mailboxes > Administration > Email Accounts.
This configuration nicely separates the inbound emails ServiceNow receives, so that the logic you define for configurations like 1) SecOps Email Processing and 2) User Reported Phishing, can take advantage of this explicit mailbox.
This approach - i.e. having a dedicated ServiceNow mailbox for SecOps purposes, along with a corporate / enterprise mail account and forwarding rule that your tools and users interact with, is an effective solution and provides a higher level of assurance around email messages received in ServiceNow being handled as expected.
This approach is not necessarily mandatory to successfully use 1) SecOps Email Processing and 2) User Reported Phishing; it is strongly recommended to investigate using this approach and design.
You can still leverage your <instance@service-now.com> email address for 1) SecOps Email Processing and 2) User Reported Phishing, and attempt to build your filtering / logic around context within an email message subject, email message sender, etc - it is just not as effective as using an explicit mailbox that functionally handles SecOps related email messages.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 08:49 AM
Thanks Andy!! This is very useful. It would be great if the docs explicitly explained that the email account needs to be defined in System Mailboxes > Administration > Email Accounts.
The reason I say this is that a Security Incident Admin can access the addresses in the email properties module of the Security Incident common application but not System Mailboxes > Administration > Email Accounts. This means the instance Sys Admin would have to do this on their behalf which should be made clear.