Here is how to trace an email: open its full headers and read the authentication results and the Received chain—not the display name or the From line alone. Those metadata records show how an email message traveled, which servers handled it, whether domain checks passed, and the sending network infrastructure. They cannot, by themselves, identify a person or pinpoint a home address.
How to trace an email using its headers
An email header is a block of metadata lines attached to every email. It records the servers the message passed through, delivery addresses, timestamps, and authentication results. The visible From field is written by the sender and can be forged.
- Preserve the original email. Forward the message as an attachment or save the raw source. Ordinary forwarding destroys the original headers.
- Open the full headers. Copy them to the clipboard for analysis.
- Read Authentication-Results first. This line summarizes the SPF, DKIM, and DMARC checks performed by the receiving server.
- Compare the identities. Compare the From domain with the Return-Path and Reply-To domains. Three different domains on a supposedly personal message represent a classic spoofing pattern.
- Follow Received entries from the bottom upward. Trace the path to the earliest trusted entry, and treat any visible IP address as a network indicator rather than a physical address.
Open the full headers in your email client
Use webmail or a desktop client where possible. Mobile apps do not provide a full header view.
- Gmail on the web: Open the message, select the three-dot menu next to Reply, choose “Show original,” then select “Copy to clipboard.” Google also provides the Google Admin Toolbox Messageheader tool to analyze headers.
- Outlook on the web or Outlook.com: Select the three-dot menu at the top of the message window, then select “View” > “View message details.”
- Classic Microsoft Outlook for Windows: Double-click the message to open it in its own window, then select “File” > “Properties.” The headers appear in the “Internet headers” field.
- Apple Mail on Mac: Open the message, then select “View” > “Message” > “Raw Source.” “All Headers” in the same menu displays them within the message.
- Yahoo Mail on the web: Open the three-dot menu and select “View raw message.”
- Mozilla Thunderbird: Select “View” > “Headers” > “All,” or “View” > “Message Source” (Ctrl+U).
The iPhone and iPad Mail app does not provide a header view. Open the message in your provider’s webmail on a computer instead.
Read the Received chain to find the delivery path
Under RFC 5321, each mail server that accepts a message must add a Received line to the top of the header and must not edit, delete, or reorder existing lines. The oldest entry is at the bottom and the newest entry (added by your provider) is at the top. Read upward from the bottom to trace the route.
| Part of a Received line | What it tells you |
|---|---|
| from | The server that handed off the message, including its observed IP address in brackets. |
| by | The server that accepted the message. |
| with | The transport protocol. ESMTPS indicates encrypted transport; SMTP or ESMTP indicates unencrypted transport. |
| Timestamp | The server-recorded time for the hop. |
For example, a message may pass from an internal queue at 10.0.1.42 to an outgoing server at 198.51.100.23, and then to the recipient’s provider. A two-second delay between hops is normal. Warning signs include an origin IP in an unexpected country, hours of delay between hops, server names that do not match the claimed domain, and missing TLS encryption.
Only the Received lines added by your own provider at the top are trustworthy. A sender can forge lines below that boundary. The IP address in brackets after a hostname comes from the TCP connection and is observed directly by the receiving server.
Use SPF, DKIM, and DMARC to test the claimed sender
The Authentication-Results line provides the primary authentication data. SPF checks whether the sending server is authorized in the Return-Path domain’s SPF record. DKIM verifies a cryptographic signature against a public key retrieved via DNS. DMARC requires that SPF or DKIM passes and that the authenticated domain aligns with the From domain.
A dmarc=fail result on a message claiming to be from a bank indicates that the From domain did not authorize the message. Verify that the DKIM d= domain matches the From domain. An altered Reply-To address causes replies to be sent to an attacker rather than the visible sender.
Passing checks confirm domain authorization, not the message’s safety. A lookalike domain such as paypa1.com will pass DMARC for itself. Furthermore, an email sent from a compromised legitimate mailbox will pass SPF, DKIM, and DMARC. Email forwarding often breaks SPF, while DKIM can survive forwarding to maintain DMARC alignment.
What an IP address can reveal—and what it cannot
The earliest trusted IP address identifies the sending server infrastructure or ISP via WHOIS lookup. It helps determine whether a message originated from an established provider or bulk hosting, but it does not identify the person who sent it.
Major webmail providers (Gmail, Outlook.com, Yahoo Mail) remove sender client IP addresses from outgoing headers. The first visible address is their own outgoing server. Messages from self-hosted systems, certain corporate systems, and direct SMTP desktop clients can expose the client IP in the lowest Received entry. Microsoft 365 can include the client IP in an X-Originating-IP header. Gmail does not record the client IP in Received lines or X-Originating-IP, using an X-Google-Smtp-Source header instead.
IP geolocation provides network-level estimates, not GPS coordinates. MaxMind reports country-level accuracy of 99.8%, but city-level accuracy within 50 km in the US is approximately 66%. VPNs, mobile carrier-grade NAT (CGNAT), and CDNs cause the visible IP to reflect an exit server, gateway, or data center rather than the user’s location.
Common email tracing myths that lead you astray
The From address proves who sent it
No. The From header is arbitrary text set by the sender. Compare it with the Return-Path, Reply-To, and Authentication-Results headers to check for spoofing.
A passing DMARC result means the email is harmless
No. DMARC confirms that the message was authorized by the domain in the From line. It does not verify domain trustworthiness, nor does it protect against compromised mailboxes.
You can trace an email back to a specific person from headers
No. Headers identify servers and network IPs, not individuals. Email providers and ISPs retain the records linking accounts to IPs, and law enforcement requires legal process, such as a court order, to obtain subscriber identities.
Gmail lets you track someone’s location
No. Standard Gmail accounts hide sender client IP addresses in message headers. While Google Workspace domains may include X-Originating-IP, any IP address indicates only a general network location.
Protect your privacy and report a dangerous message
To prevent your outgoing emails from revealing your network IP, a VPN replaces your IP address with that of the VPN server. Avoid including personal information such as full names, phone numbers, or physical addresses in message text. Mobile Gmail and Outlook apps route messages through cloud infrastructure, which masks the client IP in outgoing headers.
To prevent sender tracking, disable automatic image loading in your email client. Tracking pixels in HTML emails can log when a message is opened, device types, operating systems, and approximate recipient IP positions. This occurs only when the recipient loads external images.
To report phishing, use your provider’s reporting function: select “Report phishing” in Gmail’s menu, or “Report” > “Phishing” in Outlook. Preserve the raw message headers. Phishing emails can also be forwarded to phishing@google.com, phishing@microsoft.com, and reportphishing@apwg.org. Financial fraud or data theft should be reported to ReportFraud.ftc.gov and IC3.gov.
Frequently Asked Questions
How can I check whether an email has been received?
A delivery receipt confirms that a message reached the recipient’s mail server, not that it was opened. In Outlook, delivery receipts can be requested under “Options” > “Tracking.” Read receipts can be declined by recipients and are not supported across all clients; Gmail does not include native read receipt functionality in its core consumer service.
Can an email be traced to a location?
An IP address in an email header reveals only an approximate network location. It cannot locate an individual or household. Mobile networks using CGNAT, VPNs, and CDNs frequently locate the IP hundreds of kilometers from the sender.
What information can email tracing reveal?
Email tracing reveals the relay servers (hops), SPF, DKIM, and DMARC results, TLS encryption status, hop transit delays, and the sending network’s ISP or hosting provider. It cannot reveal the sender’s real identity, physical address, or whether the message was read.
Can emails sent from a phone be traced?
Headers from mobile emails can be inspected, but apps such as mobile Gmail and Outlook route mail through provider cloud infrastructure that masks the sender’s IP. However, opening tracking pixels or links in incoming mail on a phone can expose the recipient’s IP and device details.
How can I prevent my emails from being traced?
Use a VPN to replace your client IP address, exclude personal identifying details from the message text, disable automatic image loading, and apply expiration times to encrypted messages where supported. These measures do not hide account activity from the email provider or legal authorities.
