What this RFC defines
RFC 6647 formalises email greylisting, an anti-spam technique where an MTA temporarily rejects mail from unknown senders with a 4xx (temporary failure) code. Legitimate mail servers retry the delivery after a short delay, as required by RFC 5321. Botnet spam software typically does not retry, so the spam never arrives.
Where you see it in practice
If your first email to a new recipient bounces with a 421 or 451 response and then succeeds when your MTA retries 5-15 minutes later, you have encountered a greylisting filter. The log entry “450 Greylisted, please try again later” is a greylisting rejection. RFC 6647 also covers whitelisting policies that exempt known-good senders from the greylist delay, which is why established senders with good reputation often bypass it entirely.
How it connects to other RFCs
RFC 6647 is an applicability statement that sits on top of RFC 5321 (which defines SMTP’s retry requirements) and works alongside reputation and authentication systems (SPF/DKIM/DMARC). It does not introduce new protocol mechanisms; it documents how the existing 4xx temporary reject mechanism of RFC 5321 is used for filtering purposes.
Current status
RFC 6647 is a current informational standard, published March 2012. Greylisting remains widely deployed as a low-cost spam filter, though its effectiveness has declined as botnet software has added retry logic. Senders with established IP reputation and DKIM/DMARC authentication typically bypass greylisting.
Greylisting explained
RFC 6647 is the applicability statement for SMTP greylisting, published in June 2012. Greylisting is a spam mitigation technique: when a receiving MTA sees a new triple (sender IP, envelope sender, envelope recipient) for the first time, it rejects with a 4xx temporary failure. Legitimate MTAs retry after a few minutes; most spam bots do not retry at all or retry from different IPs. On the second attempt, the MTA accepts the message. The recipient sees a delivery delay of typically 5-15 minutes for first-time senders and no delay thereafter.
Effectiveness and side effects
Greylisting was highly effective against 2010-era spam but has declined in usefulness. Modern spam infrastructure implements retry logic, so simple triple-based greylisting catches fewer spammers than it used to. The main side effect is delay for legitimate first-time correspondents: users signing up for a service and receiving a confirmation email may see it arrive 10-15 minutes later than expected. This delay makes greylisting unpopular for transactional email and consumer-facing services.
When greylisting still helps
Greylisting remains useful in low-traffic personal mail servers or specialized environments where a few minutes of delay is acceptable. It is essentially free (only cache storage for triples), catches some remaining low-effort spam, and provides layered defense alongside SPF/DKIM/DMARC and reputation-based filtering. RFC 6647 explicitly notes that greylisting is not a standalone spam defense; it should be one input in a larger filtering strategy. Bulk email senders often see rejections from greylisting servers on first send and should implement retry logic accordingly.
RFC 6647 (June 2012) documents greylisting: a widely-deployed anti-spam technique where SMTP servers temporarily reject unknown sender/recipient/IP triplets with 4xx (typically 421 or 450), forcing legitimate senders to retry per RFC 5321 retry rules. Spammers typically do not retry (fire-and-forget); legitimate MTAs do (retry queues). After the second connection attempt, the triplet is whitelisted for a period (typically 30 days). Effective against botnets and script kiddie spam; ineffective against modern professional spam that retries. Best used as one input in a layered defense.
RFC 6647 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Document greylisting as an anti-spam mechanism |
| Type | Informational (documenting existing practice, not defining new protocol) |
| Mechanism | Temporary 4xx reject of unknown triplets; whitelist on retry |
| Triplet definition | {sender IP or /24, MAIL FROM, RCPT TO} |
| Typical delay | 5-15 minutes retry window |
| Whitelist duration | 30 days typical |
| Published | June 2012 |
Greylisting mechanism
Triplet definition and matching
Common greylisting mistakes
Related standards and further reading
- RFC 5321 SMTP Guide: retry rules foundation
Frequently asked questions
Is greylisting still effective in 2026?
Less than at deployment peak (mid-2000s to mid-2010s). Modern professional spammers implement retry queues; greylisting catches only unsophisticated bots. However, it remains useful as one input in layered defense: forces spammers to implement more infrastructure, filters out truly cheap sends, and provides small volume savings on downstream filtering. Trade against the cost: 5-15 minute delivery delay on first contact from every legitimate sender.
Should I enable greylisting on my mail server?
Depends on your priorities. If prompt delivery matters (transactional mail, customer-facing communication), the delay cost may outweigh the benefit. If you prioritize spam reduction over first-message latency, enable it. Consider whitelisting transactional senders, well-known ESPs, and any sender whose delay would harm users. Test on staging before production deployment.
What is the typical retry window?
5-15 minutes is standard. Shorter windows (under 5 minutes) risk false positives (some MTAs retry aggressively but not that fast); longer windows (over 30 minutes) accumulate user-facing delivery delays. RFC 6647 documents common practice; individual deployments tune based on their sender population.
How long should the whitelist persist?
30 days is common; RFC 6647 discusses various trade-offs. Shorter whitelists (7 days) re-greylist regular senders too often; longer whitelists (90 days) may keep entries for senders that have moved to new IPs. 30 days balances re-verification against user-facing delays.
Does greylisting break SPF and DKIM verification?
No, they operate at different layers. Greylisting acts at the SMTP transaction layer (accept or 4xx reject); SPF and DKIM verify identity and integrity after acceptance. A greylisted-then-accepted message is still SPF/DKIM/DMARC verified normally. In fact, sender authentication combined with greylisting is a good combination: greylist unauthenticated senders, whitelist authenticated ones.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
