Email FAQs and troubleshooting notification emails

Release version: Zurich

Updated July 31, 2025

3 minutes to read

Summarize

Summarized using AI

Summary of Email FAQs and troubleshooting notification emails

This content provides guidance for ServiceNow customers on monitoring, diagnosing, and troubleshooting notification email issues within their instances. It covers how to verify email sending and receipt, interpret logs, and access troubleshooting resources to resolve common email-related problems affecting inbound and outbound communication.

Show full answer Show less

Key Features

Logs and Diagnostics: Tools are available to track the health of email communication, including system email logs, message logs for individual emails, and diagnostic pages showing email configuration and job statuses.
System Mailboxes: Filtered views like the Sent, Failed, and Junk System Mailboxes help identify the status of individual emails, whether successfully sent, failed, or bounced.
SMTP Sender Job and Retries: The SMTPSender job sends emails and manages delivery retries using an exponential back-off mechanism for transient (4xx) failures, while permanent failures (5xx) are not retried. Special handling applies to address validation errors with fixed-interval retries.
Error String Field: This field in email records can provide additional error details, although some email servers may not return error strings.
Troubleshooting Knowledge Base (KB) Articles: A curated list of KB articles addresses specific issues such as inbound/outbound email failures, duplicate emails, SMTP job stalls, connection failures, and special cases like Outlook sending RTF formatted emails.

Practical Guidance for Customers

To verify if a notification email was sent successfully, check the Sent and Failed System Mailboxes and inspect the message log and error string of the specific email.
If an email is not received by the end user, review the Junk System Mailbox and email logs for received-ignored entries indicating bounced emails.
Use the Diagnostics and Connection page to assess overall email configuration and job health.
Apply the suggested KB articles to resolve common inbound/outbound email problems and specific error scenarios.
Be aware of the exponential back-off retry mechanism for handling transient SMTP delivery failures and how to interpret retry statuses.

Related Concepts and Next Steps

To enhance email notification management, customers can explore related features such as creating notification categories, configuring email templates and layouts, managing email retention and watermarks, and using the email notifications and diagnostics dashboards.

Logs and diagnostics are provided to help determine whether notification emails are being sent and received successfully, what any issues are, and who receives the email.

Diagnostics help monitor the overall health of the system and troubleshoot general problems, such as not receiving any incoming mail. Logs help identify problems with individual emails, and different logs are useful for diagnosing different types of problems.

Log checking scenarios


Problem	Log
Need to check whether an individual notification email was successfully sent	Check the Sent System Mailbox for that email. Also check the Failed System Mailbox for failure notifications.
Individual email failed	Check the message log of the individual email. Check the Error string field of the email record. Warning: Some email servers do not return error strings
Email not received by end user	Check the Junk System Mailbox for notifications about returned emails. These emails also appear in the Emails log with a Type of received-ignored. Check the Error string field of the email record. Warning: Some email servers do not return error strings Check the message log of the individual email for the reasons different recipients were included or excluded.

Email FAQs

Troubleshooting resources

See the following resources on troubleshooting inbound and outbound email problems.


Error or symptom	Solution
Inbound Email FAQ	See KB0957760.
Instance not receiving inbound email	See Inbound email troubleshooting, ServiceNow KB0524472 and KB0520595. These KB articles also provide links to a video series on troubleshooting inbound emails.
Instance not sending outbound email	See Troubleshooting Outbound email, ServiceNow KB0521382. This KB article also provides links to a video series on troubleshooting outbound emails.
Email from Outlook produces an empty Incident record containing an attachment named winmail.dat.	Configure the local Outlook client or Exchange server not to send Rich Text formatted (RTF) data to the instance.
Emails are getting set to type send-ignored for no obvious reason	See KB0790932.
Duplicate emails generated by the instance	See Troubleshooting duplicate emails generated by the instance, KB0529413.
SMTP Sender Job Stuck	See SMTP Sender Job Stuck > 30 Mins alert, KB0755061.
Connection to smtp.office365.com failed	See KB0825391.
IMAP with OAuth error AUTHENTICATE failed	See KB0963959.
Error connecting the POP email account on secure port	See KB0829289.
Inbound email processing is stuck alerts	See KB0855277.
Email Reader / SMTP Sender job stuck	See KB0679998.
Email Reader Job stuck/running for more than 2 hours alerts	See KB0755063.
SMTP retries	The SMTPSender job is responsible for sending emails from the instance and at times there can be delivery failures during transmission. Emails that aren't successfully delivered might need retries. Exponential back-off retries is a mechanism to redeliver them in the interval (1, 5, 10, 20, 40, 60, 120, 120) between the retries. The exponential retries continue until the lookback period mentioned in the glide.email.smtp.claim.lookback.hrs system property is lapsed. The retries are attempted for 4xx status codes and for all other status codes such as 5xx are considered as permanent failure. The glide.smtp.fail_message_ids and glide.smtp.defer_retry_ids system properties aren't considered. Retried emails type is set to send-retry-backoff.

Exponential back-off retries

Emails that aren't successfully delivered might need retries. Exponential back-off retries is a mechanism to redeliver them in the interval (1, 5, 10, 20, 40, 60, 120, 120) between the retries. The exponential retries continue until the lookback period mentioned in the glide.email.smtp.claim.lookback.hrs system property is lapsed.

The retries are attempted for 4xx status codes and fail for 5xx status codes during the email delivery. The glide.smtp.fail_message_ids and glide.smtp.defer_retry_ids system properties aren't considered.

Retried emails type is set to send-retry-backoff.

Note:

Address validation errors that occur during the email delivery are handled differently. The type of email record is set to send-retry-delayed and the email delivery is retried in fixed intervals of 30 minutes until the lookback period is lapsed.