A first-time sender gets a temporary rejection from a server it has never talked to before, and the message is delayed by minutes. That is greylisting, and it is the single most misdiagnosed response in transactional email.
What the server is doing
It records the triplet of sender IP, envelope sender and recipient, answers with a 4xx at RCPT or DATA, and waits. A real mail server retries after a delay; a spam bot usually does not. When the retry arrives after the configured window, typically a few minutes, the triplet is on the allow list and the message goes through.
Why the first message to a domain is special
Greylisting hits new triplets, so your very first message to a new recipient domain is the one that gets delayed. The second is fine. That means a signup confirmation to a never-contacted domain can arrive minutes late through no fault of yours, and the fix is to retry rather than to re-send a new message with a new id — the new id is a new triplet, and it gets greylisted again.
What to do
Treat 4xx as retryable with an interval longer than the typical greylist window, keep the same message id and the same envelope sender, and cap total attempts. Do not reset the message, do not switch provider mid-flight, and do not mark the address as invalid.
The detail that matters
Log the triplet and the retry timing. When a customer says their verification email took eight minutes, 'greylisted at the recipient, delivered on attempt two' is a complete and correct answer.
Volanea retries with a stable message id and surfaces the remote 4xx text, so a greylisting delay is visible instead of mysterious.
Top comments (0)