SMTP Errors and Retry Strategy
Interpret SMTP 4xx and 5xx responses, enhanced status codes, and retry behavior for transactional email.
TL;DR
Treat SMTP 4xx responses as temporary and 5xx responses as permanent unless provider documentation says otherwise. Retry temporary failures with backoff, never retry permanent failures blindly, and use webhooks for final post-acceptance delivery state.
What you will learn
- Distinguish transient SMTP failures from permanent failures
- Understand enhanced status codes
- Avoid duplicate transactional email during retries
Basic SMTP response classes
| Class | Meaning | Retry behavior |
|---|---|---|
| 2xx | Accepted or successful command | Continue |
| 4xx | Temporary failure | Retry with backoff |
| 5xx | Permanent failure | Do not retry without a change |
The first digit is the most important operational signal. Enhanced status codes add detail, such as 4.2.2 for mailbox full or 5.1.1 for a bad address.
Common temporary failures
Temporary responses usually mean the sender should try again later:
421service not available.450mailbox unavailable.451local processing error.452insufficient storage.4.7.xthrottling, reputation, or policy deferral.
Use exponential backoff with jitter. Avoid retry storms. A good pattern is retrying after seconds, then minutes, then longer intervals, with a maximum retry window appropriate to the message type.
Common permanent failures
Permanent responses usually mean a retry will not help:
550mailbox unavailable or policy rejection.551user not local.552exceeded storage allocation.553mailbox name not allowed.554transaction failed.
Permanent recipient failures should feed the suppression list. Re-sending to a known bad address hurts reputation and creates noisy analytics.
App retry rules
When submitting to Postscale by SMTP:
- Retry network timeouts cautiously.
- Retry 4xx SMTP responses with backoff.
- Do not retry 5xx responses unless you corrected the cause.
- Do not generate a new password reset token for every retry.
- Keep a message idempotency key or application event id.
When sending by REST, apply the same principle: retry transport errors and 5xx API errors carefully, but fix validation errors instead of retrying them.
Accepted is not delivered
SMTP acceptance means the provider took responsibility for the message. It does not mean Gmail, Outlook, Yahoo, or another mailbox accepted the message.
Your application should store states such as:
queuedaccepteddelivereddeferredbouncedcomplained
Use webhook retries and idempotency to update final state reliably.
Troubleshooting checklist
- Confirm the From domain is verified.
- Confirm the SMTP port and TLS mode match.
- Check whether the recipient is suppressed.
- Inspect the enhanced status code.
- Compare failures by mailbox provider.
- Look for a recent template or list-quality change.
- Review SPF, DKIM, and DMARC alignment.
References
Frequently asked questions
- Should I retry SMTP 421?
- Yes. 421 is generally a temporary service-unavailable response. Retry with backoff unless your provider gives a more specific instruction.
- Does SMTP accepted mean delivered?
- No. Accepted means the provider accepted responsibility for delivery. Use delivery, bounce, defer, and complaint webhooks for final state.
Related guides
Put the guide into production
Postscale brings sending, inbound processing, DMARC reporting, and masked addresses behind one API so the operational pieces stay connected.