Why is my email delayed?

Every mail server that handles a message adds a Received header with a timestamp. To find a delay, convert each timestamp to UTC, read the headers from the bottom up, and subtract each one from the next. The hop where the gap jumps from seconds to minutes or hours is where the message waited. The usual culprits are greylisting at the receiving server, a backed-up queue at the sender, slow spam filtering, an outage, or a message whose Date: was set long before it was actually sent.

How the timestamps work

Each server prepends its Received line, so the newest is at the top and the first hop is at the bottom. RFC 5321 §4.4 forbids changing or reordering earlier lines, and asks servers to write times as local time with a numeric offset such as -0400, precisely so delays between relays can be compared. The timestamp is the moment that server accepted the message, written after the final semicolon:

Received: from out2.example.com (out2.example.com [198.51.100.20])
        by mx.example.net with ESMTPS id 4Xk2; Mon, 26 Oct 2026 14:31:40 +0100

The offset says how far that clock is from UTC: +0100 is one hour ahead, so 14:31:40 +0100 is 13:31:40 UTC. Subtract a positive offset, add a negative one. The date format, including the older named zones like EST and GMT, is defined in RFC 5322 §3.3. See Received headers for the rest of the line.

A worked example

Here are the trace headers of a synthetic message, newest first, as they appear:

Received: from mx.example.net (mx.example.net [203.0.113.8])
        by store.example.net with LMTP; Mon, 26 Oct 2026 13:31:41 +0000
Received: from out2.example.com (out2.example.com [198.51.100.20])
        by mx.example.net with ESMTPS; Mon, 26 Oct 2026 14:31:40 +0100
Received: from smtp.example.com (smtp.example.com [198.51.100.5])
        by out2.example.com with ESMTP; Mon, 26 Oct 2026 12:58:15 +0000
Received: from [192.0.2.10] (unknown [192.0.2.10])
        by smtp.example.com with ESMTPSA; Mon, 26 Oct 2026 08:58:14 -0400
Date: Mon, 26 Oct 2026 08:58:12 -0400

Converted and read bottom-up:

Three different offsets, all describing the same morning. Without conversion, hop 3 looks like it happened an hour and a half after hop 2; in fact it was about 33 minutes. That one gap is the whole story: the sender's outbound relay held the message for half an hour before the recipient's server accepted it. A gap like that at the boundary between two organizations, with no gap anywhere else, is the classic signature of greylisting.

The analyser does this arithmetic for you and draws the chain as a timeline with the delay on each hop.

Common causes

Greylisting

A receiving server that greylists answers a first delivery attempt from an unfamiliar source with a temporary error (a 4xx code, often 450 or 451), and remembers the combination of sending IP, envelope sender and recipient. Legitimate mail servers queue the message and try again; many spam tools do not. When the retry comes in after a minimum wait, the server accepts it. RFC 6647 §5 recommends accepting retries that arrive anywhere from about one minute to 24 hours after the first attempt by default.

How long the delay is depends mostly on the sender's retry schedule. RFC 5321 §4.5.4.1 says retries to a failed destination should generally wait at least 30 minutes, while noting that two attempts in the first hour followed by backing off works well in practice. Large senders often retry sooner. Expect anywhere from a minute or two to an hour or so for a greylisted first message; repeat mail from the same sender usually goes straight through afterwards. If the sender's outbound pool uses different IPs on each retry, the delay can repeat.

What you see: a single gap at the hop where mail crosses from the sender's last server to the recipient's first one.

Sender-side queueing and throttling

Bulk senders deliberately pace mail per receiving domain, and receivers rate-limit senders who send too fast. A busy or misconfigured outbound server can also simply back up. The gap shows up in the same place as greylisting, so the two are hard to tell apart from headers alone. Large newsletters arriving hours late with no other gaps are usually throttling.

Spam filtering, sandboxing and security gateways

Content scanning normally takes seconds. Attachment sandboxing, where the file is opened in an isolated machine to watch its behavior, can take minutes. Look for a gap between two servers inside the recipient's organization, often with a hostname belonging to a security service.

Outages

If a server along the way is unreachable, the previous one queues and retries on its normal schedule, giving gaps of tens of minutes to hours. Outages affect many messages at once, so other mail from the same period will show the same gap.

Clock skew and negative delays

A timestamp is only as good as the clock of the server writing it. If a hop appears to happen before the one beneath it, giving a negative delay, one of the clocks is wrong, or the offset is. Small negative values of a few seconds are common and harmless. Large ones mean a misconfigured server, so treat delays around that hop with suspicion.

The Date header is not the send time

The Date: header records when the author's software considered the message finished, not when it was transmitted (RFC 5322 §3.6.1). It can be far earlier than the first Received line for innocent reasons:

• the message sat in Drafts and was sent later (some apps keep the original Date, some update it);
• the device was offline and the message waited in the Outbox;
• the user used scheduled send or "send later" (whether Date reflects the scheduled time varies by app);
• the message was composed in a web form or app that queued it.

So a large gap between Date: and the first Received line usually reflects the sender's device or habits, not the mail system. To measure network delay, start from the first Received hop instead. More in the Date header guide.

Which delays are worth chasing

If the big gap is at the hop entering your organization, talk to whoever runs your mail; greylisting and filtering settings are theirs. If it is before the message left the sender's servers, only the sender can fix it. If the gap is between Date: and the first Received line, nothing in transit was slow. To get the headers in the first place, see how to view email headers.