KoltrixGreylisting and 4xx deferrals: why your retries matter
Greylisting temporarily rejects unknown senders and expects a retry. How it works, what deferrals look like in logs and the retry behavior receivers expect.
On this page(7 sections)
Some mail servers deliberately refuse your first delivery attempt and wait to see whether you come back. If you do, the message goes through.
If you do not, you were probably a spam cannon, and the receiver just saved itself the work of filtering you.
What greylisting is
Greylisting is a simple anti-spam technique that exploits a difference between real mail servers and many spam tools. A standards-compliant SMTP sender treats a temporary failure as "try again later" and queues the message for retry. Much bulk spam software, historically, fired once and moved on.
A greylisting receiver tracks a triplet for each delivery attempt:
- The connecting IP address (or its network).
- The envelope sender (
MAIL FROM). - The envelope recipient (
RCPT TO).
The first time it sees a new triplet, it returns a temporary failure, typically a 451 or 450 reply. It records the triplet and a timestamp. When the same triplet returns after a minimum delay, often somewhere from a minute to several minutes depending on configuration, the receiver accepts the message and usually remembers the sender for future mail, so later deliveries go through immediately.
What a greylisting deferral looks like
In your outbound logs, you will see replies like these:
451 4.7.1 Greylisting in action, please come back later
450 4.2.0 <[email protected]>: Recipient address rejected: Greylisted, see http://...
451 4.7.1 Try again laterThe leading 4 is the key. Under RFC 5321, a reply code beginning with 4 is a transient negative completion: the command failed, but the sender is expected to retry. The enhanced status code (RFC 3463) after it, such as 4.7.1 or 4.2.0, gives more detail but keeps the same class.
The wording varies by software and configuration. Some receivers say "greylisted" explicitly; many give only a generic "try again later." From the sender's side, you usually cannot tell greylisting apart from other temporary conditions, and you do not need to. The correct response is the same.
Greylisting is one kind of deferral among many
Temporary failures come from many causes:
| Cause | Typical reply | What it means |
|---|---|---|
| Greylisting | 450/451 4.7.1 or 4.2.0 | New sender, come back later |
| Rate limiting | 421 or 451 4.7.x | You are sending too fast |
| Reputation throttling | 421 4.7.0 | Receiver is unsure about you; slows you down |
| Mailbox over quota | 452 4.2.2 | Recipient's mailbox is full |
| Receiver resource limits | 421 4.3.2 or 451 4.3.0 | Server busy or temporarily unable |
| DNS or lookup trouble | 451 4.4.x | A lookup failed on their side |
All of them ask the same thing of you: keep the message, wait, and try again with sensible backoff. Some deferrals, particularly reputation throttling at large mailbox providers, also tell you to slow down overall, not just for that one message.
What receivers expect from your retries
RFC 5321 gives guidance on retry behavior. It suggests the retry interval should generally be at least 30 minutes, and that a sender should keep trying for at least four to five days before giving up and generating a bounce. Those numbers come from an era of slower networks and are guidance rather than hard rules, but they establish the spirit: retrying is normal and expected, and giving up after an hour is not.
For greylisting specifically, a sender that retries too quickly, before the receiver's minimum delay, simply gets deferred again. A sender that retries from a different IP each time may never satisfy the triplet, because the receiver sees a new triplet on every attempt. That is a real problem for large sending pools.
The sending pool problem
If your outbound mail rotates across many IP addresses, a retry might come from a different IP than the first attempt. Many greylisting implementations mitigate this by tracking the sending network (for example, a /24 for IPv4) rather than the exact address, or by whitelisting senders that pass SPF. But not all do. Good outbound infrastructure tries to retry a deferred message from the same IP, or at least the same small group of IPs, for the same destination.
Envelope sender variability
Some systems generate a unique envelope sender per message for bounce tracking, such as [email protected] (VERP). That is fine for greylisting because the triplet is per message, but it means every new message to a greylisting receiver may be deferred once, since the sender address is always new. Implementations that normalize such addresses avoid this; many do not. The practical effect is a short delay on the first attempt of each message, not a delivery failure.
Reading deferrals in your metrics
Deferrals are a normal part of email. A small, steady deferral rate is healthy. Watch for these patterns instead:
- A sudden rise in deferrals at one large provider. Usually reputation or rate related. Slow down and check complaint rates and authentication.
- Deferrals that never resolve. If the same message is deferred for days, look at the reply text; the receiver may be blocking you while using a 4xx code.
- Deferrals concentrated on one sending IP. That IP may have a reputation problem or a missing or mismatched PTR record.
- Delivery latency complaints from users. Verification emails and magic links are time-sensitive; even one greylisting delay of several minutes can be noticeable.
Practical steps for senders
- Always retry 4xx responses. Never convert a temporary failure into a bounce on the first attempt.
- Use backoff, starting reasonably soon. A first retry within a few minutes helps clear greylisting quickly; later retries spread out.
- Retry from a consistent IP per destination where your infrastructure allows.
- Keep retrying for days, not minutes, for mail where late delivery is still useful, and set shorter windows for messages that expire, such as one-time codes.
- Make sure every sending IP has valid forward-confirmed reverse DNS and passes SPF; some greylisting setups skip known-good senders.
- Track deferrals by destination domain and reply text, not just as one aggregate number.
Key takeaways
- Greylisting temporarily rejects unknown sender-recipient-IP combinations and accepts them on a later retry.
- Any 4xx reply means "retry later"; treat greylisting like other temporary failures.
- RFC 5321 expects senders to keep retrying for days, with intervals that are not too aggressive.
- Rotating sending IPs can defeat greylisting retries; keep retries consistent per destination.
- Monitor deferrals by destination and reason so real reputation problems stand out from normal background.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
