How to Trace an IP Address (And Where the Trail Ends)

You wake up to find 47,000 failed SSH login attempts in your server logs. They all originate from a single IP address. A geolocation lookup says Bucharest. But what does that actually mean? Is someone in Romania targeting your server, or is this a VPN endpoint, a rented cloud VM, or a compromised machine running as a proxy?

Tracing an IP address goes beyond typing it into a lookup tool. Geolocation tells you where an IP is registered. Traceroute shows how traffic reaches it. WHOIS reveals who controls the address block. Reverse DNS often exposes what kind of infrastructure is behind the IP. Each method answers a different question, and together they build a picture that no single lookup can provide.

This guide walks through each method with real output examples and the honest limitations that determine whether your trace leads somewhere useful or hits a wall.

Geolocation: The Instant First Step

The fastest way to get context on an unknown IP address is a geolocation lookup. Enter the IP into a service like our IP tracer tool and within seconds you'll have:

• Country, city, and region — where the ISP's equipment serving this IP is located
• ISP and organization — the company providing internet access or hosting
• ASN (Autonomous System Number) — the network's routing identifier
• Connection type — residential, corporate, hosting, or cellular
• Coordinates and timezone — approximate location on a map

This immediately answers the most basic question: where in the world is this IP registered? But "registered" is the key word. Geolocation databases map IP blocks to the locations of ISP infrastructure, not individual users. An IP geolocating to Frankfurt might mean a residential user in Frankfurt, or a cloud server at an AWS data center in Frankfurt. The geolocation alone can't tell you which.

This is why geolocation is the starting point of a trace, not the conclusion. The real investigation starts when you combine it with the tools below.

Traceroute: Following the Network Path

Traceroute does something fundamentally different from geolocation. Instead of checking a database, it sends packets across the live internet and maps every router they pass through on the way to the destination.

How it works

Your computer sends packets with incrementally increasing Time-To-Live (TTL) values. The first packet has TTL=1, so the first router along the path decrements it to zero and sends back an ICMP "time exceeded" message, revealing its own IP address. The second packet has TTL=2, reaching the second router before expiring. This continues until the packets arrive at the final destination, mapping every network hop along the way.

Van Jacobson wrote the original traceroute implementation in 1988, and the core mechanism hasn't changed since. It remains one of the most useful diagnostic tools in networking.

Running a traceroute

Reading the output

Here's what real traceroute output looks like:

The hostnames tell the real story:

• Hops 1–2: Your local network (private IPs like 192.168.x.x and 10.x.x.x)
• Hop 3: nycmny01 — a backbone router in New York City, managed by NTT (a major international carrier). The latency is 12ms, indicating a nearby domestic hop.
• Hop 4: amstnl06 — a router in Amsterdam, Netherlands. Notice the latency jumped from 12ms to 82ms — the packet crossed the Atlantic Ocean. That 70ms gap is the speed of light through undersea fiber.
• Hop 5: Asterisks (* * *) mean the router didn't respond. This is normal — many routers silently drop traceroute probes for security. It doesn't mean the trace failed.
• Hop 6: The destination.

These backbone hostnames follow semi-standardized naming conventions across major carriers. nycmny01 = New York City, NY. amstnl06 = Amsterdam, Netherlands. londen03 = London. chibbr05 = Chicago. Once you learn the patterns, you can read the geographic transit path at a glance.

What traceroute reveals that geolocation can't

• The actual network path between you and the target — not a database estimate, but the live route
• Whether traffic transits through unexpected countries (relevant for data sovereignty)
• The backbone carriers handling the traffic (NTT, Lumen, Telia, Cogent, etc.)
• Network bottlenecks — sudden latency jumps reveal long-distance links or congestion

WHOIS and RDAP: Who Controls This IP

Every public IP address belongs to a registered block allocated by one of five Regional Internet Registries (RIRs):

A WHOIS query tells you who holds the allocation: the organization assigned the IP block, their abuse contact email, and when the allocation was registered. You can run this through our WHOIS lookup tool or from the command line:

WHOIS provides different information than geolocation. Geolocation tells you where the IP probably is. WHOIS tells you who controls the address block. For investigation purposes, the abuse contact is often the most actionable field — it's the path to getting a malicious server taken down.

RDAP (Registration Data Access Protocol), defined in RFC 7480, is gradually replacing WHOIS. It returns structured JSON instead of freeform text, making it machine-readable. All five RIRs now run RDAP endpoints alongside traditional WHOIS, and the underlying data is the same.

Reverse DNS: What Is This IP Used For

Every IP address can have a reverse DNS (rDNS) record — a hostname associated with the address. While regular DNS maps names to IPs (example.com → 93.184.216.34), reverse DNS maps IPs to names (93.184.216.34 → example.com).

Reverse DNS records are set by the IP owner, so they're self-reported. But they're still revealing:

