Why might the original sender's IP address not appear?¶

The complete header may show the mail servers that delivered a message without showing the IP address used by the person's phone or computer. That is normal for webmail, provider submission services, business platforms, relays and automated systems. The user's connection may instead exist in provider account, sign-in, session or audit records.

Start with what the header actually records¶

In the supplier-payment investigation, the recipient's system records an external mail server at 203.0.113.84. That address identifies the infrastructure handing the message into the recipient's environment. It is not automatically the address used by the person who created the message.

The record gives the investigation a service, delivery event, time and provider identifier. Those details can frame an enquiry capable of identifying the account or submission event behind the message.

Modern email commonly separates the user from external delivery¶

If somebody uses webmail, their browser connects to the email provider. The provider accepts or constructs the message inside its own service. Its outbound mail server then delivers the message to the recipient.

Many mobile and desktop applications work similarly. The device submits the message to an authenticated service; the provider relays it through internal and boundary systems. Some providers deliberately do not add the user's client address to the externally delivered header, avoiding unnecessary disclosure of network and location information to every recipient.

The provider may still hold the user connection in security, sign-in, session, audit or submission records. It simply is not part of the copy delivered to the recipient.

Other systems can move the visible route further away¶

The question may therefore need to change from “Where is the sender's IP?” to “Which account, tenant, workflow or API event caused this message to be delivered?”

Sometimes the evidence is incomplete¶

A client IP may also be missing because the investigator does not have the native original message. A screenshot, printout, inline forward or copied header extract can remove the technical route. A gateway may transform the message, a provider may remove internal fields, or the relevant lower Received line may be untrusted.

Preserve the original before concluding that the value never existed. Then work through the Received chain from infrastructure you trust rather than selecting the first IP address that looks promising.

The provider may hold a better route to attribution¶

Depending on the service and event, provider or organisational records may include:

Not every provider holds every record, and retention periods vary. Use the exact message identifiers, recipient, account, timestamp and sending infrastructure already preserved to frame a defined and proportionate preservation or disclosure enquiry.

Decide whether the client IP is actually necessary¶

An IP address is one possible link - not the prize at the bottom of every email header. A provider may be able to link the message directly to an authenticated account, session, managed device, API credential or business process. Those records may advance the investigation more effectively than a network address shared by several users.

The useful question is which evidence can identify or test control of the account or system that caused the message. Sometimes that includes a client IP. Sometimes it does not.

Move from the message to the next holder¶

1. Confirm what you possess

   Obtain the native message and complete header because a screenshot or forward may have removed the route before you received it.

2. Identify the trusted boundary

   Work from Received fields added by the recipient's systems because lower sender-supplied fields may be incomplete or invented.

3. Classify each address

   Establish whether an address belongs to a mail server, relay, platform or client connection because the same field label does not make them equivalent.

4. Preserve the delivery identifiers

   Retain the full time, Message-ID, provider identifiers, sender and recipient because they may allow the service to locate the submission event.

5. Identify the next record holder

   Determine which provider, tenant, organisation or platform operated the recorded infrastructure because its internal records may bridge the missing client stage.

6. Ask for the record that answers the case question

   Seek account, session, device, audit or platform evidence because attribution may not depend on recovering a client IP at all.

Avoid the two dead ends¶

“No user IP appears, so the email cannot be investigated” ignores the account, provider, platform, device and contextual evidence around the message.

“This mail-server IP must show the sender's location” mistakes infrastructure for the person using it.

The accurate conclusion is that the recipient-visible header identifies part of the delivery route. The next enquiry moves into the service that handled the earlier stage.

The point to remember¶