The invoice that was supposed to land at 9am showed up at 1pm. Four hours late. The client thought we forgot. We thought Gmail ate it.

Turns out neither was true. A temporary rejection at 9:01am, a 30-minute retry interval on the sender, and a recipient server that cleared the greylist after 15 minutes combined into a perfect storm of waiting. The email was fine. The path was slow.

Most people blame their email host when mail lags. Understandable — you're paying for email service, email was slow, therefore the service is broken. But nine times out of ten, the delay has nothing to do with your host. It's greylisting, retry intervals, or queue backlogs on intermediate servers. And unless you know where to look, you'll keep blaming the wrong system.

(I say this having blamed the wrong system many times myself. Embarrassing, but that's how you learn.)

We're the JustEmails team, part of Velocity Digital Labs — the same team behind JustAnalytics and ClickzProtect. We get support tickets about delayed email roughly once a week. The fix is almost never on our end — which honestly makes us feel a bit useless sometimes, but also relieved. This is how to figure out where your email actually got stuck.

What Is Greylisting and Why Does It Exist

Greylisting is a spam-fighting technique from the early 2000s that's still in use today. Here's how it works: when a server receives mail from an unknown sender/recipient pair, it rejects it with a temporary error code (450 or 451) and tells the sender to try again later. Legitimate mail servers retry. Spam bots typically don't — they're moving too fast across too many targets to bother waiting.

The receiving server keeps a record: this IP tried to send to this address, rejected at this timestamp. If the same combination shows up 5-30 minutes later (depends on configuration), the mail goes through and future sends from that pair get whitelisted.

Works great against spam. Works terribly for urgent email. Honestly, I hate greylisting. It's a blunt instrument from an era when spam filtering was less sophisticated, and it punishes legitimate senders for the sins of spammers.

The problem is you can't see it happening. Your mail server sends the message, gets a 450 response, queues the message for retry, and eventually delivers it. From your inbox, the email just shows up late. From the recipient's inbox, same thing. There's no "greylisted" indicator anywhere unless you dig into server logs or headers.

Enterprise domains love greylisting. University mail systems. Government email. Older corporate Exchange installations. Small businesses running their own mail on Postfix with default configs. If you're sending to any of these, first-contact delays are almost guaranteed.

Reading Received Headers: The Diagnostic Tool Nobody Uses

Every email carries a stack of Received headers — one for each server that touched the message. They're added in reverse order (newest at top), and they include timestamps.

This is your forensic trail. Learn to read it.

In Gmail: open the message, click the three dots, click "Show original." In Outlook: File > Properties > Internet Headers. In Apple Mail: View > Message > All Headers.

What you'll see (simplified):

Received: from mx2.recipient.com (mx2.recipient.com [192.0.2.50])
        by mx.google.com with ESMTPS id xyz123
        for <user@recipient.com>; Tue, 17 Jun 2026 13:02:15 -0700 (PDT)
Received: from mailout.sender.com (mailout.sender.com [198.51.100.10])
        by mx2.recipient.com with ESMTP id abc789
        for <user@recipient.com>; Tue, 17 Jun 2026 12:45:03 -0700 (PDT)
Received: from [10.0.0.5] (internal.sender.com [10.0.0.5])
        by mailout.sender.com with ESMTP id def456;
        Tue, 17 Jun 2026 12:44:58 -0700 (PDT)
Date: Tue, 17 Jun 2026 12:44:55 -0700

Read from bottom to top. The Date header is when the user clicked send. Each Received header shows when that server processed the message. The gaps between timestamps tell you where delays happened.

In this example:

12:44:55 — user clicked send
12:44:58 — sender's outbound server received it (3 seconds, normal)
12:45:03 — recipient's MX accepted it (5 seconds, normal)
13:02:15 — Google's server received it from the recipient's MX (17 minutes — something's off)

That 17-minute gap between mx2.recipient.com and mx.google.com? Could be internal routing at the recipient's end. Could be a queue backlog. The point: the delay wasn't at the sender. It happened after the message reached the recipient's mail system.

The Four Causes of Email Delay

1. Greylisting (Most Common for New Senders)

Look for a gap between your outbound server and the recipient's first MX. If your server sent at 9:00am and the recipient's MX logged receipt at 9:28am, but both servers show only one Received entry each — that's a greylist. Your server retried at 9:28 after the initial 450 rejection at 9:00.

You won't see the rejection in headers. Headers only record successful hops. The clue is the gap combined with a known greylist-happy destination (enterprise domains, .edu addresses, government mail).

Greylisting delays are typically 5-60 minutes. If you see 3-4 hours, it's probably retry timing compounding across multiple hops.

2. Sender Retry Interval

When a receiving server rejects with a 450/451 (temporary failure), your server queues the message and retries later. How much later? Depends on the server configuration — and you probably don't control it.

Postfix default retry: 5 minutes initially, then exponential backoff to 4 hours. Sendgrid: starts at 1 minute, backs off. AWS SES: 15 minutes. Postmark: 1 minute. Shared hosting providers: varies wildly, often 30+ minutes.

If the recipient's greylist clears after 5 minutes but your server retries every 30 minutes, you're waiting 30 minutes. Nothing broken, just unfortunate timing. Infuriating timing. But not broken.

This is why transactional senders like Postmark and SendGrid advertise fast retry loops — for time-sensitive messages like password resets, 1-minute retries matter. (We've lost count of how many "I never got the password reset email" tickets trace back to slow retries rather than actual delivery failures.) If you're building transactional email into your app, choosing between SMTP and API affects retry behavior too.

3. Queue Backlogs on Intermediate Servers

Sometimes the delay isn't a policy decision. It's just load. A mail server handling 50,000 messages/hour during a marketing blast might queue your message behind thousands of others.

The headers will show a gap between two Received lines from the same server, or a gap between the Date header and the first Received (queue delay on the sending side).

If you're on shared email hosting and another customer on the same IP is blasting a newsletter, your one-off message waits its turn. This is a good reason to separate transactional email from bulk sends — different IPs, different queues.

4. DNS Delays and MX Lookups

Less common, but worth mentioning. If the sending server can't resolve the recipient's MX records quickly (DNS timeout, misconfigured resolvers), it might retry the DNS lookup before attempting delivery. You'll see this as a gap before the first external hop.

DNS delays are usually seconds, not minutes. If you see a 10-minute gap at the DNS stage, something's wrong with the sending server's resolver configuration. Rare, but we've seen it.

What You Can Fix vs What's Normal

Fixable on your end:

Sender reputation. Better reputation = less greylisting. Ensure SPF, DKIM, and DMARC are configured correctly — our DMARC ramp-up guide walks through the full p=none to p=reject process. If you're starting from scratch, see our custom domain email setup guide for the complete DNS and authentication walkthrough. Warm up new IPs gradually. Keep complaint rates low. The recipient's greylisting system may auto-whitelist high-reputation senders.
Shared IP issues. If you're on shared hosting and experiencing regular delays, the culprit might be other senders on your IP. Dedicated IPs or a transactional email service with good IP hygiene (Postmark, Sendgrid, Postmark) can help.
Queue separation. Don't send marketing blasts from the same queue as time-sensitive transactional mail. At JustEmails, transactional API sends route through a separate pool from standard SMTP relay — see our SMTP vs API guide for when to use which. Learned that one the hard way.

Not fixable — just normal:

First-contact greylisting. You can't stop a recipient's server from greylisting. The first email to a new address at a cautious domain will often be delayed. Second email to the same address should be instant.
Recipient server load. If the delay happens after the recipient's MX accepted the message (internal routing), that's their infrastructure. You can't fix it.
Multi-hop routing. Some organizations route mail through multiple internal servers (compliance logging, spam filtering, archival). Each hop adds latency. A 3-hop internal path taking 10 minutes total isn't broken — it's just enterprise mail infrastructure being enterprise mail infrastructure. You can't fix it. You can only document it, sigh, and move on.

A Real Example: Diagnosing a 2-Hour Delay

A user reported an email sent at 10:12am Pacific arrived at 12:18pm. Two hours. They assumed our servers were down.

Here's the header trail (sanitized):

Date: Tue, 17 Jun 2026 10:12:05 -0700
Received: from justemails-out.app (10:12:08)
Received: from mx1.corpmail.example (10:12:12)
Received: from internal-filter.corpmail.example (11:45:23)
Received: from mailstore.corpmail.example (12:18:01)

10:12:08 — we sent it. 10:12:12 — their MX accepted it (4 seconds). 11:45:23 — their internal filter picked it up (93 minutes later). 12:18:01 — it hit the mailstore (33 minutes later).

The 93-minute gap between MX acceptance and internal filter? That's their queue, not ours. The additional 33 minutes to mailstore? Also internal. Our job ended at 10:12:12.

This is why header forensics matter. Without them, "email was 2 hours late" becomes a vague complaint that defaults to blaming the sender.

Did we feel vindicated? A little. Did we feel bad that we couldn't actually help? Also yes.

When to Actually Worry

Occasional 5-30 minute delays to enterprise domains: normal, greylisting. Occasional delays during high-send-volume periods: normal, queue load. First email to a new contact delayed, subsequent emails instant: normal, greylist whitelist working.

Worry if you see:

Consistent multi-hour delays to the same domain across multiple emails
Delays on sends to major providers (Gmail, Outlook.com) that aren't flagged as spam
Gaps appearing at your own outbound server (check the first Received after Date)
Bounce messages citing blocklist or reputation issues

If your headers show the delay starting at your outbound server, that's worth investigating. If the delay starts after the recipient accepted the message, it's their problem. Not much comfort when the client is annoyed, but at least you know where to point.

Frequently Asked Questions

Why would a receiving server greylist my email?

Greylisting is an anti-spam technique that temporarily rejects unknown sender/recipient combinations with a 4xx tempfail code — typically 450 or 451. The receiving server expects legitimate mail servers to retry, while spam bots usually don't bother. Most servers greylist for 5-30 minutes, though some aggressive configurations hold mail for 2 hours. If you're sending to enterprise domains with strict spam filtering, greylisting delays are common on first contact with any new address at that domain.

How do I know if a delay was greylisting vs a queue backlog?

Read the Received headers. Greylisting shows up as a long gap between two adjacent Received lines from different servers — the sending server held the message waiting to retry. Queue backlogs show up as a long gap between two Received lines from the same server, or a delay between the Date header and the first Received. Greylisting gaps are typically 5-30 minutes; queue backlogs can be minutes or hours depending on how overloaded the server was.

Can I prevent greylisting delays on my outbound mail?

Not directly — you don't control the recipient's greylisting settings. But you can minimize delays by improving sender reputation: ensure SPF, DKIM, and DMARC are properly configured, warm up new IPs gradually, keep complaint rates low, and use a reputable sending provider with established IPs. High-reputation senders often get whitelisted by greylisting systems automatically after the first successful delivery. Shared IPs on budget email services tend to hit greylisting more often because other senders on the same IP drag down the reputation.

Why does my email provider's retry interval matter?

When a receiving server returns a 4xx tempfail (greylisting or temporary overload), your sending server queues the message and retries later. The retry interval varies wildly: some servers retry in 1 minute, others wait 15-30 minutes. If the greylist window is 5 minutes but your server retries every 30 minutes, your email sits in queue for 30 minutes even though the recipient was ready after 5. You have no control over this on most hosted email — it's baked into the server configuration.

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares

Email Arriving Hours Late? Greylisting and Retry Queues Explained