SMTP deferral and greylisting
A 'not now, try again' rejection. Real mail servers retry minutes later and get in; sloppy spam scripts never bother.
See it
What it is
SMTP has two kinds of no. A 4xx is a deferral: not now, come back later. Deferrals happen for throttling, a full mailbox, a busy server, or a policy the receiver wants you to prove you can survive. A 5xx is permanent for that transaction, which is not the same as 'the address is dead'. It covers dead mailboxes, but also policy blocks, authentication failures, content rejections, and reputation refusals, and only the first of those is a reason to stop mailing the person. The enhanced status code is where the difference lives: 5.1.x is about the recipient, 5.7.x is about policy or authentication.
Greylisting is the deliberate version. The receiver records the triplet of sending IP, envelope sender, and recipient, defers the first attempt, and accepts the same triplet on a retry a few minutes later. Real mail servers keep a queue and retry; the spam scripts of the 2000s did not, which is why the trick worked. RFC 6647 wrote it up. It is less common now on the big providers, but plenty of corporate and self-hosted servers still run it.
Gotcha: the cost is time, and time is the one thing a login code cannot spare. A greylist delay of 5 to 60 minutes turns a magic link into a support ticket. Second gotcha: never treat a deferral like a bounce. Suppressing a deferred address deletes a perfectly good subscriber, and large sending pools that retry from a different IP can restart the greylist clock instead of clearing it.
Ask AI for it
Implement deferral handling in my email sending service. Parse the SMTP reply code and the enhanced status code from every failure. Treat 4xx as retryable for the current message and 5xx as non-retryable for that transaction, then split 5xx by what it actually says: suppress the address only on confirmed permanent recipient failures (5.1.x, user unknown, domain not found), and route 5.7.x policy and authentication failures and content rejections to a sender remediation alert instead, since those are our problem and the recipient is fine. Retryable failures go to a queue with exponential backoff plus jitter (first retry at 5 minutes, then widening intervals, giving up after 48 hours). Never suppress an address on a 4xx. Log the deferral reason per recipient domain and expose a 'currently deferred' count separate from bounces and from suppressions.