How does greylisting work?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You send an email to someone who uses a mail server with greylisting enabled. Instead of accepting or rejecting it, the server says: "Not yet. Try again in a few minutes." That's greylisting in a nutshell.

Here's the full three-step sequence:

Step 1: First contact. Your mail server connects and tries to deliver the message. The receiving server checks the combination of three things: your sending IP address, your sender address (the "from"), and the recipient address. If it hasn't seen this exact combination before, it issues a temporary rejection, usually something like "451 Try again later" or "421 Service temporarily unavailable." This is called a 4xx deferral. It's not a hard bounce. It means "come back."

Step 2: The wait. The receiving server holds that three-piece combination in memory (IP + sender + recipient). It expects a legitimate mail server to try again automatically, because that's what SMTP requires. Legitimate mail servers (called mail transfer agents, or MTAs) are built to retry failed deliveries on a schedule, typically every 15 to 60 minutes.

Step 3: Retry accepted. When your server retries and presents the same combination, the receiving server recognizes it and accepts the message. You're now on the "known good" list for that combination, so future messages from you to that recipient usually go straight through.

Why does this stop spam? Most cheap spam engines don't bother with retries. They blast millions of addresses and move on. If a server says "come back later," they don't. That's the behavioral gap greylisting exploits.

The downside for legitimate senders is a short delay on first contact, usually 5 to 30 minutes. That's usually fine for marketing email. It's less fine for password resets or time-sensitive transactional emails, which is why well-configured mail servers prioritize retries quickly, and why major ESPs have often already established trusted relationships with the receiving servers you care about most.

Still if you're seeing consistent delivery delays that look like greylisting (4xx deferrals on first send, then successful delivery on retry), that's generally not a cause for alarm unless the delays are unusually long or happening on all your sends. For persistent deferral problems, sender reputation is usually the underlying variable worth investigating.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Get a diagnosis for your specific delivery delays.

I read this on the Email Almanac about how greylisting works. My situation: I'm sending from describe your ESP or mail server setup. I've noticed [describe: delivery delays / 4xx deferrals in logs / specific recipients or domains that seem to delay delivery]. My typical send volume is X per day/week. What I want to understand: whether greylisting is causing my delivery delays, whether this is expected behavior or a warning sign, and whether there's anything I should configure differently.

Edit the yellow boxes, then send to the AI of your choice.