How do you trace the IP address an email came from?

Every email carries a record of the servers it passed through, and that record includes IP addresses. Finding the right one is easy once you know which lines your own systems wrote. This guide shows where to look, how to read the address you find, and the limits of what an IP address can tell you about a sender.

Where is the sender's IP address in an email?

The sender's IP address is in the Received header lines, inside square brackets after the word from. RFC 5321, section 4.4 says every server that accepts a message must add a Received line, and that its from clause should contain "the name of the source host as presented in the EHLO command" and "an address literal containing the IP address of the source, determined from the TCP connection."

That last part matters. The name in a Received line is whatever the connecting server chose to call itself. The bracketed IP is what the receiving server actually saw on the network connection, so it's much harder to fake, as long as a server you trust wrote the line.

First, get the full headers. In Gmail, open the message, select More next to Reply, then Show original (Gmail Help). In new Outlook and Outlook on the web, select More actions > View > View message details; in classic Outlook for Windows, open the message, then File > Properties and copy the Internet headers box (Microsoft Support). Our guide to reading email headers covers Apple Mail and the rest of the header.

Which Received line shows the real sending IP?

The trustworthy sending IP is in the first Received line written by your own mail provider or filter, reading from the top. Servers add new lines above old ones and, per RFC 5321, "MUST NOT change the order of existing lines". So the top line is the last hop, and the history runs downward.

Here's a simplified example. The addresses are reserved documentation addresses:

Received: from mx2.filter.example (mx2.filter.example [198.51.100.25])
    by mail.yourcompany.example with ESMTPS; Mon, 2 Nov 2026 09:14:07 +0000
Received: from mail.sender.example (unknown [203.0.113.77])
    by mx2.filter.example with ESMTPS; Mon, 2 Nov 2026 09:14:05 +0000
Received: from [192.168.1.20] (helo=laptop)
    by mail.sender.example with ESMTPSA; Mon, 2 Nov 2026 09:14:01 +0000
Received: from trusted-bank.example ([192.0.2.200])
    by relay.bank.example; Mon, 2 Nov 2026 08:01:00 +0000

Read it this way:

1. Line 1 was written by your mail server. It received the message from your filter at 198.51.100.25. That's your own infrastructure, so keep going.
2. Line 2 was written by your filter, mx2.filter.example. This is the handover point: the first server you trust that received the message from outside. The connecting IP was 203.0.113.77. That's the sending server you can trust.
3. Line 3 says a device at 192.168.1.20 submitted the message to mail.sender.example. The sender's server wrote this, so it's a claim, not proof.
4. Line 4 claims a bank's relay was involved an hour earlier. It could be completely invented. Nothing you control saw that hop.

RFC 5321, section 7.1 is frank that SMTP mail "inherently cannot be authenticated, or integrity checks provided, at the transport level", and that it's "feasible for even fairly casual users" to create misleading messages. Lines below the handover point are where that happens.

How do I know which servers are mine?

Your servers are the hosts named by your domain's MX records, plus your mailbox provider. In Microsoft 365, hosts end in outlook.com or protection.outlook.com; in Google Workspace, they end in google.com. If you use a filtering service in front of your mailboxes, its hosts appear first. Check your MX records with the MX Lookup if you're unsure.

Microsoft 365 also writes the connecting IP into its own header. In X-Forefront-Antispam-Report, the CIP field is "the connecting IP address" and CTRY is the source country "as determined by the connecting IP address, which might not be the same as the originating sending IP address" (Microsoft Learn). The Microsoft 365 header decoder pulls these fields out for you.

Why can't I see the sender's own IP address?

Usually because the sender used a large webmail or business mail service. The person's browser or app talks to the provider, and the provider's server starts the SMTP journey. The earliest Received line you can see often belongs to that provider, so the IP you trace is the provider's server, not the person's computer or phone.

Some services add the submitting device's address in a line like Received: from [192.168.1.20] or in a non-standard header such as X-Originating-IP. Others leave it out. RFC 5321, section 7.6 notes that trace headers can "disclose host names and similar information that would not normally be available", which is one reason providers limit what they record. Either way, a device address written by the sender's provider is only as reliable as that provider.

