Email security basics

What is greylisting in email?

By iBlockSpam Team How we check our guides Updated Oct 10, 2026 9 min read 4 sources

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.

On this page 9 sections

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, 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 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:

A message arrives from an unknown sender. The server builds a record from the connection. RFC 6647 recommends a "tuple" of the sending IP address, the envelope sender (MAIL FROM) and the first recipient (RCPT TO).
The server refuses it temporarily. It replies with a 4xx code and stores the tuple with a timestamp.
The sender's server queues the message and schedules a retry.
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."
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.
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 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: 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, with the 4 making it temporary. Our 451 4.7.1 and 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, 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). Those don't clear by waiting once.

A quick way to tell the difference:

Did it succeed on the next retry? That's typical greylisting.
Does the reply text mention greylisting, a delay or "try again later" with no reason? Probably greylisting.
Does it mention reputation, rate limits, authentication, PTR or TLS? That's a policy or reputation problem. Fix the cause.
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.

What should you do if your mail is being greylisted?

If you send mail and recipients see delays:

Confirm your server retries. Check that your mail server or sending app queues 4xx failures and retries for several days, as RFC 5321 expects. Apps and devices that send directly are the usual culprits; route them through a proper mail server or relay.
Send from stable addresses. Keep a consistent set of outbound IPs, each with reverse DNS that matches. Check yours with the PTR Lookup and see reverse DNS for mail servers.
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.
Authenticate. Pass SPF, DKIM and DMARC. Many filters apply greylisting only to unknown or suspicious senders. The deliverability test checks all three.
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 explains those layers.

Next steps

If a message is late, open its headers in the 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.

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

See how your domain measures up

Run a free Email Health Check: MX, SPF, DKIM, DMARC and transport security in one scan, with the raw records shown. No sign-up.

Keep reading