A shared IP pool creates a real dependency on a sending service and its other traffic. It does not remove the customer's responsibility for its own messages. Diagnose the shared infrastructure and the customer's authentication configuration in parallel so one explanation does not conceal the other.
Separate pool ownership from message ownership
Amazon SES documents shared addresses used by multiple customers and dedicated alternatives with different operating characteristics. That is a concrete example of a service-controlled pool, not a description of every provider's routing product. Obtain the actual pool and service details for the account under investigation. SES IP options.
The customer usually controls business intent, recipient selection and some domain settings, while the service controls outbound infrastructure. Write down the actual division rather than assuming it. Identify who can repair signing, envelope-domain configuration, suppression propagation and IP routing, since those may be different teams.
Verify the customer-specific authentication path
Inspect a final message from the affected stream. Record the signing domain and selector, visible From domain and envelope identity, together with the actual receiving evaluation. DKIM verification concerns the signed message and published signing key; an IP reputation problem does not itself explain a broken signature. RFC 6376.
Check whether a gateway altered signed content or whether a custom-domain setup was never enabled for the account. A correct public key does not prove that the service signed the sample with it. Preserve the exact message revision and DNS evidence before making a change.
Use a comparison that can distinguish causes
Compare another authorized stream on the same pool and the affected stream through a controlled alternate route only if such a test is available and approved. Keep destination, content and recipient conditions as comparable as practical. Do not send unwanted mail or bypass a provider restriction merely to generate a test.
Suppose two hypothetical streams share a pool: one has a corroborated signing defect, while both encounter a similar route diagnostic. That calls for two investigations, not a choice between them. Confirm the first stream's signing configuration and ask the infrastructure owner to explain the actual refusal. A common diagnostic alone does not prove that reputation caused it.
These are invented facts for a decision example, not an executed rules check or signature test. A production finding requires actual trusted receiver or cryptographic evidence and route-specific transport records.
Escalate without oversharing
Give the service owner the relevant IP, timestamps, destination service, precise response and redacted message identifiers. Ask whether the route changed, whether an incident is known and what further evidence is required. Do not request other customers' private traffic or present a third-party blocklist listing as proof of every receiver's behavior.
Continue correcting verified local defects while the provider investigates shared infrastructure. If a migration is proposed, require a plan that preserves authentication, suppression and critical-message continuity. Moving an already broken configuration can preserve the problem while adding a new reputation ramp-up.
Close the two tracks independently
Mark the customer authentication repair complete only after a new sample demonstrates the corrected route. Mark the pool investigation complete only with its own supporting outcome or clearly stated unresolved limitation. Keep recipient complaints and placement observations distinct from both.
This separation gives the business a usable report: what it controlled and fixed, what the provider established, and what still requires evidence. Shared infrastructure is a dependency to manage, not a blanket explanation for every delivery failure.
Close a repaired signature without closing the route case
In a hypothetical follow-up, an authorized sample from the same stream now has a trusted DKIM pass, but a later message still receives the relevant temporary transport refusal. Record which message each result concerns and preserve the IP, recipient service and times. Do not join unrelated daily warnings simply because they share an IP.
The signing repair can be supported by its new sample while the route issue remains open. Ask whether content, recipient class or routing changed between samples before generalizing. This teaches independent closure, not a measured provider recovery or a reason to migrate immediately.
Keep customer repair and pool investigation separate
- Verify the affected message’s signing and evaluated identities.
- Retain actual route, destination and diagnostic evidence.
- Assign the configuration owner and infrastructure owner explicitly.
- Close each supported defect on its own corrected outcome.
- Share only the narrow authorized incident data; do not request other customers’ traffic.