deliverabilityGreylisting Explained: What It Is and What to Do as a Sender

Greylisting is when a receiving mail server temporarily refuses mail from a sender it hasn't seen before. It puts that sender on a greylist and answers with a temporary error, typically 450 (sometimes 451), and expects a legitimate mail server to try again later. According to IONOS, legitimate servers retry, while spam software typically doesn't.

For you as a sender, that means three things: let your sending system retry, don't remove an address after a single temporary error, and authenticate your mail. The rest of this guide explains why.

What greylisting is (greylist meaning)

RFC 6647, the IETF document that describes the technique, defines greylisting as "the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism."

In plain terms, a greylist is a waiting list on the receiving side. The server doesn't say yes or no to an unknown sender right away. It says "not now" and waits to see whether the sender comes back.

Greylisting is set up by whoever runs the receiving mail server. Neither the sender nor the recipient configures anything for it to work (IONOS). It's one of several anti-abuse tools a receiver can use, and it works on the delivery attempt, not on the content of the message.

How greylisting works, step by step

Here is what happens during SMTP greylisting, in the typical setup RFC 6647 describes:

1. Your server connects to the recipient's mail server and starts an SMTP conversation.
2. The receiver builds a triplet from the attempt: the sending IP address, the sender address (MAIL FROM) and the first recipient address (RCPT TO). This is the combination RFC 6647 recommends.
3. The triplet is unknown, so the receiver replies with a temporary error. RFC 6647 allows 421 or 450 for this; in practice you'll also see 451.
4. Your server queues the message and tries again later, as SMTP servers are expected to do after a temporary error.
5. The retry is accepted if it arrives after the receiver's minimum delay.
6. The receiver remembers the triplet, so later mail with the same combination is usually accepted without a delay. Postgrey, a greylisting tool for the Postfix mail server, also automatically allowlists clients that keep passing the check.

A greylisted exchange looks roughly like this. It's an illustrative example, not a real server log, and the wording of the reply differs from server to server:

S: 220 mx.example.net ESMTP
C: EHLO mail.sender.example
S: 250 mx.example.net
C: MAIL FROM:<news@sender.example>
S: 250 OK
C: RCPT TO:<alex@example.net>
S: 450 4.7.1 Greylisted, please try again later

The 4 at the start is the important part. Under SMTP (RFC 5321), a reply starting with 4 is a temporary failure, and one starting with 5 is permanent. Our guide to SMTP bounce codes explains the codes in detail.

How long the delay lasts

There is no single answer, because every receiver sets its own value. RFC 6647 recommends that receivers accept retries within a window of one minute to 24 hours. A retry that comes outside the window is treated as a new attempt.

Postgrey is one concrete example: by default, it temporarily rejects a triplet that it has never seen, or first saw less than 5 minutes ago (Postgrey).

So the delay depends on two settings: how long the receiver wants you to wait, and how soon your sending system retries. If your system retries before the receiver's minimum delay has passed, it gets another temporary error and has to try again.

Greylist vs blacklist vs whitelist

The three lists answer different questions. A greylist asks "will this sender come back?", a blacklist asks "do we distrust this sender?", and a whitelist says "skip the checks for this sender."

	Greylist	Blacklist (blocklist)	Whitelist (allowlist)
What it does	Defers mail from unknown senders for a while	Rejects or filters mail from senders with a bad reputation	Exempts trusted senders from checks
Based on	Whether the sender has been seen before and whether it retries	Reputation, for example spam complaints or spam trap hits	A list kept by the receiver
Typical reply	Temporary 4xx, delivery after a retry	Can be a lasting 5xx rejection	Normal acceptance
How long	Minutes to hours	Until the sender is removed from the list	As long as the entry is kept
What you can do	Retry; your sending system usually does this	Find and fix the cause, then request removal	Nothing on your side; the receiver decides

The lists can work together. RFC 6647 describes exceptions that let receivers exempt certain IP addresses or networks from greylisting, which is an allowlist in practice.

What greylisted looks like in your campaign reports

You usually won't see the word "greylisted" in a campaign report. Most sending tools show it as a deferral, a delayed message or a soft bounce, and the wording varies by tool. If you open the bounce details, look for a 450 or 451 reply, often with a text like "greylisted" or "try again later."

