How can you test routing paths (traceroute, MX lookup)?

Something's off. Mail to a certain domain isn't arriving, or it's arriving late, and you have no idea where it's getting stuck. That's when you run through this three-step diagnostic: MX lookup, SMTP connectivity check, and header trace. Each one narrows the problem down to a specific point in the path.

Step 1: MX Lookup

So before you send anything, check where mail for that domain is supposed to go. An MX record is the DNS instruction that tells the internet which mail server should accept messages for a domain. Run this in your terminal:

dig MX example.com

You'll get back a list of mail servers with priority numbers (lower number = higher priority). What you're looking for: does the domain actually have MX records? Are they pointing somewhere sensible? If you see no records, or records pointing to a server that doesn't exist, that's your problem right there. Mail has nowhere to go.

On Windows, the equivalent is nslookup -type=MX example.com. Both do the same thing.

Step 2: SMTP Connectivity Test

Now you know where mail should go. The next question is whether your server can actually reach it. Use swaks (a purpose-built SMTP testing tool) or telnet to knock on the door:

swaks --to test@example.com --server mail.example.com --port 25

Or with telnet:

telnet mail.example.com 25

What you're watching for in the response codes:

• 220 means the server is alive and accepting connections. Good start.
• 250 means the server accepted your command. Keep going.
• 421 or 450 means a temporary defer. The server is alive but not ready. Usually a rate limit or load issue.
• 550 or 554 means a permanent rejection. Could be a reputation block, a policy rule, or the address doesn't exist.
• A connection timeout (no response at all) usually means a firewall is blocking port 25 between your sending IP and their server.

Try port 587 if port 25 is blocked. Some mail environments route submission traffic through 587 instead (this matters more for authenticated outbound flows than for server-to-server delivery).

Step 3: Header Analysis After Delivery

If the message did get through but something seems wrong (delayed, filtered, modified), the Received headers inside the delivered email tell the full story. Each server that handled the message adds its own Received header, so the complete path is logged in reverse order (bottom entry is the first hop, top entry is the last).

Reading them manually is tedious. Use Google Workspace's Admin Toolbox or MXToolbox's Header Analyzer to parse them into a readable timeline. What you're looking for:

• Unexpected hops (a server in the chain you didn't expect, which could indicate a smart host or relay is intercepting mail)
• Large time gaps between hops (a server that held the message for minutes or hours is usually the delay bottleneck)
• Authentication results (SPF, DKIM, DMARC pass or fail markers that might explain why a message was filtered)

What Each Tool Actually Tells You

Put it together as a flow. MX lookup tells you if the destination is configured correctly. SMTP connectivity tells you if your server can reach that destination. Header analysis tells you what actually happened during transit. If MX looks fine, SMTP connects cleanly, and headers show no unusual hops or gaps, the problem is likely reputation-based rather than routing-based. That's when you check your domain and IP reputation.

If you're stuck and the commands above aren't giving you a clear answer, our SOS hotline is free. Routing issues can get weird fast, and sometimes a second pair of eyes cuts the diagnostic time in half.