# What Is Greylisting in Email? RFC 6647 451 Deferrals & Impact on Email Verification > Understand how anti-spam greylisting works via temporary 451 4.7.1 SMTP deferrals, how triplets are tracked, and how email verifiers classify temporary deferrals. - **Author**: Vespera, Product & Content Lead - **Published**: 2026-09-14 - **Source**: https://mailveri.com/blog/greylisting-explained - **AI Reference**: https://mailveri.com/llms-full.txt --- Greylisting is an elegant, protocol-level anti-spam defense deployed across thousands of corporate and custom mail transfer agents. Standardized under RFC 6647, it exploits a fundamental difference in behavior: legitimate mail servers queue and retry deferred deliveries, whereas automated spam scripts move on immediately. However, for real-time email verification engines, greylisting introduces distinct technical challenges. ## How RFC 6647 Greylisting Tracks the SMTP Triplet When an unfamiliar inbound connection initiates an SMTP session, a greylisting server tracks an identification **Triplet**: 1. **Client IP Address:** The connecting server's IP (e.g., `198.51.100.24`). 2. **Envelope Sender:** The `MAIL FROM:` address. 3. **Envelope Recipient:** The `RCPT TO:` address. If the receiving server has never seen this exact triplet before, it temporarily refuses the transaction with a 4xx transient failure code, typically `451 4.7.1 Greylisting in action, please come back later` or `450 4.2.0 Recipient address deferred`. Because RFC 5321 requires compliant mail transfer agents (MTAs) to retain deferred messages in local spool queues and reattempt delivery after a delay (typically 5 to 15 minutes), legitimate emails arrive normally. Once the sender retries from the same IP, the receiving server recognizes the triplet, delivers the message to the inbox, and whitelists that triplet for subsequent deliveries (typically cached for 30 to 90 days). In contrast, high-volume spam engines and botnets send millions of unspooled messages simultaneously and rarely maintain stateful retry queues, eliminating over 90% of automated spam before it ever reaches content filters. ## Why Greylisting Causes False Invalids in Naive Email Verifiers While greylisting effectively suppresses inbound spam, it complicates email verification. A verification tool does not actually send an email; it connects to the target MX, issues `RCPT TO` to test mailbox existence, and terminates the session with `RSET/QUIT`. When a greylisting server returns a `451` or `450` code, a naive verification tool cannot distinguish whether the recipient exists. Low-tier verifiers frequently make one of two catastrophic mistakes: - **False Invalids:** Marking greylisted corporate mailboxes as “Invalid”, which discards legitimate enterprise sales leads. - **Aggressive IP Switching:** Switching sending IPs immediately on 4xx recipient blocks, which creates a new triplet and resets the greylisting delay timer on the destination server. A production-grade verification architecture treats greylisting with strict protocol discipline. In real-time stateless verification (such as point-of-capture web forms), unresolvable 4xx recipient deferrals must resolve to a safe, non-billable `UNKNOWN` status rather than guessing. For background batch scrubbing, the engine schedules intelligent delayed retries to allow the greylisting cooling-off window to expire, successfully validating deliverability without triggering spam alarms. For outbound marketing and transactional senders, configure your sending MTA spooler with an aggressive initial retry window (between 300 and 600 seconds) rather than a multi-hour backoff. This ensures that the second delivery attempt arrives promptly once the remote greylist timer expires, minimizing inbox delivery delays for genuine subscribers. ## How Greylisting Affects Verification & Why MailVeri Never Charges for Unknowns | SMTP Response | Meaning | MailVeri Status | Credits Deducted | | --- | --- | --- | --- | | `250 2.1.5 OK` | Mailbox confirmed active | `VALID` | 1 credit$0.0002 – $0.00059 | | `550 5.1.1 Mailbox not found` | Mailbox confirmed non-existent | `INVALID` | 1 credit$0.0002 – $0.00059 | | `451 4.7.1 Greylisted, try again` | Temporary RFC 6647 deferral | `UNKNOWN` | **0 credits (100% Free)** | ```http C: RCPT TO: S: 451 4.7.1 Greylisting in action, please come back in 00:05:00 C: QUIT S: 221 2.0.0 Bye ``` Read more in our deep dive on [Unknown Email Status Explained](https://mailveri.com/blog/understanding-unknown-email-status), or start verifying lists at up to 90% lower cost on our [Pricing page](https://mailveri.com/pricing). ## Frequently Asked Questions ### What is email greylisting and why does it return a 451 code? Greylisting (RFC 6647) temporarily rejects mail from an unfamiliar sender-recipient-IP triplet with a 451 4.7.1 deferral to block hit-and-run spam bots that never retry, while legitimate mail servers automatically retry delivery a few minutes later. ### How does MailVeri handle greylisted mail servers during verification? Instead of falsely marking a temporarily deferred address as INVALID, MailVeri classifies unresolved 4xx deferrals safely as UNKNOWN and charges 0 credits, protecting valid B2B prospects from accidental deletion. ### How much does bulk email verification cost on MailVeri? MailVeri uses 100% pay-as-you-go Universal Credits that never expire: $9 for 10,000, $59 for 100,000, $299 for 1,000,000, and $999 for 5,000,000 checks ($0.0002/email), with 1,000 free credits on signup and 0 credits billed for UNKNOWN results.