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.
