Skip to content
EML-020 Email Evidence

What can I do with an IP address found in an email header?

title: What can I do with an IP address found in an email header? subtitle: First establish which system recorded it and what that address represented at that point in the delivery route. slug: what-can-i-do-with-an-ip-address-found-in-an-email-header series: email-evidence section: technical-interpretation card_type: question_card pathway_order: 21 section_order: 8 status: draft public_safe: true video_ready: true word_count: 615 estimated_read_time_seconds: 254 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - IP address - Received header - attribution - mail server sources: - title: 'RFC 5321: Simple Mail Transfer Protocol' url: https://www.rfc-editor.org/info/rfc5321/ - title: 'RFC 5598: Internet Mail Architecture' url: https://www.rfc-editor.org/info/rfc5598/ - title: 'Microsoft Learn: Message trace in Exchange Online' url: https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-modern-eac - title: 'Gmail Help: Trace an email with its full header' url: https://support.google.com/mail/answer/29436?hl=en-GB

What can I do with an IP address found in an email header?

First establish which system recorded it and what that address represented at that point in the delivery route.

Script

You’ve found an IP address in an email header.

Before looking it up, ask where it came from.

An email header can contain several IP addresses, and they may represent very different things.

One may be the external mail server that connected to the recipient’s provider.

Another may belong to a security gateway, mailing platform or customer-management system.

A private address may describe a server inside an organisation.

A provider-specific field may record a client connection used to submit the message.

An address copied into an untrusted lower Received line may be false.

The address is only useful once you understand which system recorded it and what that system was describing.

Start with the trusted Received chain.

Identify the first mail server in the recipient’s trusted environment that accepted the message from outside.

The address in that line is often the IP address of the external SMTP server that handed the message over.

That can help identify the sending provider, platform, organisation or gateway.

It may also help correlate the email with message-trace, provider or network records.

But it usually doesn’t identify the device used by the person who wrote the email.

If the message came from webmail, the user’s browser connected to the provider’s web service. The provider’s mail server then sent the email onwards.

The recipient may see the provider’s server address, not the sender’s home, mobile or VPN address.

If the message came through a mailing platform, the visible address may belong to shared platform infrastructure used by many customers.

If it passed through a corporate gateway, the address may identify the organisation’s boundary server.

If it was forwarded, the visible route may begin with the forwarding service rather than the original author.

So classify the address before drawing conclusions.

Ask:

Is it public or private?

Does it belong to the recipient’s provider, the claimed sender’s provider, a third-party platform, a hosting service, a VPN, a corporate gateway or something else?

Which Received line contains it?

Was that line added by a trusted system?

Does the timestamp match the event?

Is a source port recorded anywhere?

Can the provider match the address and time to an account, tenant, campaign or session?

Then preserve the surrounding context.

Keep the complete line, not just the address.

Record the hostname, protocol, timestamp, timezone, Message-ID, Return-Path, DKIM domain, recipient and any provider-specific identifiers.

An isolated IP address stripped from the header may lose the information needed to explain it.

You can then use the IP address as a line of enquiry.

Check ownership and network type.

Identify the organisation likely to hold records.

Ask whether the address was dedicated, shared or part of a large service.

Consider preservation or lawful requests through the appropriate route.

Corroborate it with account, provider, device and content evidence.

Be careful with geolocation.

A mail-server address may geolocate to a data centre, cloud region or provider gateway. That tells you where the infrastructure appears to be, not where the author sat.

The common mistake is:

“This is the first IP address I found, so it is the sender’s IP.”

Another is:

“The address geolocates to this city, so the person sent the email from there.”

Both may be wrong.

A careful conclusion may be:

“The recipient’s provider recorded the message as arriving from a mail server using this IP address. The address is associated with this provider.”

If a provider-specific field genuinely records the original client connection, say that and explain which system created the field.

Don’t promote a mail-server address into a user-device address without evidence.

The IP address may give you a useful route into the provider, platform or account behind the message.

First work out what it represents.

Key takeaway

An IP address in a header may identify a mail server, gateway, platform or client connection. It doesn’t automatically identify the sender’s device or location.

Source notes

Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.