# What is greylisting in email?

URL: https://iblockspam.com/blog/what-is-greylisting
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Email security basics
Author: iBlockSpam Team

> How email greylisting works, why it stops some spam, why it delays legitimate mail, how it looks in bounces and logs (4xx codes like 451 4.7.1), and what to do.

## Short answer

Greylisting is a spam defense where a receiving server temporarily refuses mail from an unfamiliar sender with a 4xx SMTP code and accepts it when the sender retries later. Real mail servers queue and retry; much spam software doesn't. The cost is delay: legitimate first-time mail can arrive minutes or hours late, depending on the sender's retry schedule.

You send an important message, and it shows up an hour later with no error in sight. Or a bounce warns that delivery is "delayed" and the server "will retry". Greylisting is one of the usual reasons. It's an old, simple spam defense that trades a little delay for less junk, and knowing how it works tells you whether to wait, fix something, or ask the recipient for an exception.

## What is greylisting?

Greylisting is the practice of temporarily refusing mail from senders a server doesn't know yet. [RFC 6647](https://www.rfc-editor.org/rfc/rfc6647.html), the IETF document that describes it, defines it broadly as "any degradation of service for an unknown or suspect source, over a period of time (typically measured in minutes or a small number of hours)." In the narrow sense most people mean, it's "generation of an SMTP temporary failure reply code" for those sources.

The name sits between a blocklist (always refuse) and an allowlist (always accept). A greylisted sender isn't trusted or blocked. It's asked to come back later.

## How does greylisting work?

The trick relies on a basic SMTP rule. A 4xx reply means "temporary failure, try again," and [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1) says that for these replies "the SMTP client SHOULD try again." A real mail server keeps the message in its queue and retries. RFC 6647 explains that much spam software "does not perform retransmission attempts after receiving an SMTP temporary failure," because "in spamming, volume counts for far more than reliability."

A typical greylisting system works like this:

