A technical guide to email headers, SMTP routing, and why emails get delayed.
Everything you need to understand SMTP routing, decode email headers, and diagnose delivery delays — from protocol basics to per-hop latency benchmarks.
Every email carries two distinct layers: the body (what you read) and the headers (what the internet's mail infrastructure wrote). Headers are plain-text metadata lines prepended to every message by each server that handles it — from the moment your client hits Send to the moment it lands in the recipient's inbox.
The most important header for diagnosing delays is Received:. Every mail transfer agent (MTA) appends a new Received: line at the top of the header block — meaning the first line is the most recent hop, and the last line is the oldest. This tool reverses that order so you see the journey chronologically, from origin to inbox.
SMTP (Simple Mail Transfer Protocol) is the standard used to send email between servers. When you click Send, your email travels through a chain of servers before reaching its destination — a process that normally takes under ten seconds but can stretch to hours when something goes wrong.
Each Received: header records: from (the sending server), by (the receiving server), with (the protocol used), and a timestamp. The delta between consecutive timestamps is the time that server spent processing and forwarding the message — and that delta is exactly what this tool calculates and visualizes.
The with field in a Received: header tells you which protocol was used for that hop, revealing how secure and authenticated the connection was.
The original 1982 protocol. Transmits in plaintext with no encryption or authentication. Rare on the modern internet for server-to-server mail; still seen on some legacy internal systems. If you see plain SMTP, that hop was unencrypted.
Adds negotiation capabilities (RFC 5321): servers advertise supported extensions including AUTH, SIZE, and STARTTLS. Most server-to-server mail uses ESMTP with opportunistic TLS encryption.
The connection was wrapped in TLS from the start (implicit TLS, typically port 465). More secure than STARTTLS because encryption begins before any protocol negotiation. Major providers like Google enforce ESMTPS for inbound mail.
The most secure combination: authenticated and TLS-encrypted. Typical for mail client → SMTP provider connections on port 465 or 587.
Used for final delivery within a single system — typically from the MTA to the mailbox store. Not routable between servers. If you see LMTP, that hop represents the last step into the mailbox.
When an email takes longer than expected, the Received: chain usually points directly to the responsible server. Here are the most frequent causes and what the delay pattern looks like in the headers.
The receiving server temporarily rejects the first delivery attempt from an unknown sender. Legitimate mail servers retry after the specified delay; spambots typically do not. The retry gap appears between your outbound relay hop and the receiving server.
Anti-spam gateways (Proofpoint, Barracuda, Mimecast, Google's filter) scan message content before accepting it. Complex messages with attachments, HTML, or links to unknown domains take longer. Delay appears at the receiving gateway hop.
The most common cause of multi-hour delays. Your message sat in a queue waiting for a delivery slot. The delay appears between the sending client hop and the first outbound relay hop.
Corporate mail gateways apply policy rules: blocking certain file types, quarantining content-policy violations, or routing messages to a compliance review queue. The delay is at the corporate gateway hop; the email may require manual release.
The sending server couldn't resolve the recipient domain's MX record. Appears as a gap before the first receiving server hop. Retries follow the server's schedule (typically 15 min, 1 hr, 4 hrs).
Large providers (Gmail, Outlook) throttle inbound connections from unknown senders. The sending relay retries until accepted. Look for multiple identical hops with increasing timestamps at the receiving server.
If the initial TLS handshake fails (certificate mismatch, protocol incompatibility), servers may retry with a fallback or queue for retry. Adds small but detectable delays at the connection hop.
The receiving server's clock is behind the sending server's. Produces a timestamp earlier than the previous hop — technically impossible for a real delay. This tool detects clock skew, clamps the delta to zero, and flags the affected hop.
Knowing what's normal helps you identify a real problem versus an expected delay. Transit times vary by email type, sender reputation, and recipient infrastructure.
| Total Transit | Assessment | Likely Cause |
|---|---|---|
| < 5 seconds | ✅ Excellent | Direct relay, high-trust sender, no filtering |
| 5 – 30 seconds | ✅ Normal | Spam scanning, TLS handshake, standard routing |
| 30 sec – 3 min | 🟡 Acceptable | Greylisting (first delivery) or content inspection |
| 3 – 15 min | 🟠 Slow | Aggressive greylisting, rate limiting, mild queue backlog |
| 15 min – 1 hour | 🔴 Delayed | Significant queue backlog, policy hold, DNS issues |
| 1 – 4 hours | 🔴 Seriously delayed | Major queue backup, quarantine hold |
| > 4 hours | 🔴 Critical | Server failure, DNSBL listing, prolonged policy hold |
A single hop accounting for more than 80% of total transit is your bottleneck. This tool surfaces exactly that hop and labels its severity:
| Per-Hop Delta | Label | Meaning |
|---|---|---|
| 0 – 5s | Normal | Healthy forwarding. No issue. |
| 5 – 30s | Minor | Typical spam scan or connection setup. |
| 30s – 2min | Slow | Greylisting or content inspection. |
| 2 – 10min | Delayed | Rate limiting, queue wait, or policy check. |
| > 10min | Critical | Queue backup, quarantine, or server issue. |
Once you've identified the bottleneck server, the appropriate action depends on where in the chain the delay occurred.
If the largest gap is between the sender's client and the first relay, the issue is on the sender's side:
If the delay is in the receiving domain's servers, it's outside your direct control:
Use the Download Report button in this tool to export a structured plain-text report of the full hop analysis. Enable PII masking before downloading if you need to redact email addresses and IP addresses. The report includes the Message-ID and all raw header data your administrator will need to open a support ticket.
Why does the total transit time differ from what I expected?
Transit time is measured from the first parsed timestamp to the last. If your client didn't record a Received: header, or if the Date: header shows an earlier time than the first relay, there may be a small discrepancy. This tool also prepends the Date: header as an origin hop when it predates the first Received: timestamp.
Why is one of my deltas showing 0 seconds?
Either two servers recorded the handoff at the same second (common for internal routing within a single mail system), or a clock skew condition caused a negative delta that was clamped to zero. Check for the Clock Skew badge on that hop.
Can I trust the timestamps in email headers?
Mostly, but not absolutely. Each timestamp is self-reported by the server that wrote it. Misconfigured servers can have clocks that are minutes or hours off. This tool detects obvious clock skew (negative deltas) but cannot detect all forms of inaccuracy. Treat results as diagnostic estimates, not verified measurements.
What does "tz assumed UTC" mean?
The timestamp in that Received: header used a named timezone code that this tool couldn't resolve (not in its standard timezone map). Rather than discard the timestamp, the tool assumed UTC (offset = 0). This may cause a small inaccuracy in that hop's delta.
My email arrived instantly but the header shows a 2-hour delay. Is that right?
This commonly happens with greylisting. The server initially rejected the message, your outbound server queued it, retried 2 hours later, and it was accepted and delivered within seconds. The total transit looks long, but the actual wait was in the retry queue — which the header chain accurately reflects.
Why is my email header missing some hops?
Some servers strip or suppress Received: headers for privacy or anti-spam reasons. Large cloud providers sometimes consolidate internal hops. If your header shows fewer hops than expected, some servers in the chain are not recording their handoffs.
Is the data I paste here stored anywhere?
No. WhyIsMyEmailLate runs entirely in your browser. No email headers are transmitted to any server, logged, or stored. The optional PII masking feature operates entirely in client-side JavaScript and only modifies what is displayed — your original pasted data is never touched.
How does the Transit Narrative interpret what caused my delay?
The Transit Narrative uses pattern-matching on two signals: the duration of the largest delay and the naming conventions of the server where that delay occurred. For example, a 4–15 minute hold is characteristic of greylisting; a server hostname containing words like "corporate" or "internal" suggests a gateway policy hold; a delay exceeding one hour with no recognizable pattern is flagged as a critical delay requiring escalation. These are probabilistic interpretations — the same 10-minute delay could be greylisting, a spam scan, a queue backlog, or something else entirely depending on infrastructure that the headers do not expose. What "delay" means can also differ across organizations: some treat anything over 30 seconds as a delay; others consider 15 minutes routine. The Transit Narrative reflects common industry conventions, not a universal standard. Always treat it as a starting point for investigation, not a verified diagnosis. The hop-by-hop graph and raw header data below the narrative are your ground truth.
This guide covers the most common scenarios in modern email delivery infrastructure. For enterprise mail troubleshooting, share the Downloaded Report with your mail administrator.