ServiceNow Email Troubleshooting Tips

Go to System Properties > Email Properties

Navigate to Email Accounts

SMTP protocol is responsible for sending emails
POP protocol is responsible for receiving emails

Open the email accounts to test connection :

Navigate to System Diagnostics > Email Diagnostics

Check the Email Reader Job in the related links to confirm whether the email reader job is running or not.

For user-level troubleshooting, go to the individual users and validate if they an account email.

Notification device validation.

The account email and the email notif device should be in sync (via a business rule).

Managing bounced emails

These emails indicate that they were bounced back, meaning email addresses are automatically blocked after reaching a default threshold of 10 failed delivery attempts or bounced emails.

Navigate to System logs > Emails

If the incoming emails are not showing up in the emails log, that means that SN never saw them (which means that it's not a SN issue - the issue occurs on top of or before they come into the system).

The advice to troubleshoot these type of issues is to double check your spam filter; your email accounts; Office 365,

Another issue may occur when the phishing email has been created, but somehow the security incident was not generated based on the 'Create Phishing Email' inbound action.

In that case, have a look into Security Incident Phishing Emails (sn_si_phishing_email):

And confirm the security incident field is empty - even though the ingestion rule was triggered:

In that case, the most likely root cause of the issue lies in the Transform Phishing Email flow that you can access in the workflow.

Go to:

Workflow Studio > Flow

Search for:

Transform Phishing Email to Security Incidents

You may find the OOB ServiceNow flow in Read Only mode.

Check whether you have an active copy of it.

ServiceNow confirms that the flow is automatically launched for a newly created phishing-email record whose state is New. After successful processing, the phishing record's state becomes Processed, and the Security Incident reference is populated.

Check Flow Executions

This is the next thing I'd do before changing any configuration.

Open the active copy of Transform Phishing Email to Security Incidents and select Executions.

Search around what time the phishing email was created.

For example:

2026-10-05 21:20:18

PHIS0010005 was created at approximately that time.

There are two important outcomes.

No execution exists : this strongly points to the flow being inactive, the wrong flow/version being active, the record trigger not matching, or the required Security Operations Spoke/configuration not being installed/active.

An execution exists but is Failed/Error/Cancelled : open it and identify the first failed action. That will probably give you the actual root cause immediately.

In particular, inspect the steps around aggregation and Create Security Incident.

For troubleshooting inbound emails or emails that are coming in (into SN), check the Email Log in the related tab

These email logs show you what's going through all of the inbound action. These logs indicate if the inbound action failed or succeeded.

You can also preview the email.

Navigate to System Policy > Email > Inbound Action

That's a wrap!

Resources