Begin at the trusted receiving boundary

Open the original message and identify headers added by the mailbox provider or gateway you control. Received fields are prepended as a message moves, so read the trace with trust boundaries in mind rather than assuming the visually first or last IP is always the original application host. Headers supplied before your trusted boundary can be forged.

Look for the receiver’s Authentication-Results or Received-SPF evidence. A receiver may report a client IP alongside the SPF identity. Record the IP, the receiving host that observed it, and the timestamp. For example:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.net
Received: from outbound.example.net (outbound.example.net [192.0.2.40])
  by mx.receiver.example with ESMTPS ...

192.0.2.40 is documentation space, not a real sending address. In this simplified example, it is the peer seen by the receiver. It does not prove which application generated the message or whether every message from the brand uses that infrastructure.

Account for gateways and forwarding

An inbound security gateway may receive the internet connection and then relay internally. A forwarding service may become the connecting client for the final receiver. In those cases, record both the hop and its role. The relevant IP for a blocklist investigation depends on which system made the decision and which list was consulted.

Do not resolve the visible From domain and call its A record the sending IP. Do not use the URL in the footer. Website hosting, tracking, return-path, and SMTP infrastructure can all be separate.

Cross-check with sender evidence

Match the receiving observation to your sending provider’s event using message identifiers and time. Confirm whether the IP belongs to a shared pool, dedicated allocation, customer gateway, or forwarder. Use the provider’s official range information where available, but prefer the IP observed on the affected message.

Record a defensible conclusion

Write: “Receiver X observed 192.0.2.40 connecting for message Y at time Z.” Avoid: “Our company’s sending IP is permanently 192.0.2.40.” Repeat with representative streams if you are building an inventory. When no trusted trace is available, mark the IP unknown and request evidence instead of checking a convenient but unrelated server.