An email can carry several domain identities while arriving from one visible connecting IP. Asking whether “the reputation” is good hides those distinctions. Start by naming the address or domain that each source evaluates and the receiving service that produced the signal.
Separate identity from reputation
DKIM establishes an association between a signed message and a signing domain. It does not by itself declare the content wanted or safe. A valid signature can accompany unwanted mail. RFC 6376.
Similarly, an IP address identifies the observed network origin at a hop, which may be a shared service or translated address. Reputation is an evaluator's assessment of observed behavior, not a transferable certificate. Google exposes distinct IP and domain reputation views, while Microsoft SNDS provides IP-oriented telemetry. Google’s Postmaster data covers personal Gmail traffic, is not real-time and can omit low-volume data for privacy. Microsoft SNDS provides Outlook.com IP observations for authorized address owners. Preserve those scopes rather than merging the views into an invented universal score. Postmaster dashboards, SNDS.
Create an identity map for the failing stream
Record the connecting IP, visible From domain, envelope sender domain and DKIM signing domain. Preserve the provider route and message revision too. If a service signs with its own domain while the visible From uses the customer's brand, write both explicitly. “Domain reputation is bad” is incomplete unless it names the domain and source of that assessment.
Compare affected and unaffected traffic using the same dimensions. One IP can carry multiple brands; one brand can use multiple IPs. A new route can change the IP without changing the brand, while a custom-signing rollout can change the signing domain without moving the connection. Keep these changes in a dated configuration history.
Use the two-by-two example cautiously
Consider a hypothetical two-brand, two-IP comparison. Brand A has unfavorable observations on both addresses; Brand B has unfavorable observations only on the first. That leaves both a brand-associated pattern and an IP-associated pattern worth investigating. It does not identify a single cause.
These invented labels are not provider scores, and the matrix is not a model of a filtering algorithm. It illustrates confounding: audience composition, content and routing may change together. A real diagnosis needs comparable traffic and independent observations before attributing cause.
Choose corrective work at the right layer
For a route-specific transport failure, retain the actual diagnostic and ask the infrastructure owner to investigate. For complaints concentrated in one program across several routes, inspect permission, expectations and suppression with that program's owner. For failed authentication, examine the evaluated identity and configuration directly rather than hoping a reputation improvement will make the failure disappear.
Avoid presenting a new IP or domain as a clean slate. Changing infrastructure does not remove the need for wanted mail, correct identities and reliable complaint handling. It may introduce new operating work and weaken the comparison if every variable changes at once.
Preserve uncertainty in the closure
State which signals were observed, the identities they cover and the actions supported by them. If a provider does not expose a score for a domain, say that data is unavailable rather than infer the score from an unrelated IP chart. Track receiving outcomes separately from inferred causes.
A useful result can be “the issue follows this stream across two routes” rather than “the domain is guilty.” That narrower statement directs the next test without claiming knowledge of proprietary weighting or a guaranteed path to the inbox.
Use a controlled comparison without promising causation
Suppose the next proposed check follows the affected stream through an approved alternate route while preserving content, destination mix and observation duration as far as practical. Before collecting results, state the competing explanations: route-specific refusal, program-specific complaints or a message-level authentication defect.
If the same stream still has problems on both routes, that does not prove a domain score caused them. If one route looks better, audience history and receiving behavior can still differ. Retain the actual diagnostic and the provider's scoped telemetry, and choose the next evidence request that could distinguish those alternatives. This is a hypothetical investigation plan, not a computed reputation model or a measured route improvement.
Assign the next check to the supported pattern
- Map IP, From, envelope and DKIM identities for the actual stream.
- Record the provider, scope and time of each reputation signal.
- Compare streams across routes without treating correlation as causation.
- Investigate route diagnostics, audience complaints and authentication separately.
- If a provider does not expose a score, mark it unavailable rather than infer a universal rating.