Many email service providers retry temporary failures automatically, so a greylisted message is often delivered later in the same send. Whether that happens depends on the platform's retry settings.

Here is where it goes wrong: if your sending system gives up too soon, or doesn't retry at all, the greylist turns into a bounce for a message that would have been accepted on the next attempt. That's why our bounce codes guide treats greylisting as a special case of 4xx.

Does greylisting affect deliverability?

Greylisting is about when mail arrives, not whether it lands in the inbox or the spam folder. Its side effects are about timing:

• Delay on legitimate mail. RFC 6647 names the delay imposed on legitimate mail as the most obvious drawback of greylisting, and it matters most for time-sensitive messages.
• Time-critical messages arrive late. IONOS points out that greylisting is a poor fit for messages such as password resets. Sign-up confirmations are time-sensitive in the same way.
• More delay with many sending servers. RFC 6647 notes that when a sender retries from a different outbound server, the receiver may see a new triplet and greylist the same message again.

Greylisting is only one reason for a 4xx reply. Full mailboxes, server load and rate limiting produce temporary errors too, so check the reply text before you decide what caused a deferral.

What to do as a sender

You can't switch greylisting off on someone else's server. You can make sure it costs you as little as possible:

• Send through a system with a standard retry queue. Established providers and mail servers normally retry temporary failures. If you run your own sending code, make sure it queues and retries 4xx replies instead of dropping them.
• Don't suppress an address on a single 4xx. One temporary error isn't evidence that the address is bad. Suppress only after repeated soft bounces; how many is a policy choice, and our guide to lowering bounce rates covers how to set it.
• Keep your sending source stable where you can. Sending from a consistent IP address or pool means receivers see a familiar triplet, so you're greylisted less often after the first delivery.
• Authenticate your mail. IONOS notes that greylisting works best alongside SPF, DKIM and DMARC. Set up SPF and DMARC for your sending domain.
• Send time-critical transactional mail from a warmed, consistent source. Password resets and confirmations suffer most from a delay, so don't send them from a new IP or a rarely used server.
• Check addresses before you send. Greylisting is temporary, but hard bounces from bad addresses aren't. A free email verifier lets you check addresses before a campaign.

Does greylisting still matter?

Yes, as long as receivers use it. Greylisting is still available in common mail software, for example Postgrey for Postfix. How widely it's used today varies by receiver, and we haven't found a reliable figure, so plan for it rather than assume it's gone: a working retry queue is all most senders need.

FAQ

What does greylisted mean?

It means a receiving server temporarily refused your message because it didn't recognize the combination of your sending IP, sender address and recipient. It expects your server to retry later.

Is greylisting a bounce?

It's a temporary failure, so many tools count it as a soft bounce or a deferral. It only becomes a real non-delivery if your sending system stops retrying before the receiver accepts the message.

Does greylisting block email permanently?

No. Greylisting is a deferral with a 4xx reply, not a rejection. The receiving server takes the message once your system tries again inside its retry window, which RFC 6647 recommends setting between one minute and 24 hours. Mail is only lost if the sending side gives up before a retry gets through.

How long does greylisting last?

That's up to each receiver. RFC 6647 recommends a retry window of one minute to 24 hours, and Postgrey's default turns away triplets first seen less than 5 minutes ago. After a successful retry, the receiver usually remembers you for later mail.

Is greylisting the same as a blacklist?

No. A greylist defers mail from unknown senders for a short time and then accepts it if the sender retries. A blacklist (blocklist) is based on reputation and can lead to lasting rejections. See spam traps and blocklists for how senders end up on one.

Can I avoid greylisting?

Not completely, because the receiver decides. A stable sending source, proper authentication and a standard retry queue keep the impact small. The "What to do as a sender" section above has the full list.

Does greylisting hurt my sender reputation?

We haven't found a source that treats a single greylist deferral as a reputation signal, and how receivers weigh deferrals depends on the receiver. What can hurt is what happens next: if your system doesn't retry, or you keep sending to addresses that bounce for other reasons, your bounce rate rises.

Check your list before the next send

Greylisting is temporary and your sending system can handle it. Invalid addresses are a different problem. Try the free email verifier to check addresses before you send, and read our SMTP bounce codes guide to tell temporary errors from permanent ones.