How to find the sending IP address in an email header, and which Received line to trust

Which line is evidence

Every SMTP server that accepts a message must add its own Received line at the top, and must not change, delete or reorder the ones already there (RFC 5321, section 4.4). So the chain reads newest first: the line at the top was written by the last server, and the line your own border mail server wrote sits wherever your infrastructure begins. That line is the evidence. Everything below it arrived inside the message and could have been written by the sender, formatted perfectly, in any number; the prepend-only rule binds well-behaved software, it is not a tamper seal. The bottom line, which most guides point at, is therefore the easiest one to fabricate, often holds a private address, and for many webmail submissions no line records the client hop at all. Read from the top down and stop trusting at your own boundary. If you run the mail system, you know which host names are yours; if you do not, follow the addresses rather than the names. Start at the top and keep going down while the address a line records belongs to your provider's own network; the first line whose recorded address sits outside it is the boundary, and that address is the sender. The "from" name is the client's EHLO claim, so a sender can put your provider's name there and push the apparent boundary down into lines it wrote itself. Nothing below the boundary counts, even when a lower line also happens to name your provider.

Two things move the boundary. If a filtering gateway, an appliance or a relay of your own sits in front of your provider, the boundary is the line that gateway wrote, one or more lines further down, and the provider's line above it records only the gateway. And if the message reached you through a forwarder, an alias or a mailing list you do not run, the boundary line records that forwarder accurately and tells you nothing about who fed it: the address is real, the attribution is not, and the operator to contact is the forwarder rather than the originator.

Reading one Received line

A typical line reads: from mail.claimed.example (rdns.isp.example [203.0.113.42]) by mx.yours.example. In the RFC's grammar, and in the common Postfix, sendmail and Gmail layout, the name after "from" is what the connecting machine announced in its EHLO command, and it is worth exactly that: RFC 5321 says a server may check the name against the connection and must not refuse the message if it does not match. The parenthesised part immediately after the "from" name is filled in by the receiving server rather than the client, which the standard's own grammar reflects, but its two halves differ in weight. The bracketed address is what the server saw on the TCP connection. The name beside it is the answer to a reverse-DNS lookup, published by whoever controls that address's reverse zone, so read it as the network's own labelling of the address and not as identification of the sender. The name after "from" is the sender's assertion, and swapping it for the observed address attributes the wrong host every time. A bracketed address standing where the "from" name would be is, in the RFC's grammar, the client's own EHLO address literal, but not every server follows the grammar: Exim writes the address it observed in that position whenever reverse DNS does not verify, and puts the client's claim in the parentheses as helo=, so treat a leading bracketed address as ambiguous until you know which your server means. Layouts differ by software: Exim puts the verified reverse-DNS name first when reverse DNS does verify, and Exchange writes the address without square brackets, so learn your own server's layout from a known-good message before triaging. Note too that a real line usually carries several parenthesised comments, and only the one attached to the "from" clause holds the observed connection: the software name after "by", an envelope-from, and TLS details are unrelated. Three more details trip parsers. The address literal is a SHOULD, so a conforming server may omit it, and a missing address is not suspicious in itself. IPv6 appears both as [IPv6:2001:db8::1] and, at some large receivers, bare in brackets. And the timestamps carry explicit offsets so hops can be compared, but relay clocks are wrong often enough that a negative gap between two lines usually means a bad clock, not tampering.

The other places the address appears

