Greylisting: Why a Real Email Address Comes Back Unknown

Greylisting is a spam filter that temporarily refuses mail from any sender it has not seen before, then accepts the same mail when the sender retries later. An email verifier checks once and does not come back, so a valid address on a greylisting server returns unknown. The mailbox may be fine. The server simply has not answered yet.

Evan Harris proposed greylisting in 2003. His paper observed that "the vast majority of spam appears to be sent from applications designed specifically for spamming," and that those applications "never attempt a true retry as a real MTA would." The filter exploits that gap. It still works: Pagani et al. (2016) measured greylisting "preventing over 50% of the spam to be delivered to the users inboxes."

What is greylisting?

Greylisting is a delay applied to unfamiliar senders. It never rejects mail permanently. Harris explained the name himself: "Greylisting got its name because it is kind of a cross between black- and white-listing, with mostly automatic maintenance."

The sender's queue takes the cost. In Harris's words, "since we never permanently fail a message delivery, as long as the delivering MTA's are well behaved, we should never cause a legitimate mail to bounce." A real mail server waits and tries again. The mail arrives late. Spam software moves on to the next target.

How does greylisting work?

The server records three values for each delivery attempt and defers any combination it has not seen. Harris called the combination a triplet:

1. The IP address of the sending host
2. The envelope sender (MAIL FROM)
3. The envelope recipient (RCPT TO)

Harris placed the check "immediately after the RCPT command is received," so the deferral lands on the recipient step. A new triplet gets a temporary failure. A retry of the same triplet after the delay is accepted, and the triplet is remembered so later mail passes without waiting.

Timing matters at both ends. A retry that arrives too soon is deferred again: greylistd resets the clock, and the Exim wiki says plainly, "we don't accept it if it's tried again immediately." A retry that arrives too late starts over. Mimecast restarts the process after 12 hours, and OpenBSD spamd drops unretried entries after 4 hours.

Not every greylister treats all mail alike. Mimecast applies it to "all inbound messages from connections not previously seen." rspamd only delays messages whose spam score crosses its greylisting threshold.

Example: a greylisted delivery and its retry

The exchange below is illustrative. The rejection line, 451 4.7.1 Please try again later, is the reply shown in Harris's paper. The retry half is an example of a typical acceptance, not a captured log. Arrows follow Harris's notation: -> is the sending server, <- is the receiving server.

# Attempt 1, 09:00, from 192.0.2.10
-> MAIL FROM:<alice@example.org>
<- 250 2.1.0 Sender ok
-> RCPT TO:<bob@example.com>
<- 451 4.7.1 Please try again later
-> QUIT

# Attempt 2, 09:30, same sending IP, same sender, same recipient
-> MAIL FROM:<alice@example.org>
<- 250 2.1.0 Sender ok
-> RCPT TO:<bob@example.com>
<- 250 2.1.5 Recipient ok
-> DATA

Nothing about bob@example.com changed between 09:00 and 09:30. The triplet aged past the delay.

How long does greylisting last?

The delay is usually minutes. The memory of a passed sender lasts weeks. Each implementation picks its own numbers and its own reply text.

The long whitelist lifetimes are deliberate. The spamd manual sets 36 days "to allow for the delivery of monthly mailing list digests without greylist delays every time."

Why does a valid address return unknown?

Because the server deferred the triplet before it said anything about the mailbox. A verifier opens an SMTP session, sends MAIL FROM and RCPT TO, and reads the reply. On a greylisting server that reply is a 4xx, and the verifier has nothing else to go on.

The design explains why the reply carries no information. The triplet is built from three strings: an IP address, a sender and a recipient. Whether the recipient mailbox exists is not one of the inputs. As a consequence of that design, a real mailbox and a made-up one at the same domain receive the same first deferral.

The reply code does not help either. Greylisting has no standard reply, and each implementation chooses its own (see SMTP error codes for how the classes are defined). RFC 3463 calls class 4 a "Persistent Transient Failure." Harris used 4.7.1, although RFC 3463 describes X.7.1 as "useful only as a permanent error," so his choice is a convention outside the RFC's own wording. A 4xx can also have causes unrelated to greylisting, such as the ones covered under SMTP 421.

A single-probe verifier that never returns has, in effect, behaved like the fire-and-forget sender the filter was built to stop. unknown is the honest label for that outcome.

Why do retries matter, and how does a sender pass greylisting?

Retrying is the entire test. A sender passes by coming back with the same triplet inside the server's window.

RFC 5321 sets the expectations for well-behaved senders: "In general, the retry interval SHOULD be at least 30 minutes," and the give-up time "generally needs to be at least 4-5 days." That interval is longer than most of the delays in the table above. Mimecast's documentation notes that Exchange "retries to send a message every 10 minutes by default."

The retry must also come from a recognisable address. Postgrey matches by subnet by default, using a /24 for IPv4. rspamd masks IPv4 to /19 and IPv6 to /64. A retry from outside the matched range is a new triplet, and the delay starts again. Harris flagged the risk for large senders: when a pool of servers retries "from any one of several sending MTAs," legitimate deliveries "may take significantly longer than expected."

For a sender, the practical rules follow from those facts. Send through a real MTA with a queue. Keep retries inside one subnet. Do not retry instantly. A deferral that is retried correctly never becomes a bounce. One abandoned past the give-up time does (see hard bounce vs soft bounce).

What is the difference between greylisting and blacklisting?

A greylist defers unknown senders until they prove they retry. A blacklist refuses senders already judged bad. The OpenBSD spamd manual draws the line clearly. Greylisted hosts "are given a temporary failure message by spamd when they try to deliver mail" while spamd "has not yet decided if they are likely spammers." For blacklisted hosts, "Mail is rejected with either a 450 or 550 error message. A blacklisted host will not be allowed to talk to a real mail server."

The two are designed to run together. Harris presented greylisting as a complement to IP blacklists.

What does greylisting mean for verification accuracy claims?

It means some addresses cannot be classified on one probe, so any accuracy figure depends on how the vendor counted them. Verifier vendors acknowledge this in their own documentation. ZeroBounce names an "unknown/greylisted" result and lets you "reattempt the validation request after 30 minutes" with a greylist_processing parameter. NeverBounce's result codes attribute unknown results often to greylisting or security gateways and state that unknown "is not a negative result." Kickbox suggests "retrying your request after about 5 minutes," though its page does not name greylisting.

When you read a headline accuracy number, ask three questions. Were unknown results removed from the denominator? If the vendor retried, how long did it wait? Did the retry come from the same IP or subnet? A probe from a different range is a new triplet and meets the same deferral. A verifier that reports a confident valid or invalid on the first probe to a greylisting server is reporting something the server never said.

How Trueguard handles greylisting

Trueguard's realtime check runs one SMTP probe and returns at once. It does not wait out a greylisting delay, so an address behind one returns unknown. The same rule covers a case most verifiers do not describe. To test for catch-all, Trueguard also probes a bogus address at the domain. If the real address gets 250 but the bogus probe gets a 4xx, the result is unknown rather than safe, because the catch-all question went unanswered. A Mimecast server under load is a real example: it answered the second probe with "451 Internal resource temporarily unavailable." A 5xx 5.7.x policy refusal at RCPT also returns unknown rather than invalid. For Google- and Microsoft-hosted mailboxes, Trueguard can get a verdict from the provider without an SMTP probe (see catch-all domain).

Our advice for signup forms: treat unknown as not proven. Do not block on it. Let the confirmation email decide, since it is real mail sent by a server that retries, or re-check the address later. Try an address in the free email verifier, then read the email verification API docs. The free plan includes 100 email validations a month, with no card required. Get your free API key.