The rDNS hostname often reveals more about an IP's purpose than geolocation does. A hosting provider hostname means it's a server. A residential ISP pattern with a CPE (customer premises equipment) designation means it's a home connection. An ec2- prefix means anyone could have rented this AWS instance from anywhere in the world.

Tracing Emails Back to Their Source

Email header tracing is one of the most common reasons people need to trace an IP address. Every email accumulates Received: headers as it passes through mail servers, and reading them in reverse order (bottom to top) reveals the path from sender to your inbox.

Our email header analysis tool automates this process: paste the full headers and it extracts every IP address with geolocation data for each server hop, plus SPF, DKIM, and DMARC authentication results.

The major limitation

Gmail, Outlook.com, and Yahoo strip the sender's original IP address from outgoing email headers. If someone sends you an email from a Gmail account, the headers will only show Google's internal infrastructure — not the sender's actual IP or location. This is a deliberate privacy protection and there is no workaround.

Email header tracing works reliably when the email came from:

• A corporate mail server (Exchange, self-hosted Postfix/Sendmail)
• A smaller email provider that doesn't strip headers
• A compromised server being used to send spam (the server's IP will be visible)

For a detailed walkthrough of reading email headers and understanding SPF/DKIM/DMARC authentication, see our Email Header Analysis Guide.

When the Trail Goes Cold

Not every IP trace leads to a useful result. Several common scenarios cut the trail short.

VPNs and commercial proxies

If the IP belongs to a VPN provider (NordVPN, ExpressVPN, Mullvad, etc.), every tool you run — geolocation, WHOIS, reverse DNS, traceroute — describes the VPN server, not the actual user behind it. Our VPN Detector can identify most commercial VPN IPs, which at minimum tells you the trace results are unreliable for that address.

Tor exit nodes

Tor routes traffic through three encrypted relay hops, and only the final exit node's IP is visible. The exit node operator has no knowledge of who originated the traffic. Tor publishes a list of all exit nodes, so you can check whether an IP is one — but that's where the trace ends.

Carrier-grade NAT (CGNAT)

Mobile carriers and some broadband ISPs put thousands of subscribers behind a single public IP using CGNAT. Even if you trace an IP to "T-Mobile, Dallas," there could be 5,000 phones sharing that address at any given moment. Without a specific timestamp and cooperation from the carrier (which requires a court order), you cannot narrow it to an individual device.

Cloud infrastructure and CDNs

An IP belonging to AWS, Google Cloud, Azure, or a CDN like Cloudflare tells you very little about the person who rented the resource. Anyone can spin up a server in any region with a credit card. The geolocation just tells you which data center region was chosen. If you're seeing Cloudflare IPs in your server logs, that's the CDN edge server — not the actual visitor. The real IP may be in the X-Forwarded-For header, but that header can be spoofed by malicious clients.

Real Cases Where IP Tracing Mattered

IP tracing rarely solves a case on its own. In real investigations, it provides one piece of a larger evidentiary puzzle.

The Mirai botnet (2016)

In September 2016, security journalist Brian Krebs' website was hit with a then-record 620 Gbps DDoS attack from the Mirai botnet — a network of hundreds of thousands of compromised IoT devices. Researchers at Akamai traced the botnet's command-and-control traffic through IP addresses and domain registrations. The FBI's investigation combined this IP evidence with code analysis, domain WHOIS records, and forum activity to identify three college students — Paras Jha, Josiah White, and Dalton Norman — who pleaded guilty in December 2017.

IP tracing found the infrastructure. Traditional investigation connected it to the people.

The Silk Road server (2013)

The FBI located the Silk Road marketplace server after a misconfigured CAPTCHA page leaked the server's real IP address rather than its Tor hidden service address. The IP traced to a data center in Reykjavik, Iceland, where Icelandic authorities imaged the server drives. That single IP address — exposed by a configuration error — was the thread that unraveled the entire operation, though connecting the server to operator Ross Ulbricht required months of additional work.

Business email compromise

The FBI's Internet Crime Complaint Center (IC3) reports that business email compromise (BEC) fraud caused $2.9 billion in losses in 2023. In these cases, IP tracing from email headers is routinely used to determine whether a "CEO" email actually originated from the company's network or from a different country entirely. When a financial controller receives a wire transfer request "from the CEO" and the email headers show an IP in Lagos rather than the company's known network, that's an immediate red flag. Combined with authentication failures (SPF/DKIM), header IP analysis is one of the fastest ways to confirm a spoofed message.

The consistent pattern across these cases: IP tracing provides leads, not proof. It narrows the geography, identifies the network infrastructure, and reveals the trail. Connecting that trail to a specific person requires additional evidence and, in most cases, ISP cooperation through legal process.

Traceroute mechanism based on Van Jacobson's 1988 implementation. WHOIS protocol: RFC 3912. RDAP: RFC 7480. Regional Internet Registries: NRO. Mirai prosecution: DOJ press release, December 2017. Silk Road: United States v. Ulbricht. BEC statistics: FBI IC3 2023 Annual Report. VPN usage: Security.org, DemandSage.