In-depth explanations of why emails get delayed — with real header examples and action steps.
Email delays are frustrating precisely because they're invisible. A message leaves your outbox instantly but doesn't arrive for minutes, hours, or even days — and the recipient sees nothing until it finally lands. The good news: every delay leaves a record. Raw email headers capture a timestamp at every server handoff, and that timestamp trail tells you exactly where time was lost. This guide covers the most common delay causes in depth — what they are, how to recognize them in raw headers, and what you can do about each one.
Greylisting is an anti-spam technique where a receiving mail server temporarily rejects the first delivery attempt from any sender it hasn't seen before. The rejection uses SMTP code 451 ("Service temporarily unavailable"), which legitimate mail servers interpret as a request to retry after a delay. Spam-sending systems, which typically attempt delivery only once and move on, give up. Legitimate servers retry after the greylisting delay period — usually 5 to 15 minutes, sometimes up to an hour — and the message is then accepted.
In email headers, greylisting appears as a gap of 5–60 minutes between the first outbound relay hop and the first receiving server hop. You may also see multiple identical "from" entries from the same sending server with increasing timestamps — each represents a retry attempt. After the greylisting period expires, a successful delivery attempt produces the final Received: entry with the receiving server.
What to do: Usually, nothing. Greylisting delays are one-time occurrences — once the sending server's IP/domain combination is added to the receiver's whitelist, future messages deliver immediately. If greylisting delays are chronic and affecting time-sensitive communications, the sending domain's administrator can request whitelisting from the receiving domain's mail administrator.
Queue backlog is the most common cause of multi-hour email delays. Every mail server maintains a queue of messages waiting to be delivered. Under normal conditions, this queue is nearly empty — messages are delivered within seconds of being queued. But when a server is processing a large volume of outbound mail (bulk campaigns, end-of-day batch sends, a server recovering from maintenance), new messages wait in the queue behind earlier ones.
In headers, a queue backlog delay appears as a large gap between the sender's client submission hop and the first outbound relay hop. The message was accepted by the submission server immediately, but the relay didn't actually attempt delivery until much later. Unlike greylisting, which shows multiple retry attempts, a queue backlog typically shows a single large gap followed by a normal delivery sequence.
What to do: If you send through a shared mail provider (an ESP or shared hosting mail server), queue backlogs during peak hours are normal and unavoidable. For time-sensitive communications, consider using a dedicated IP with a transactional email service (Amazon SES, SendGrid, Mailgun) that offers prioritized delivery queues. For corporate senders, your mail administrator can investigate the outbound queue depth and server load at the time of the delay.
Modern email security gateways don't just check sender reputation — they scan the full content of every message before accepting it. Content scanning involves natural language processing to detect spam patterns, URL analysis to check whether linked domains are on blocklists, attachment inspection for malware, and image analysis. Complex messages with rich HTML, multiple images, or links to recently registered domains take longer to scan. Large attachments, especially PDFs or ZIP files, can add 30–60 seconds of inspection time per message.
In headers, content filtering delays appear at the receiving gateway hop. The message was accepted by the sending server normally, traveled across the network in milliseconds, but then waited at the receiving gateway's inbound scanning cluster before being passed on to the internal mail server.
What to do: Persistent content filtering delays are a signal that your messages are triggering more intensive scanning. Review your message content for characteristics that increase spam scores: overly aggressive marketing language, excessive use of images relative to text, links to domains with poor reputation scores, or attachments of types commonly associated with malware. Tools like Mail Tester (mail-tester.com) can score your messages before you send them.
Enterprise organizations deploy email security gateways that enforce organizational policies well beyond basic spam filtering. A policy hold occurs when a message triggers a rule that requires human review before delivery: messages containing certain keywords, attachments of a restricted file type, messages from external senders to distribution lists, or messages that match a data loss prevention (DLP) pattern. These holds can last from 30 minutes (if IT reviews the queue regularly) to 24+ hours (if the review queue is low-priority).
Policy holds are identifiable in headers by a very large time delta at a gateway hop with a hostname that includes vendor names (proofpoint.com, mimecast.com, barracudanetworks.com) or internal naming conventions (inbound-gateway, mailfilter, secure-mx). The message arrives at the gateway promptly, then sits in the hold queue until a policy reviewer releases it.
What to do: If you're the sender, contact the recipient's IT department with your Message-ID and the exact send timestamp and ask them to check whether the message is in a policy hold queue. If you're the recipient and expecting time-sensitive messages from external senders, work with your IT team to establish approved sender or domain exceptions in the gateway configuration.
Before a sending MTA can deliver a message, it must perform a DNS lookup to find the recipient domain's MX records. If DNS is slow, returning inconsistent results, or the MX records point to servers that are temporarily unreachable, the sending server must retry. Standard retry schedules for DNS failures are typically 15 minutes, 1 hour, and 4 hours, with a final bounce after 48–72 hours of failed attempts.
DNS-related delays appear in headers as a gap before the first receiving server hop, but — unlike queue backlog delays — they are typically accompanied by multiple retry attempts. You may also see error codes in NDR (Non-Delivery Report) messages if the DNS failure results in a permanent bounce.
What to do: If you're the recipient's domain administrator, verify your MX records are correctly configured and that your mail servers are responding to external SMTP connections. Use MXToolbox (mxtoolbox.com) to test your MX record resolution and connectivity from multiple geographic locations.
Major email providers — Gmail, Microsoft 365, Yahoo Mail — throttle inbound SMTP connections from senders with unknown or low reputation scores. This is a defense against spam campaigns where a single sending IP tries to deliver thousands of messages quickly. When a sender is being rate-limited, the receiving server returns a temporary deferral (SMTP 421 or 450) and the sending server must retry. Each retry attempt appears as a repeated Received: entry with an incrementing timestamp.
What to do: Rate limiting is a sender reputation issue. Build IP reputation over time by sending consistent, low-volume mail from a dedicated IP, implementing proper SPF/DKIM/DMARC authentication, and maintaining low bounce and complaint rates. Google Postmaster Tools (postmaster.google.com) provides visibility into your IP and domain reputation with Gmail specifically.
Server clock skew is a special case that doesn't represent a real delivery delay but can look like one — or, more confusingly, can produce a negative time delta that appears to show the message arriving before it was sent. Clock skew occurs when one of the servers in the routing chain has a system clock that is out of sync with UTC. Even a few minutes of clock drift can create apparent anomalies in the timestamp sequence.
WhyIsMyEmailLate detects negative deltas in the Received: chain (where a later hop has an earlier timestamp than the previous hop), clamps those deltas to zero, and flags the affected hop with a Clock Skew indicator. This tells you the anomaly is a measurement artifact, not a real delay, and prevents the skewed timestamp from distorting the overall transit time calculation.
What to do: If you observe clock skew consistently from the same sending or receiving server, the server's NTP (Network Time Protocol) configuration may need attention. Report it to the relevant mail administrator with the Message-ID and the specific Received: header showing the skew.
Most email delays resolve on their own — greylisting clears after one successful retry, queue backlogs drain, and policy holds are eventually reviewed. Escalate to a mail administrator when: a message has not arrived after 4 hours with no NDR; delays are recurring on the same sending or receiving server; or you have time-sensitive communications that require delivery guarantees. When escalating, always provide the full Message-ID, the sender and recipient domains, the approximate send time, and the downloaded hop analysis report from WhyIsMyEmailLate — these give the mail administrator everything they need to search server logs and diagnose the issue quickly.