1. **A message arrives from an unknown sender.** The server builds a record from the connection. RFC 6647 [recommends](https://www.rfc-editor.org/rfc/rfc6647.html#section-5) a "tuple" of the sending IP address, the envelope sender (`MAIL FROM`) and the first recipient (`RCPT TO`).
2. **The server refuses it temporarily.** It replies with a 4xx code and stores the tuple with a timestamp.
3. **The sender's server queues the message** and schedules a retry.
4. **The sender retries.** If the retry arrives after the minimum wait and inside the allowed window, the tuple matches and the message is accepted. RFC 6647 says the default window "SHOULD be from one minute to 24 hours."
5. **The server remembers the sender.** After a successful retry, RFC 6647 recommends allowing "all further SMTP traffic from the IP address in that tuple." Later mail from that server goes straight through.
6. **Old records expire.** Entries for addresses that go quiet are deleted after a timeout, which RFC 6647 says should be "at least one week" by default.

If you've never looked at an SMTP session, [what is SMTP](https://iblockspam.com/blog/what-is-smtp) walks through `MAIL FROM`, `RCPT TO` and reply codes.

### Where in the SMTP session can greylisting happen?

RFC 6647 describes greylisting at several points in the conversation. Each uses more information than the last.

| Stage | What the server checks | Notes |
|---|---|---|
| Connection | Client IP address (or host name) | Replies 421 and closes, or 4xx to every command |
| HELO/EHLO | IP plus the name the client gave | 4xx to every following command |
| MAIL FROM | IP plus envelope sender | 4xx for the rest of the session |
| RCPT TO | Recipient plus IP, sender and/or other recipients | The most common approach |
| DATA | Envelope plus header fields or a digest of the content | Most expensive; RFC 6647 says it's not typical practice |

Many systems also apply greylisting selectively. RFC 6647 mentions greylisting only IPs on a DNS blocklist, or IPs whose reverse DNS names look like dynamic home connections. That reduces delay for everyone else.

## What are the pros and cons of greylisting?

| Pros | Cons |
|---|---|
| Cheap: the server rejects before receiving the message body | Delays legitimate first-time mail |
| Early: runs before content scanning | Senders that don't retry lose mail |
| Removes a large amount of simple bulk spam | Spammers that retry get through after one delay |
| Gives blocklists time to list a new spam source before the retry | Large senders with many IPs can be delayed repeatedly |
| Needs no content inspection | Needs a shared, maintained database across all MX hosts |

RFC 6647 sums up the benefit: spamware "generally does not retry and is therefore less likely to succeed." It also names a second effect: by the time a new spam source retries, "it will appear in a list of sources to be filtered."

The main cost is delay. RFC 6647 calls it "the most obvious detriment," and warns that "where timely delivery of email is essential, especially for financial, transactional, or security-related applications, the possible consequences of such systems need to be carefully considered." Sign-in codes and password reset links that arrive an hour late are effectively lost.

## How long does greylisting delay mail?

The receiver sets a minimum wait. The actual delay depends on when the sender retries.

RFC 5321 says the retry interval "SHOULD be at least 30 minutes," and RFC 6647 adds that "some popular MTAs do not retry failed delivery attempts for an hour or more." Some mail servers also back off further after each failure. So a first message from a new contact can easily arrive half an hour to an hour or more late.

Once a sender has passed, its later mail isn't delayed, until the record expires or the sender's IP changes.

## Why do big senders get greylisted again and again?

Large providers and email platforms send from pools of servers. RFC 6647 [describes the problem](https://www.rfc-editor.org/rfc/rfc6647.html#section-4.1): a site with "multiple outbound MTAs that share a common queue" may retry from a different machine, so "example.com sees a different source, and once again greylisting occurs on the same message."

The same thing happens on the receiving side. If a domain has two MX hosts that don't share a greylisting database, a retry that lands on the other host is greylisted again. RFC 6647 says all inbound servers for a domain "SHOULD share a common greylisting database."

RFC 6647 suggests two fixes for receivers:

- track a range of addresses such as a /24 instead of a single IP, so a retry from a neighboring server in the same pool still matches;
- keep an exception list, noting that "highly visible online entities such as email service providers that will be certain to retry" should be allowed to bypass the check.

Other senders that greylisting can trip up: systems that change the envelope sender on every attempt (for example, a unique bounce address per try), devices and apps that don't retry at all, and broken implementations that treat a 4xx as a permanent failure. RFC 6647 points out that the last case "can result in such things as inadvertent removal from mailing lists."

## How does greylisting show up in bounces and logs?

Greylisting replies are temporary failures, so the first thing you see is usually nothing at all. The message sits in the sender's queue. If retries keep failing, many servers send the sender a "delivery delayed" warning, and eventually a final bounce after the give-up time.

There's no single greylisting code. RFC 6647 says that under SMTP rules "the only two reasonable choices are 421 if the implementation wishes to terminate the connection immediately and 450 otherwise," but in practice you'll also see 451. Each server writes its own text, so treat these as examples of the shapes you may see:

- `450 4.2.0` or `450 4.7.1` with text such as "Greylisted, please try again later"
- `451 4.7.1` with "try again later" or a link to the receiver's help page
- `421` with "try again later, closing connection"

The enhanced code `4.7.1` means "Delivery not authorized, message refused" under [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html), with the 4 making it temporary. Our [451 4.7.1](https://iblockspam.com/smtp-errors/451-4-7-1) and [450](https://iblockspam.com/smtp-errors/450) pages explain each in more detail.

### Greylisting or something else?

RFC 6647 warns that "there is some confusion in the industry that conflates greylisting with an SMTP temporary failure for any reason." Not every 4xx is greylisting. Gmail's [list of SMTP errors](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes), for example, uses 421 and 451 replies when a sending IP has no valid reverse DNS, and 421 rate limiting when SPF or DKIM don't pass or when there's an unusual rate of unsolicited mail ([421 4.7.28](https://iblockspam.com/smtp-errors/421-4-7-28)). Those don't clear by waiting once.

A quick way to tell the difference:

1. **Did it succeed on the next retry?** That's typical greylisting.
2. **Does the reply text mention greylisting, a delay or "try again later" with no reason?** Probably greylisting.
3. **Does it mention reputation, rate limits, authentication, PTR or TLS?** That's a policy or reputation problem. Fix the cause.
4. **Does it keep failing for more than a day?** Treat it as a real problem, whatever the text says.

Look up any reply with the [SMTP error code lookup](https://iblockspam.com/tools/smtp-error-codes).

## What should you do if your mail is being greylisted?

If you send mail and recipients see delays:

1. **Confirm your server retries.** Check that your mail server or sending app queues 4xx failures and retries for several days, as [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) expects. Apps and devices that send directly are the usual culprits; route them through a proper mail server or relay.
2. **Send from stable addresses.** Keep a consistent set of outbound IPs, each with reverse DNS that matches. Check yours with the [PTR Lookup](https://iblockspam.com/tools/ptr-lookup) and see [reverse DNS for mail servers](https://iblockspam.com/blog/reverse-dns-ptr-records-for-mail-servers).
3. **Keep the envelope sender stable across retries.** If your platform encodes a unique ID in `MAIL FROM`, make sure it doesn't change between attempts of the same message.
4. **Authenticate.** Pass SPF, DKIM and DMARC. Many filters apply greylisting only to unknown or suspicious senders. The [deliverability test](https://iblockspam.com/tools/deliverability-test) checks all three.
5. **Ask for an exception.** For a partner whose server greylists you repeatedly, ask their admin to add your sending IPs or domain to the greylisting exception list.

## Should you use greylisting on your own mail server?

It can still help a self-hosted server, but follow RFC 6647's recommendations:

- share one database across every MX host;
- don't greylist authenticated users or your own submission service;
- exempt known large senders and anything time-critical (banks, sign-in codes, payment providers);
- consider greylisting only senders with poor or no reputation.

RFC 6647 also notes that its guidance is based on IPv4 experience and that the much larger IPv6 address space "might even negate any benefits." Hosted filtering services can combine reputation, authentication and content checks so they don't have to delay every unknown sender. [How spam filters work](https://iblockspam.com/blog/how-spam-filters-work) explains those layers.

## Next steps

- If a message is late, open its headers in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) and compare the timestamps on each `Received:` hop to find where it waited.
- If you send mail, confirm your servers retry 4xx failures and have matching reverse DNS.
- If you run a mail server, review your greylisting exceptions and make sure all MX hosts share one database.
- For how temporary and permanent failures differ for senders, read [hard bounce vs soft bounce](https://iblockspam.com/blog/hard-bounce-vs-soft-bounce).

## Frequently asked questions

### How long does greylisting delay an email?

It depends on the sender, not the receiver. The receiver only sets a minimum wait, often minutes. The message arrives at the sender's next retry after that, and RFC 5321 says retries should generally wait at least 30 minutes. RFC 6647 notes some popular mail servers don't retry for an hour or more, so delays of an hour are normal.

### Is greylisting still effective against spam?

Partly. RFC 6647 says it "surprisingly remains useful" because much spam software doesn't retry, but also that some spamware routes around it. It's a cheap, early filter that removes simple bulk spam, not a complete defense. It works well alongside reputation, authentication and content checks.

### Can greylisting cause emails to be lost?

Normally no, because a compliant sender keeps retrying for days. Mail can be lost when the sending system doesn't retry at all, treats a 4xx reply as permanent, or changes its envelope or IP address on every attempt so it never matches. Some web forms, apps and devices behave this way.

### What does 451 4.7.1 mean in a greylisting context?

451 is a temporary failure and 4.7.1 means delivery wasn't authorized under the receiver's policy. Together they say "not now, try later." Some greylisting implementations use it, often with text such as "greylisted" or "try again later". Your server should retry automatically; if it still fails after a day, look at reputation or authentication instead.

### How do I stop my mail from being greylisted?

You can't switch it off on someone else's server, but you can make it painless. Retry properly, send from stable IP addresses with matching reverse DNS, authenticate with SPF, DKIM and DMARC, and ask regular contacts to add your sending servers to their greylisting exceptions. Once you pass, most systems remember you.

## Sources

- [RFC 6647: Email Greylisting: An Applicability Statement for SMTP](https://www.rfc-editor.org/rfc/rfc6647.html)
- [RFC 5321: Simple Mail Transfer Protocol, sections 4.2.1 and 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html)
- [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html)
- [Google Workspace Admin Help: Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)

## Free tools for this guide

- [SMTP Error Code Lookup](https://iblockspam.com/tools/smtp-error-codes): Paste a bounce or type a code like 550 5.7.26: plain-English meaning, likely causes and fixes, with sources.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Reverse DNS (PTR) Lookup](https://iblockspam.com/tools/ptr-lookup): Check PTR records, forward-confirmed reverse DNS and generic-looking host names.
- [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test): Send one email and see its SPF, DKIM and DMARC results, reverse DNS, blocklists, TLS and spam verdict.

---

Source: iBlockSpam, https://iblockspam.com/blog/what-is-greylisting (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt