Hello @davidschull,
From an enterprise architecture and data governance perspective, this is a classic example of cross-system data contamination, but it represents zero risk to your organization's infrastructure.
When you operate as a customer of a massive SaaS provider, your corporate identity (your email address) exists in multiple external databases: their CRM (Salesforce), their support ticketing system, and their internal ServiceNow instance (SURF).
What you are witnessing here is a data governance failure within ServiceNow's internal operations. There are two primary architectural reasons this happens:
Manual Data Entry Error: An internal facilities administrator at ServiceNow manually typed an email address for the Boston Kiosk Operator, fat-fingered the entry, and accidentally selected your externally federated contact record from their global address list.
Sub-Production Cloning: ServiceNow may have cloned their production SURF database to a lower development environment for testing. If they failed to run data obfuscation scripts (data masking) on the contact tables, and subsequently left outbound email enabled on that sub-production instance, it can easily blast test notifications to real external customers.
Rest assured, this event occurred entirely outside of your organization's ServiceNow instance. Your instance architecture, data boundaries, and security perimeters remain completely intact.
