Tracert (the Windows name, shortened for legacy 8.3 filenames) and traceroute
(the Unix original) map the exact route packets take across the internet. The trick
is the IP TTL (Time To Live) field: every router decrements it by
one, and the router that decrements it to zero discards the packet and sends back an
ICMP Time Exceeded message. By sending probes with TTL 1, 2, 3,
… each router on the path reveals itself in turn — producing a hop-by-hop list
with the router's IP address, its reverse-DNS hostname, and the round-trip time to
that hop. This free online tracert runs the trace from our European datacenter, so
you can see how the internet at large routes to a server — independent of your own
Wi-Fi, VPN, or ISP.
Typical uses: locating the hop where latency or packet loss begins, checking which
carrier a route crosses, verifying whether a mail
server (MX host) is reachable from outside your network, and gathering evidence
for your hosting provider or ISP when a route breaks.
How to read your traceroute results
Hop — the router's position on the path. Hop 1 is the first router after the tracing machine; the last row is the destination if it was reached.
Hostname — the router's reverse-DNS (PTR) name. Carrier naming conventions often encode the city or airport code (e.g. fra, ams, nyc), letting you follow the route geographically.
Time (RTT) — the round trip to THAT hop. It should rise gradually with distance; watch for where it jumps and stays high.
Status — router reply, timeout, or destination reached. Timeouts are only meaningful in patterns, not in isolation.
Common traceroute result patterns and their meaning
Pattern
What it means
One slow middle hop, later hops fast
Router deprioritizes ICMP replies while forwarding normally — harmless
Latency jumps at one hop and stays high
Long physical link (e.g. ocean crossing) or congested interface at that hop
Timeouts from one hop to the end, destination unreached
Real reachability problem at or just after the last responding router
Trailing timeouts but the service works
Destination firewall filters ICMP — the host is fine
A few starred middle hops, trace completes
Routers that never answer probes — cosmetic, ignore
Tracert vs. ping
Ping tells you whether a host is reachable and how fast
the round trip is; tracert tells you which route packets take and
where the path slows down or breaks. Use the
online ping test first for a quick health check and
continuous latency monitoring; switch to this traceroute when ping shows loss or
high latency and you need to locate the failing hop — the last responding router
tells you whose network to call.
Traceroute for mail servers and email deliverability
When SMTP connections to an MX host time out or mail queues back up, trace the route
to your MX hostnames: the hop where loss or latency begins localizes the problem to
your network, your ISP, an intermediate carrier, or the destination — evidence you
can escalate instead of guessing. Then continue up the stack with the analyzer's
companion tools: the Ping Tool for reachability and
latency trends, the Domain Security Checker for
SPF/DKIM/DMARC DNS records, the Blacklist
Checker for RBL listings of your sending IPs, the
Email Header Analyzer for per-message
authentication results, and the
email-deliverability guide for the complete diagnostic funnel.
Frequently asked questions about traceroute (tracert)
Quick answers to the most common questions about tracert, traceroute, hops and route timeouts. Click any question to expand its answer.
What is tracert?
Tracert is the Windows command-line name for traceroute, the network diagnostic that maps the route packets take from one host to another. Instead of only telling you whether a destination answers (which is what ping does), tracert lists every router — every "hop" — along the path together with its IP address, hostname, and per-hop latency. It works by sending probes with deliberately small TTL (Time To Live) values: the first probe expires at the first router, which announces itself with an ICMP Time Exceeded message, the second probe expires at the second router, and so on until the destination replies. The result is a hop-by-hop picture of the path, which is why tracert is the go-to tool when you need to find WHERE on a route packets are delayed or lost.
How does an online traceroute work compared to tracert in my terminal?
Running tracert in a Windows command prompt (or traceroute on macOS/Linux) traces the route from YOUR computer, so the first hops are always your own router, your ISP, and your local peering points. An online traceroute like this one runs from our server in a European datacenter, so it shows the path from a neutral, well-connected vantage point — useful for checking how the internet at large reaches your server, for comparing against the route you see locally, and for testing when your own network blocks ICMP or you have no terminal at hand. This browser tool advances the trace one hop per tick, sending exactly one ICMP probe per TTL from our infrastructure and streaming each router reply, its reverse-DNS name, and its round-trip time back to your browser in real time.
How do I read traceroute results?
Read a traceroute top to bottom: hop 1 is the first router after the tracing machine and the last line is the destination (if it was reached). Each row shows the hop number, the router hostname from reverse DNS, its IP address, and the round-trip time of the probe. Latency should rise gradually with distance; what matters is the PATTERN, not one number. A big permanent jump at one hop and every hop after it marks a long physical link (for example an ocean crossing) or a congested interface. High latency at a single middle hop while later hops stay fast is usually harmless — routers deprioritize generating ICMP replies while forwarding your actual traffic at full speed. Loss or timeouts that begin at one hop and continue to the destination localize a real problem at or just after that hop.
What do the asterisks (* * *) in tracert output mean?
An asterisk means a probe for that hop received no reply within the timeout. It does NOT automatically mean the hop is down: many routers rate-limit or simply never send ICMP Time Exceeded messages, so a starred middle hop with normal replies at later hops is cosmetic and can be ignored. The pattern to worry about is asterisks that START at some hop and continue all the way to the end without ever reaching the destination — that localizes a real reachability problem at or just beyond the last responding router. Trailing asterisks can also mean the destination itself silently drops probes while serving normal traffic (a firewall filtering ICMP), which is why a website can work perfectly even though its trace never "completes".
Why does my traceroute stop before reaching the destination?
There are three common reasons. First, the destination or its network filters ICMP: the trace shows every hop up to the target network and then times out forever, while the actual service (web, mail) works fine — this is normal and widespread. Second, a genuine outage or routing problem: packets stop at the last responding hop, and the service is equally unreachable — the last responding router tells you which network to blame. Third, a middle network uses MPLS tunnels or hides its interior, so several hops appear as timeouts before later hops respond again. To tell these apart, check whether the service itself responds (then it is ICMP filtering), and compare traces from two vantage points such as your own terminal and this online tool.
What is the difference between tracert and traceroute?
They are the same idea with different names and slightly different default mechanics. Tracert is the Windows implementation (the name was shortened to fit legacy 8.3 filenames) and sends ICMP Echo Request probes. Traceroute is the Unix/Linux/macOS original and by default sends UDP probes to high-numbered ports, though it can use ICMP (-I) or TCP (-T). Both rely on exactly the same TTL-expiry trick: each router that decrements the TTL to zero reveals itself with an ICMP Time Exceeded message. Because the probe types differ, a Windows tracert and a Linux traceroute to the same destination can show slightly different behavior where firewalls treat ICMP and UDP differently. This online tool uses single ICMP probes per hop, matching the tracert style.
What is the difference between traceroute and ping?
Ping answers WHETHER a host is reachable and HOW FAST the round trip is; traceroute answers WHICH ROUTE packets take and WHERE the path slows down or breaks. Ping sends ICMP Echo Requests straight to the destination and reports end-to-end round-trip time and packet loss — perfect for a quick health check or continuous latency monitoring. Traceroute sends probes with increasing TTL values so every router on the path reveals itself, producing a hop-by-hop map with per-hop latency. In practice you use them together: ping first to confirm there IS a problem (loss or high latency), then traceroute to locate the hop where the problem starts and decide whether it is your network, your ISP, an intermediate carrier, or the destination.
Why does traceroute matter for mail servers and email deliverability?
When mail is delayed or connections to an MX host time out, the cause is often on the network path rather than in the mail server itself. A traceroute to your MX hostnames shows whether packets reach the destination network at all, which carrier the route crosses, and at which hop latency or loss begins — evidence you can hand to your hosting provider or ISP instead of guessing. Combined with this DMARC analyzer's other tools — the online ping test for reachability and latency trends, the Domain Security Checker for SPF/DKIM/DMARC DNS records, the Blacklist Checker for RBL listings of your sending IPs, and DMARC aggregate-report monitoring for authentication results — traceroute completes the network layer of email troubleshooting.
🍪 Cookie Notice This website uses only technically necessary cookies that are essential for the operation of the site. No tracking, analytics, or marketing cookies are used. According to §25 (2) TDDDG, no consent is required for technically necessary cookies.