# Greylisting: How It Works and What Senders Should Do

URL: https://email-validation.org/guides/greylisting/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

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](https://www.rfc-editor.org/info/rfc6647/)
(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

| Setting | RFC 6647, section 5 |
|---|---|
| Window in which a retry counts | Configurable; the default should be from 1 minute to 24 hours |
| Retry after the window closes | Treated as a new message: the first-seen time resets |
| How long a known IP stays known | Records with no recent traffic expire; the default should be at least one week |
| Grouping of sending IPs | A server may track whole blocks, such as a /24, instead of single IPv4 addresses |
| Several inbound MX servers | They should share one greylisting database and policy |
| Authenticated submission | Should not be greylisted |

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:

```text
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](https://email-validation.org/bounce-codes/451-4-7-1/). Some
deferrals look similar but have other causes, and waiting alone does not fix them:

- [450 4.2.1](https://email-validation.org/bounce-codes/450-4-2-1/): at Gmail, one mailbox is receiving mail faster than it allows.
- [421 4.7.0](https://email-validation.org/bounce-codes/421-4-7-0/): a policy deferral, for example missing reverse DNS or low reputation.
- [421 4.7.28](https://email-validation.org/bounce-codes/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](https://www.rfc-editor.org/info/rfc5321/), 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](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf)
(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](https://email-validation.org/bounce-codes/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](https://email-validation.org/guides/bounce-processing-dsn/).

## 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](https://email-validation.org/guides/bounce-processing-dsn/#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](https://email-validation.org/guides/shared-vs-dedicated-ip/).
- 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](https://email-validation.org/guides/verify-email-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`](https://email-validation.org/docs/statuses/unknown/#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](https://email-validation.org/docs/guides/signup-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](https://email-validation.org/guides/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](https://email-validation.org/email-checker/); if the result is `unknown` with the reason
`greylisted`, check it again later.

## Related

- [The unknown status: greylisted](https://email-validation.org/docs/statuses/unknown/#greylisted) and the other reasons for `unknown`.
- [Glossary: greylisting](https://email-validation.org/glossary/#greylisting) and [soft bounce](https://email-validation.org/glossary/#soft-bounce).
- [Bounce code 451 4.7.1](https://email-validation.org/bounce-codes/451-4-7-1/) and the [bounce code dictionary](https://email-validation.org/bounce-codes/).

## Related guides

- [Bounce processing and DSNs explained](https://email-validation.org/guides/bounce-processing-dsn/)
- [Verify an email address without sending a message](https://email-validation.org/guides/verify-email-without-sending/)
- [Reduce your email bounce rate](https://email-validation.org/guides/reduce-email-bounce-rate/)
- [Shared vs dedicated sending IPs](https://email-validation.org/guides/shared-vs-dedicated-ip/)
- [Catch-all emails explained](https://email-validation.org/guides/catch-all-emails/)
- [All guides](https://email-validation.org/guides/)

## Sources

- [RFC Editor: RFC 6647, Email Greylisting: An Applicability Statement for SMTP](https://www.rfc-editor.org/info/rfc6647/):
  definition, greylisting points, the triplet, timing defaults, unintended consequences, verification.
- [RFC Editor: RFC 5321, Simple Mail Transfer Protocol](https://www.rfc-editor.org/info/rfc5321/): 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](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf):
  section 3.8 on handling temporary failures.

## Get up to 500 free credits. No card needed.

New accounts get 500 free credits (100 when you sign up with a free email provider such as Gmail, Outlook or Yahoo, or another personal mailbox such as a paid one like Fastmail or one from your internet provider). Try it on your own list before you buy. [Create your account](https://email-validation.org/signin/?new=1) or [open the free email checker](https://email-validation.org/email-checker/).