Domain reputation, sending-IP reputation, and URL reputation concern different objects. A message can use your brand domain, an ESP's shared IP, and a third-party tracking domain at the same time. When placement changes, identify which objects actually changed and what evidence concerns each one. Moving to another IP does not erase all domain or link-related conditions, and replacing a domain does not automatically repair an infrastructure problem.
Inventory the objects on a received copy
Record the visible From domain, envelope-sender domain, passing DKIM signing domain, and observed public sending IP. Extract the actual link destinations and redirect domains from the final rendered message. The hostname of your public website is not necessarily the mail server, and the visible text of a link can differ from its target.
Keep these values with the send time, route, and observed folder. The same brand can send through several systems, while a shared ESP pool can carry traffic for many unrelated senders. Without a copy-level inventory, a change in outbound infrastructure can be misdiagnosed as a change in your domain's standing.
Attach evidence to the correct object
An IP blocklist finding concerns the queried IP and that list's rules. It does not prove that every receiving provider uses the list or that the visible From domain is listed. An IP-oriented provider dashboard likewise needs the appropriate ownership and coverage context. Microsoft SNDS, for example, offers information about controlled sending infrastructure and feedback; it is not a universal score for every domain and receiver.
Domain-related provider information can reflect authenticated sending streams under that provider's definitions. A URL warning concerns a linked domain or destination, which may belong to a redirect service rather than your sending domain. Preserve the exact source, lookup time, and queried object. A generic reputation label should not merge these findings into a single unexplained verdict.
Compare changes with a stable baseline
If a placement decline follows a migration, compare the old and new route inventories. Did the sending IP change, did DKIM remain aligned, did the bounce domain change, and did the new platform rewrite links? A migration often changes several variables at once. That makes it especially important to correct established configuration defects before declaring a reputation cause.
For a suspected link problem, compare a legitimate controlled variant while retaining the rest of the route and required message facilities. For an infrastructure issue, obtain transport responses and provider evidence relevant to the actual IP. One improved seed result can support an operational decision, but it does not reveal the private reputation model or establish that a domain is universally safe.
Assign remediation to the responsible owner
Your DNS administrator may control signing and bounce-domain records. The ESP may manage shared-pool allocation and abuse response. A marketing application may control tracking redirects. Determine who can correct the identified condition and provide them with the precise copy, object, timestamp, and supporting evidence.
Avoid unnecessary identity rotation as a substitute for investigation. Repeated changes can introduce new authentication and operational problems while leaving audience expectation or broken links untouched. Preserve legitimate sender identities and fix demonstrated defects. Document unresolved hypotheses so the team does not mistake a migration for a complete reset of every signal.
Frequently asked questions
Does a clean IP prove the domain is healthy?
No. It establishes only the checked IP finding within that source's scope. Other identities, content, and receiving-provider signals require their own evidence.
Can shared-IP neighbours affect my route?
Shared infrastructure can carry multiple senders, but the exact impact depends on receiver behaviour and provider management. Investigate evidence rather than assuming every problem belongs to a neighbour.
Is a tracking domain authenticated by my DKIM?
A signature can cover message content containing a link. It does not certify the destination's reputation or make that domain equivalent to the signing domain.
Sources and scope
Source check: November 5, 2026. Source checking is separate from publication. Observations apply to the tested copies and conditions.