Greylisting Explained: Why Your Emails Arrive Late (and What to Do)

Greylisting is a receiver-side anti-spam technique where the receiving mail server temporarily rejects the first delivery attempt from an unknown sender with a 451 4.7.1 temporary failure, then accepts it when the sending server retries — which legitimate mail servers always do and spam bots usually don't. The result: genuine email arrives late (typically 1–30 minutes on first contact), while one-shot spam blasts never get through. As a sender you can't disable it, but you can minimize its impact.

Here's how the mechanism actually works, why your OTP emails take eight minutes to arrive at some domains, and the short list of things that are actually within your control.

What is greylisting, exactly?

SMTP has two flavors of rejection. A 5xx code is permanent: "no, and don't try again." A 4xx code is temporary: "not right now — retry later." Greylisting exploits the second one.

When a receiving server with greylisting enabled sees a delivery attempt from a sender it doesn't recognize, it answers with something like:

451 4.7.1 Greylisting in action, please come back later

The sending server queues the message and retries after its normal retry interval (often 1–15 minutes for the first retry, depending on MTA configuration). On the retry, the greylisting server recognizes the sender, lets the message through, and usually remembers the sender for a whitelist window — industry defaults are commonly around 24–36 days, after which the entry expires.

The whole scheme rests on one observation from the early 2000s (the original paper is Evan Harris's 2003 "The Next Step in the Spam Control War"): spam-sending software is built for volume, not reliability. A botnet blasting millions of messages from compromised machines typically makes one attempt per address and moves on. Retrying costs the spammer time and infrastructure; it costs a legitimate MTA nothing, because retrying on 4xx is already baked into the SMTP spec (RFC 5321 requires it).

Modern reality check: the big mailbox providers (Gmail, Microsoft, Yahoo) do not use classic greylisting — they have better signals. You'll hit greylisting mostly at smaller corporate mail servers, cPanel/Plesk hosting, ISP mailboxes, some European providers (GMX and several German hosts are known for it), and anti-spam appliances. But if you send B2B or transactional mail at any scale, a slice of your list sits behind greylisting right now.

How does the greylisting triplet work?

Greylisting servers don't track senders by a single field. They track a triplet of three values:

1. Connecting IP address (sometimes a /24 block instead of the exact IP)
2. Envelope sender (the MAIL FROM address)
3. Envelope recipient (the RCPT TO address)

A connection is greylisted if that exact triplet hasn't been seen before. This has practical consequences for senders:

• Send from consistent IPs. If your ESP rotates you across a pool of outbound IPs, each new IP restarts the greylisting delay for every recipient domain. Good ESPs keep triplet-consistent mappings or pre-warm their pools; cheap ones don't.
• Keep your envelope sender stable. If your bounce address changes per message (VERP-style encoding like bounce+user123=@...), some greylisting implementations treat each variant as new. Most modern implementations normalize this, but old ones don't.
• Bulk sends to the same domain amortize well. After the first triplet to company-x.com passes, subsequent messages from the same IP/sender to other recipients at that domain may still be triplet-new — implementation-dependent — but many servers whitelist at the IP or sender level after a threshold, so delays collapse quickly on a warm relationship.

What does a greylisting deferral look like in an SMTP transcript?

Here's a real-shaped session, the kind you'd see in your MTA logs. First attempt:

-> 220 mx.company-x.com ESMTP ready
<- EHLO mail.acmebilling.com
-> 250-mx.company-x.com greets mail.acmebilling.com
<- MAIL FROM:<[email protected]>
-> 250 2.1.0 Sender OK
<- RCPT TO:<[email protected]>
-> 451 4.7.1 Greylisted, please try again in 300 seconds
<- QUIT

Your MTA logs 451, queues the message, and retries per its schedule. Fifteen minutes later:

<- RCPT TO:<[email protected]>
-> 250 2.1.5 Recipient OK
<- DATA
-> 354 End data with <CR><LF>.<CR><LF>
-> 250 2.0.0 Message accepted for delivery

Two things to note. First, the 451 arrived at the RCPT TO stage — the server waited until it had the full triplet before deciding. Some implementations defer at DATA instead. Second, the deferral message helpfully stated the embargo ("300 seconds"), but many servers don't, and your MTA will just follow its own retry schedule regardless.

The important operational point: a `451` is not a bounce. It's a deferral. Your queue should hold the message and keep retrying for hours (standard practice is 4–5 days before giving up). If your sending software surfaces greylisting deferrals as failures, that's a reporting bug, not a deliverability problem. For the full taxonomy of 4xx vs 5xx responses, see our SMTP error codes explainer.

How long does greylisting actually delay email?

The delay equals max(remaining embargo, your MTA's retry interval). Typical values in the wild:

So for most send-receive pairs, the first ever email waits 5–20 minutes, and everything after that flows instantly until the whitelist entry expires. The pain concentrates in exactly one scenario: the first email to a new recipient — which, unfortunately, is usually a signup confirmation, an OTP (one-time passcode), or a password reset.

Why do OTP and password-reset emails suffer the most?

Three reasons collide:

1. They're always first-contact. A user signing up at your app for the first time is, by definition, a triplet the recipient server has never seen.
2. They're time-sensitive. A 10-minute greylisting embargo on an OTP with a 5-minute validity window means the code is dead on arrival. The user requests another code — which generates a new message, sometimes greylisted again if the envelope sender encoding changed, and the loop repeats.
3. User behavior punishes you. Users don't blame the recipient's mail server. They blame your app, request three resets, and a few will mark the eventually-arriving duplicate as spam — which hurts your complaint rate on top of everything.

If OTP delays at greylisting domains are hurting you, the mitigations are:

• Extend OTP validity to 15–30 minutes so codes survive the embargo.
• Stable identity: send all transactional mail from one consistent IP set and one consistent envelope sender so the whitelist entry sticks after the first success.
• Pre-warm the triplet where possible: if your signup flow sends a confirmation email before the OTP email, the confirmation eats the greylisting delay and the OTP (sent minutes later, same triplet if the recipient matches) goes straight through.
• Measure it. Track deferral rates per recipient domain in your logs; a sudden spike in 451s from one corporate domain tells you they changed their appliance settings, and you can adjust OTP TTL for that domain specifically.

What can senders actually control?

Honestly: not much, and that's by design. Greylisting is the receiver's defense. But here's the complete list of sender-side levers:

1. Make sure your MTA retries correctly. This is the big one, and it only matters if you run your own mail server. Verify your retry configuration:

# Postfix: check retry intervals
postconf | grep -E "queue_run_delay|minimal_backoff|maximal_backoff|maximal_queue_lifetime"

Sane defaults: first retry within 5 minutes, queue lifetime of at least 24 hours (5 days is the Postfix default). A misconfigured server that retries only once after 30 minutes, or gives up after an hour, will hard-fail against strict greylisters. Some greylisting servers also flag "impatient" retryers — retrying during the embargo can restart the timer on strict implementations.

2. Keep your sending infrastructure boring. Consistent IPs, consistent HELO hostname, consistent envelope sender, valid reverse DNS (PTR). Greylisting servers frequently stack checks: a deferred message from an IP with no PTR record may get additional scrutiny on retry.

3. Don't confuse greylisting with throttling. Gmail's 421 4.7.0 ... rate limited and Yahoo's 451 ... tempfail are reputation-based throttling and rate limits, not greylisting — retrying those faster makes things worse, and they don't come with a whitelist window. Greylisting is identity-based ("have I seen you before?"); throttling is behavior-based ("I don't like your volume or reputation right now").

4. Accept it. For the long tail of greylisting domains, 5–15 minutes of first-contact delay is simply the cost of delivery. Build your UX around it: "Check your email — it may take a few minutes" beats a support ticket.

If you want to see how your own sending setup behaves — whether your MTA retries properly, whether your IPs are consistent, whether your authentication passes on the retry — send a message through the deliverability tester. It scores the full path and flags infrastructure inconsistencies that greylisting-adjacent filters also penalize.

What can recipients and IT admins do?

If you're on the receiving side — you're the IT admin whose users complain that password resets take forever — you have the real controls:

• Whitelist by IP or CIDR. Every greylisting implementation (postgrey, Postfix postscreen, cPanel's, MailMarshal, etc.) supports an exceptions list. Add your critical vendors' sending IPs: payroll, SSO, monitoring alerts, your ESP's transactional ranges.
• Whitelist by envelope sender domain, where supported — more robust than IPs because ESPs rotate IPs.
• Lower the embargo for internal-facing MX hosts. Many shops run 5 minutes externally and 1 minute (or none) on secondary MXes that partners use.
• Consider whether you still need it. Greylisting's catch rate has declined as spammers added retry logic and as better filters (reputation, content, DMARC enforcement) matured. Plenty of admins now run it only as a light first pass with a 60-second embargo, purely to shed fire-and-forget bot traffic.

To find out which MX hosts and providers serve a given domain — useful before you start whitelisting — run the domain through the MX lookup tool and you'll see the exact servers doing the deferring.

How do you confirm greylisting is your actual problem?

Before redesigning your signup flow, verify the delay is really greylisting. The evidence is in your own logs:

# Postfix: find 451 deferrals grouped by recipient domain
grep "status=deferred" /var/log/mail.log | grep "451" \
  | grep -oE 'relay=[^,]+' | sort | uniq -c | sort -rn | head

You're looking for three signatures. First, the deferral code is 451 (or occasionally 450) with text mentioning "greylist," "come back," or "try again later" — not 421/452, which point to throttling. Second, the message is accepted on retry without any change on your side; if you pull the full queue history for one message ID, you should see the defer-then-accept pattern with nothing else in between. Third, the delay clusters at first-contact recipients at specific domains rather than spread evenly across your traffic.

If deferrals repeat across many retries without eventual acceptance, that's not classic greylisting — that's a server that has decided it doesn't like you. Check your IP's PTR record and authentication alignment before assuming time will fix it. And if you're building or testing transactional flows in staging, use an email sandbox so greylisting delays in test environments don't get mistaken for broken code — pair that with our guide on testing transactional email in development.