Email FAQs and troubleshooting notification emails

  • Release version: Yokohama
  • Updated January 30, 2025
  • 3 minutes to read

    • 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.