Greylisting explained

Greylisting is an anti-spam technique: a receiving mail server answers a sender it does not know yet with a temporary 4xx reply and accepts the same message when it comes back later. It works because a lot of spam software never retries, while a real mail server keeps the message in its queue and tries again. For a legitimate sender the cost is a delay, not a lost message, as long as the sending system queues and retries. For address verification, a greylisting reply means "ask again later": it says nothing about whether the mailbox exists.

What greylisting is

The IETF describes the practice in RFC 6647, Email Greylisting: An Applicability Statement for SMTP (June 2012). In the broad sense, greylisting is any reduced service for an unknown or suspect source for a limited time, which the RFC says is typically minutes or a few hours. In the narrow sense, which is how most people use the word, it is an SMTP temporary failure reply sent to such a source.

RFC 6647, section 1.1, gives two reasons it works:

• Purpose-built spam software often supports only part of SMTP. When it gets a temporary failure, it moves on to the next address instead of retrying.
• Delaying mail from a newly seen IP address gives blocklists time to catch up. If the source is a spammer, by the time it retries it may already be listed, and the retry is refused.

The RFC is also clear about what greylisting is not: not every temporary failure is greylisting. A sender has no way to know why a server deferred it (section 3), which is exactly why every 4xx reply must be handled the same way: queue and retry.

The triplet

A greylisting server remembers who has tried to send to it. RFC 6647, section 2, lists where in the SMTP session it can decide: at the connection, at HELO/EHLO, at MAIL, at RCPT, or at DATA.

The classic design is the triplet. RFC 6647, section 5, recommends keying the record on three values:

1. the IP address of the sending server,
2. the envelope sender (the address in MAIL FROM, also called the return path),
3. the first envelope recipient (the first RCPT TO).

The first recipient is enough because, as the RFC notes, legitimate servers do not appear to reorder recipients between retries. After one successful retry, the RFC recommends accepting all further traffic from that IP address, whatever the envelope says.

The timing the RFC recommends

Some sites raise the low end of the window to match common retry intervals, but the RFC sees little benefit in doing so. Section 2.1 gives 30 minutes as an example of a minimum age before a new source is accepted.

How greylisting looks to a sender

RFC 6647, section 5, makes no specific recommendation for the reply code. Under SMTP rules, it says, the only two reasonable choices are 421 if the server wants to close the connection, and 450 otherwise. In practice, codes and texts vary by software, and the text may say "greylisted" or simply ask you to try again later. An illustrative exchange:

S: 220 mx.example.net ESMTP
C: EHLO mail.example.com
S: 250 mx.example.net
C: MAIL FROM:<bounces@example.com>
S: 250 2.1.0 Sender OK
C: RCPT TO:<pat@example.net>
S: 450 4.7.1 <pat@example.net>: Greylisted, please try again later
C: QUIT
S: 221 2.0.0 Bye

Our bounce code dictionary explains a typical greylisting reply, 451 4.7.1. Some deferrals look similar but have other causes, and waiting alone does not fix them:

• 450 4.2.1: at Gmail, one mailbox is receiving mail faster than it allows.
• 421 4.7.0: a policy deferral, for example missing reverse DNS or low reputation.
• 421 4.7.28: Gmail is slowing down a sender because of an unusual rate of unsolicited mail.

A simple test: greylisting accepts the first retry that arrives inside its window, so a correctly configured sender gets through on its next attempt. A deferral that repeats for hours or days is something else. Read the text after the code.

Queue and retry: what RFC 5321 asks

RFC 5321, the SMTP standard, already requires the behavior that greylisting relies on. Section 4.2.1 defines a 4yz reply as transient: the action did not happen, but it may succeed if repeated, and the client should try again. Section 4.5.4.1 sets the sending strategy:

• Mail that cannot be sent right away must be queued and retried.
• After a failed attempt, the sender must wait before retrying the same destination. The retry interval should generally be at least 30 minutes.
• Retries continue until the message is sent or the sender gives up. The give-up time generally needs to be at least 4 to 5 days.
• The retry settings must be configurable. Experience, the RFC says, favors two attempts in the first hour, then one every two or three hours.

A retry after 30 minutes falls well inside the default window of RFC 6647, so a standards-following server gets through on its second attempt. The price is that delay. RFC 6647, section 3, notes that some popular mail servers wait an hour or more before retrying, which matters for time-critical mail such as sign-in codes.