Other common reasons the trail stops:

• Private addresses. 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are reserved for private networks by RFC 1918. An address like 192.168.1.20 is someone's internal network, not a public location. IPv6 addresses starting fc or fd are the private equivalent, defined in RFC 4193.
• Forwarding and mailing lists. If the message was forwarded, the handover IP belongs to the forwarder. Look for ARC headers or a list server in the chain.
• VPNs and compromised machines. Spam often comes from hijacked accounts or infected computers, so the IP points at a victim, not the person behind it.

What does each part of the IP address lookup tell you?

Once you have the trusted connecting IP, a few lookups tell you what kind of sender it is.

ARIN describes RDAP as "a Whois alternative for querying Internet resource registration data" that returns standardized JSON, and its bootstrap service sends a query on to whichever regional registry holds the address. You can also use the lookup page of the registry for the address's region. In the result, look for an entity with the abuse role.

The most useful single check is often the Authentication-Results header. If it shows spf=pass for the domain in From, the domain owner listed that IP as an approved sender, which tells you far more than a city name. Our guide on checking whether an email passed SPF, DKIM and DMARC shows how to read it.

How do I trace an email's IP address, step by step?

1. Copy the full headers of the original message, not a forward. Ask a colleague to send it as an attachment if they received it.
2. Paste them into the Email Header Analyzer. It runs in your browser and lays out each hop with its IP and timestamp.
3. Find the handover point. Start at the top and move down past every line written by your mailbox provider and filter. The first line from an outside host is the one you want.
4. Note the bracketed IP in that line's from part, and the time.
5. Check Authentication-Results from your provider. A forged copy shouldn't survive, because RFC 8601, section 5 requires your receiving server to delete copies that claim to come from inside its trust boundary.
6. Run the lookups in the table above: registry, PTR and blocklists.
7. Decide what it is. A big provider's IP with SPF and DKIM passing for a lookalike domain means a scammer signed up for an account. An IP that fails SPF for a real brand's domain means spoofing. A residential IP on blocklists suggests an infected machine.

Can an IP address identify the person who sent an email?

No, not on its own. Registry data names the organization that holds the address block, such as an ISP, a hosting company or a mail provider. Matching an address to a customer needs that operator's logs for the exact time, and those logs aren't public.

In the US, 18 U.S.C. § 2703(c)(2) lists subscriber records, including "any temporarily assigned network address", that a provider must disclose to a government entity using a subpoena or other legal process. That's the route investigators use. If you're a victim of fraud, such as a payment-redirection email, report it to law enforcement with the full headers rather than trying to unmask the sender yourself. Our phishing reporting guide lists where to send reports.

Don't contact or confront someone because of an IP lookup. Shared addresses, VPNs and hijacked accounts make wrong conclusions easy.

What should I do with the IP address once I have it?

What you do next depends on what the trace showed.

• Spam from a network with an abuse contact: send the full headers to that address. Abuse desks act on evidence, not on a forwarded message without headers.
• Phishing that impersonates your company: compare the sending IP and SPF result with your own servers. If it's spoofing your exact domain, see someone sending email from my address and tighten DMARC.
• Repeated mail from one source: an admin can block the IP or domain. In Microsoft 365, the CIP value can go into the connection filter's IP Block List; see the Tenant Allow/Block List guide for sender and domain blocks.
• A suspicious message an employee received: if they clicked anything, follow what to do after clicking a phishing link first. The trace can wait.

Next steps

1. Trace one legitimate message from a colleague to learn your own handover point, so you can spot an unusual one quickly.
2. Paste any suspicious message's headers into the free Email Header Analyzer and run the sending IP through the Blacklist Checker.
3. Report abuse to the network's abuse contact, and report fraud to law enforcement with the full headers.
4. Reduce how often you need to trace mail at all. iBlockSpam filters spam, phishing and spoofing at the MX before mail reaches your mailboxes; see how it works.

Browse more guides on running email day to day.