Receivers also record the connecting address in structured fields, and the same boundary rule applies. Received-SPF carries it as client-ip (RFC 7208, section 9.1). Authentication-Results carries it only as policy.iprev, or as smtp.remote-ip beside an arc= result (RFC 8617, an Experimental RFC), which records the connection the ARC evaluator saw and is your view only if your own receiver wrote it; providers otherwise put it in a comment, such as Microsoft's documented spf=pass (sender IP is ...) form, and a comment is prose, not a contract. Microsoft's X-Forefront-Antispam-Report records the connecting address as CIP. Before you read any of these, check who wrote it: for Authentication-Results that is the authserv-id, for Received-SPF the receiver key and its place directly above your own Received line, and for a vendor header whether it sits above your boundary at all. RFC 8601 requires a conforming server to delete Authentication-Results fields that claim its own identifier but did not come from a trusted server, precisely because senders insert them, and any such field carrying an unfamiliar identifier is untrusted text that arrived inside the message, whether a forwarder left it or a sender forged it. Vendor X- headers, X-Originating-IP among them, are in no registry and were changed unilaterally in the past; RFC 6648 deprecates the convention.

Why webmail usually hides the client and submission usually does not

Mail reaches a provider by broadly three kinds of path, and only two of them are SMTP hops that the standard obliges a server to stamp. Server-to-server relay gets a Received line. Authenticated client submission on port 587 or 465 gets one too, typically tagged ESMTPA or ESMTPSA, and its address is normally the client's connecting address: published examples through January 2025 (a Thunderbird desktop client in 2022, a firewall appliance's notifier in 2025) show mail submitted through smtp.gmail.com with the client's address in the oldest Received line, the one smtp.gmail.com itself wrote. That line sits below your boundary, so it is hearsay. On a genuine message it is the provider's honest record of the submission; on a forged one it costs an attacker nothing to invent, and nothing inside the message tells you which of the two you are holding. Treat a client address found there as a lead to confirm with the provider, never as the basis for a block or an abuse report, and note that even a genuine one is often a household, office or carrier NAT egress shared by many people. Browser webmail, provider apps that talk HTTPS to their own back end, and other non-SMTP clients carry no SMTP hop, and no standard requires a Received line for them, so the client appears only if the provider chooses to add it. As widely reported, mail composed in the Gmail web interface shows only Google infrastructure; we found no Google statement either way, and its own help page on viewing full headers does not address it. Microsoft stopped exposing the consumer Hotmail and Outlook.com sender address around the turn of 2012 into 2013, while Microsoft 365 webmail was reported in 2019 to add an x-originating-ip line that tenant admins can strip; test with a message to yourself before relying on any of it. Finally, an address from 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 or 100.64.0.0/10 in a Received line marks a hop inside a private network, shared carrier-grade NAT space in the case of the last of those, or a client's own EHLO literal. None of it is routable across the public internet, so a receiver outside that network would not have observed it on the connection.

What the address you found actually is

It is the last hop into your receiver, and most of the time that is not the author's device. It is a provider's outbound relay (Google's published SPF record lists 209.85.128.0/17 and 74.125.0.0/16, and Microsoft 365's spf.protection.outlook.com lists 40.107.0.0/16 among others, as published on 18 August 2026; consumer Outlook.com and Hotmail use a separate, smaller record), a mailing list, a marketing platform, a corporate gateway, a VPN exit or a carrier's shared pool. A country derived from it describes that hop, which Microsoft's own documentation warns may not be the originating address. What the address does give you is a network to look up: who holds it and when the record was registered, which network announces it and has announced it before, whether it is tagged as hosting or a proxy service, whether it sits on blocklists, which describes the recent behaviour of that address or its neighbours rather than this particular message, and which abuse contact is published for it. Read those as dated claims rather than as identity. Registry objects are maintained by the holder and go stale; space is reassigned, resold and sublet without the record always following, so the name on a whois object can be an upstream provider, a former customer or a shell, and the published abuse contact can be an upstream desk that forwards. Where the record and the announcement history disagree, the history is usually the better guide to who operates the space now. That is the right next step for both readers of this piece: for a deliverability engineer, it tells you which of your addresses the receiver actually saw; for a phishing triager, it turns one line of a header into a report that reaches the right desk, as long as the report states what your own server observed and when, and leaves the accusation to the operator who can see the account behind the address. Reading headers is a defensive skill, and it does not cut both ways: the receiver writes the only line that counts, from the connection, not from anything the client asserts.