Never treat a 4xx as a bounce

RFC 6647, section 4.2, describes a failure of some SMTP implementations: treating every error as final. The message then returns to the sender as undeliverable, and the address may be removed from a mailing list for no reason. M3AAWG makes the same point in its Sender Best Common Practices (version 3.0, February 2015, section 3.8): senders must not treat temporary failures as permanent, because some receivers temporarily refuse a first message to see whether the sender follows the RFCs.

In practice:

• Send through a mail server or sending platform that keeps a real queue. A script that talks SMTP directly and gives up on the first 4xx will lose greylisted mail.
• Count a deferral as a soft bounce only if the message finally expires in the queue (4.4.7 is the usual sign).
• Keep greylisting deferrals out of your suppression logic. How to classify what does come back is in bounce processing and DSNs.

Shared IP pools and changing envelopes

The triplet assumes that a retry looks like the first attempt. RFC 6647, section 4.1, lists the cases where it does not:

• Several outbound servers sharing one queue. If the retry leaves from a different server, the receiver sees a new IP address and greylists the same message again. A sending IP that changes between attempts, for example through DHCP, has the same effect.
• Several inbound servers without a shared database. The retry reaches a second MX host that has never seen you.
• Infrequent senders. A server that mails a domain rarely can age out of the database and be greylisted again for a high percentage of its mail.

Section 4.2 adds one that matters for bounce handling: some senders encode message-specific details in the MAIL FROM address. If that address changes between retries, the server may treat each retry as a new delivery, and the message is never delivered. Per-recipient return paths (VERP) are fine; just keep the return path of a given message identical on every retry.

Repeated greylisting can mean long delays, out-of-order delivery, or a message returned after the give-up time. What helps:

• Retry from the same IP address when you can. If you send from a pool, see shared vs dedicated IPs.
• Keep the envelope sender stable for each message across retries.
• Rely on the receiver side too: RFC 6647 allows tracking whole /24 blocks, which helps clusters on one network but not clusters spread across networks, and it recommends letting known senders such as email service providers bypass greylisting (section 5).

What greylisting means for address verification

Verification asks the recipient's mail server about a mailbox without sending a message (see how verification works without sending). RFC 6647, section 4.2, notes that greylisting interferes with exactly this kind of session, whether it comes from a legitimate application or from a spammer harvesting addresses.

When a server defers the check, there is no reliable answer yet. Our result is then unknown with the reason greylisted and the action retry_later. What to do:

• Keep the address. A greylisting reply says nothing about the mailbox; do not suppress it.
• Check again later. A second check minutes or hours later often gets a definite answer. unknown results use no credit.
• Do not retry in a tight loop. Repeating the check every second does not help.
• On sign-up forms, accept the address and check it again later instead of blocking the person (sign-up form validation).

Be realistic about the limit: some servers keep deferring unfamiliar clients, and some answers stay unknown. For those, a confirmation email (double opt-in) settles the question.

Questions

How long does greylisting delay a message?

Usually one retry interval. RFC 6647's default window starts 1 minute after the first attempt, so the delay depends mostly on how long the sending server waits. With the 30-minute interval RFC 5321 suggests, expect about half an hour.

Is a greylisted message a soft bounce?

No. The message is still in the sender's queue and will be retried. It becomes a failure only if every retry fails until the give-up time.

Can I stop being greylisted?

Not on your own. RFC 6647, section 2.7, expects well-behaved senders to be added to the exception list after their first proper retry. Retry correctly, from a stable IP, with a stable envelope.

Try it

Check an address in the free email checker; if the result is unknown with the reason greylisted, check it again later.

Related

• The unknown status: greylisted and the other reasons for unknown.
• Glossary: greylisting and soft bounce.
• Bounce code 451 4.7.1 and the bounce code dictionary.

Related guides

• Bounce processing and DSNs explained
• Verify an email address without sending a message
• Reduce your email bounce rate
• Shared vs dedicated sending IPs
• Catch-all emails explained
• All guides

Sources

• RFC Editor: RFC 6647, Email Greylisting: An Applicability Statement for SMTP: definition, greylisting points, the triplet, timing defaults, unintended consequences, verification.
• RFC Editor: RFC 5321, Simple Mail Transfer Protocol: reply classes (section 4.2.1) and the queue and retry strategy (section 4.5.4.1).
• M3AAWG: Sender Best Common Practices, version 3.0: section 3.8 on handling temporary failures.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.