How emails with duplicate Message ID's are handled in ServiceNowSummarySome customer email systems can send SN instances multiple emails with the same Message-ID. By default the instance will save the first email into the [sys_email] table, and then silently drop any subsequent ones with the same Message ID. In order to see the emails with duplicate Message ID's that are being dropped, ensure the system property glide.email.debug is set to type true|false and value true. Emails that are dropped due to being duplicates will be logged as, for example: 2020-01-22 10:07:06 (056) worker.5 worker.5 txid=12f345bc1ba6 Message UID='00123f4e56789745' Message-ID='<AJGHEYTISMBTHAYAAAAAAAAAMEul/ioeqdYUIO1jyq7tY3CgAAAEAAAAICPx8Ch0U1Bu2IX+wLq2D0BBBBB==@example.com>' was previously read and will be ignored. On more recent ServiceNow releases, the log message might look like: 2023-02-20 04:23:21 (041) worker.2 worker.2 txid=203c7c30dgds Message UID='01475aef57822l4p' Message-ID='<AJGHEYTISMBTHAYAAAAAAAAAMEul/ioeqdYUIO1jyq7tY3CgAAAEAAAAICPx8Ch0U1Bu2IX+wLq2D0BBBBB==@example.com>' was previously read (sys_id of email='684cbc30dbcd29d051f961bb139665b3') and will be ignored ReleaseAll current ServiceNow versionsInstructionsThe default behaviour can be changed by setting the system property glide.email.allow_duplicate_message_ids (of type true|false) to the value true. This change has implications, in particular that matching of reply emails based on the In-Reply-To header will pick up a random email from the duplicates. After this change has been applied the emails with duplicate Message IDs will be stored on Email[sys_email] as normal. However note that when searching on the Email[sys_email] table for emails with duplicate Message ID you must search by Type (e.g Received) and Message ID, otherwise the system will not be using the out-of-box index on type,message-id. Related LinksThe ServiceNow platform by default assumes that Message IDs are unique. Ref. 3.6.4. Identification Fields in relevant specification https://tools.ietf.org/html/rfc5322#section-3.6.4 : Though listed as optional in the table in section 3.6, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate and as described below. The "Message-ID:" field contains a single unique message identifier.