InboxRatio
Check your domain

Glossary term

Greylisting: rejected now, welcome later

What greylisting is

Greylisting is an anti-spam technique in which a receiving mail server temporarily rejects the first delivery attempt from an unfamiliar sender and accepts the message when it is retried. The receiver answers the initial attempt with a 4xx temporary failure — often something like 451 4.7.1 Greylisted, please try again later — and remembers who tried. When the same sender retries after a delay, the mail goes through, and the sender is typically remembered as known for some period afterward.

The bet underneath it is behavioral. A legitimate mail server implements the retry queue that SMTP has always required — RFC 5321 obligates senders to treat temporary failures as retryable — while a great deal of spam infrastructure historically fired one attempt per address and moved on. By demanding the one behavior spamware skipped, a receiver could shed a large share of junk without inspecting a single message body.

Greylisting is formally described in RFC 6647, which is notable for its tone: it documents the technique, its variants and its costs, and is candid that the benefit erodes as spammers learn to retry.

How greylisting differs from other soft bounces

From the sending side, a greylisting event is a soft bounce — same 4xx class, same retry obligation. The differences are in intent and resolution.

An ordinary deferral reports a condition: mailbox full, server busy, throttling in force. It resolves whenever the condition does, which may be minutes or never. A greylisting deferral reports nothing about conditions — the receiver could have accepted the message and chose not to. It resolves deterministically: wait out the window (commonly minutes), retry, delivered.

The tell in practice is the pattern. Greylisting produces a 4xx on first contact with a receiver, success on retry, and smooth delivery thereafter — while reputation throttling produces deferrals that scale with your volume and persist across retries. Bounce text helps too; many implementations say "greylisted" outright. When the text is vague, the first-contact-then-fine signature is usually enough to diagnose it.

How greylisting works

A greylisting receiver tracks a triplet for each incoming attempt:

  1. The sending server's IP address.
  2. The envelope sender (the return-path address).
  3. The envelope recipient.

An unseen triplet gets the temporary rejection and a timestamp. If the same triplet returns after the minimum delay, the message is accepted and the triplet is whitelisted — for days or weeks, depending on configuration — so subsequent mail flows without delay. Variants soften the matching (netblock instead of exact IP, sender domain instead of full address) to cope with providers that retry from a different server than the one that made the first attempt.

That retry-from-elsewhere behavior is the technique's classic operational snag. Large sending platforms rotate outbound IPs, so the retry may arrive from a new address, form a new triplet, and get greylisted again. RFC 6647 discusses exactly this, and it is one reason well-run greylisting implementations match on network ranges and one reason large receivers mostly prefer reputation systems: greylisting is a blunt instrument in a world of distributed senders.

Who uses it today: mainly smaller mail systems — corporate servers, universities, hosting providers, appliances — where it remains a cheap first-line filter. Gmail, Microsoft and Yahoo rely on reputation and content models instead, though they produce greylisting-like deferrals for unproven senders, which is why the two phenomena get conflated.

Greylisting and your deliverability

For a sender on competent infrastructure, greylisting is mostly invisible: your ESP's queue retries, the message lands, and the only trace is a delivery delayed by some minutes on first contact with that receiver. It costs you nothing measurable — with three caveats.

Delay-sensitive mail feels it. A password reset or one-time code that hits a greylisting receiver on first contact can arrive after the code expired or the user gave up. Transactional senders care about first-attempt latency in a way newsletter senders never notice, and it is a fair question to put to a transactional provider: how do their queues pace retries against greylisting receivers?

Homegrown senders fail it. Scripts that fire mail via a bare SMTP transaction with no queue — cron jobs, CRM plugins, IoT devices — treat the 451 as a failure and never retry. The mail is simply lost, and the sender concludes the receiver is broken. The receiver would say the opposite: the sender declined to behave like a mail server. If you send anything that matters through DIY infrastructure, retry handling is not optional.

And your identity consistency matters more than usual. Because triplets key on the envelope sender and IP, erratic infrastructure — rotating return-path domains, scattershot IPs — resets your greylisting clock repeatedly. Stable sending identity, consistent PTR and MX-facing configuration, and authenticated mail keep first-contact friction to a one-time cost per receiver.

Limitations and failure modes

The lost password reset. Where greylisting bites hardest in practice: a user requests a reset, the confirmation races a greylisting window, and the support ticket reads "your emails don't work." Nothing is broken — the message arrived minutes late or the sending script never retried. Diagnosis requires reading the SMTP log, not the dashboard.

No-retry senders. Notification scripts and legacy systems that treat any 4xx as fatal lose mail silently at every greylisting receiver, forever. The fix is architectural: route DIY mail through a real relay with a queue.

Retry-from-a-new-IP loops. Large pools can retry from addresses outside the receiver's matching range, re-triggering the grey period repeatedly. In stubborn cases delivery can take hours — mostly a receiver-configuration problem, but the sender experiences it as flaky delivery to one domain.

Misdiagnosing throttling as greylisting. A sender sees 4xx responses, concludes "greylisting, it'll clear," and ignores what is actually reputation-based throttling that scales with their volume. Greylisting clears on retry; throttling clears on behavior change. Confusing them wastes the early-warning value of the deferral.

Eroded effectiveness. RFC 6647 said it plainly: once spamware retries, the core trick stops discriminating. Modern spam operations retry. Receivers leaning on greylisting alone are running a 2004 defense against 2026 traffic, and senders should not interpret "we greylist" as "we filter well."

Related terms

Soft bounce, SMTP, sender reputation, email warm-up, MX record, PTR record, IP reputation, hard bounce.

Frequently asked questions

How long does greylisting delay an email? Typically minutes: the receiver's minimum wait plus however long the sending queue takes to retry. Poorly matched retries from rotating IPs can stretch it to hours in unlucky cases. After first contact, the sender is usually remembered and later mail flows immediately.

Is being greylisted a sign of bad reputation? No — classic greylisting fires on unfamiliarity, not on badness. Every new sender-recipient relationship at a greylisting receiver starts grey. Repeated deferrals that scale with volume are a different phenomenon (throttling) and that one is about reputation.

Do Gmail and Outlook greylist? Not in the classic triplet sense. The major providers run reputation and content filtering, though they emit temporary failures that behave similarly for new or suspect senders — especially during warm-up. Small and mid-size mail systems are where textbook greylisting lives.

Can I avoid greylisting entirely? You cannot opt out of a receiver's policy, but you can make it costless: send through infrastructure with proper retry queues, keep your sending IPs and return-path stable, and authenticate consistently. Some receivers also skip greylisting for senders with established reputation or matching forward-confirmed reverse DNS.

Why did only the first email to a new contact arrive late? That is greylisting working as designed: the first triplet paid the delay, the whitelist entry now covers the relationship, and subsequent messages skip the wait until the entry expires.

Does greylisting still stop spam? Less than it did. It still sheds low-effort blast traffic and buys time for blocklists to catch fresh sources, which is why small systems keep it as a cheap layer. Against retry-capable spam operations it filters little — the consensus RFC 6647 reached over a decade ago.

If mail to one particular domain keeps arriving late or vanishing, check the sending logs for 451-class responses before blaming the list or the content — and make sure whatever sends your transactional mail actually retries, because SMTP's patience is the whole entry fee.

Sources