Shared egress is not a shared business identity
Two applications can reach a receiver through the same outward-facing mail infrastructure while belonging to different customer accounts and serving different business purposes. An IP-only inventory can therefore merge legitimate services, unknown accounts and unrelated traffic into one misleading identity. The corrective habit is to group infrastructure for investigation while keeping service attribution and approval at the account-and-purpose level.
This guide uses primary standards and provider documentation reviewed on 8 November 2026. It contains a fictional comparison, not an attribution of any real source. No report, provider account, DNS record or delivered message was accessed. There is no claim that EmailAuth performs these correlations or that a particular provider caused a customer incident.
Understand what a shared pool establishes
Amazon SES's pool documentation describes shared addresses as well as dedicated pool choices. That is concrete first-party evidence that an address need not uniquely identify a customer. It does not establish which pool a real stream used, and it does not mean that every provider has identical allocation behavior. Account, region and configuration evidence must come from the actual service under investigation.
A dedicated address narrows one infrastructure relationship but still does not supply an application owner or business approval. A single account can support several workflows, and account arrangements can change. Avoid a rule that treats shared infrastructure as suspicious or dedicated infrastructure as trusted. The question is which evidence connects this observed stream to the intended service and authorized use.
Keep the authentication identities attached
RFC 9990 reports more than a connecting address. The relevant record includes message identities, authentication results and the DMARC evaluation context. Preserve these distinctions when grouping observations. Rows with the same IP but different From domains or signing identities should not lose their separate evidence because a dashboard label happens to be the same.
A DKIM signing domain can help distinguish streams, but it is not a unique customer-account identifier by definition. RFC 6376 associates a signature with a signing domain and selector. Several applications can use a domain, selectors can rotate, and provider-held signing infrastructure can support many customers. The investigator still needs the service's own account and configuration records to make a specific attribution.
Examine the cross-customer authorization boundary
RFC 7208 section 11.4 explains that SPF host authorization does not generally establish which individual user of an MTA may use a particular address. The mail service must enforce its own controls against cross-user forgery. This is a protocol limitation to account for, not an allegation that a named provider permits abuse.
Do not respond to an uncertain shared-IP observation by authorizing a broad provider network. Such a change can enlarge host authorization without resolving the account question. Before proposing SPF or signing changes, identify the documented configuration for the exact product and customer identity. Approval of one application's purpose is not blanket permission for every account using the same network.
Compare two fictional candidates
Imagine Atlas Billing and Beacon Surveys, two invented services whose reports appear behind the same illustrative egress address, 198.51.100.24. No real provider is assigned to that address. One candidate is expected to send invoices; the other is expected to send surveys. In the paper case, neither account identifier nor representative message has yet been supplied, so both remain candidate mappings.
The useful investigation asks for the two service configurations, their permitted domains and their business owners. If later authorized evidence associates an invoice stream with one account and a survey stream with another, the mapping can be recorded separately even if egress remains shared. Without that evidence, a combined “approved shared provider” entry would hide the uncertainty rather than resolve it. The paper exercise has not completed those later steps.
Resolve contradictions without collapsing the evidence
Suppose the owner recognizes a vendor but the observed signing domain differs from the expected setup. Possible explanations include another product, a reseller arrangement, stale configuration or a different customer account. These are hypotheses to test, not findings. Preserve the conflicting identities and ask the responsible administrator for the precise configuration version and route rather than changing the inventory to match the most familiar name.
Infrastructure records can support the inquiry but cannot settle it. ARIN's Whois guidance describes registration information about networks and associated organizations. A network registration may identify the resource holder or reassigned organization, not the application that submitted an individual message. Record the source and date, then keep that layer separate from customer-account evidence.
Choose grouping keys that preserve the service boundary
A proposed working view can group by provider for workload planning while retaining customer, domain, purpose and account as separate dimensions. Do not deduplicate distinct service records merely because an IP, ASN or provider label matches. Likewise, do not split one service into a new approved vendor every time a provider rotates egress. The service record should explain the relationship between stable business responsibility and changing infrastructure.
Review permissions at the same boundary. A technician may investigate an approved evidence sample without permission to access another customer tenant or send the sample to a provider. External sharing, credential setup and DNS edits require their own authorized scope. A suspected mismatch can remain unresolved while an accountable owner gathers the missing evidence; uncertainty is safer than a fabricated attribution.
Retain the missing demonstration as a release gate
The exact intake requirement is still open: Validate current primary specifications and retain a worked example before drafting. Current standards and the fictional two-service case support this documentary draft, but original operational evidence has not been obtained. The catalogue specifically requires: A redacted report-to-decision walkthrough with source fields, classification uncertainty and next action.
That eventual walkthrough must show how the actual shared infrastructure was related to a particular customer account, which alternatives were considered and who approved the resulting service classification. A provider logo, a recognizable reverse-DNS label or an IP match cannot substitute for it. Keep the draft unpublished until the independent technical review, customer-specific evidence and owner release decisions are complete.