Submission and delivery
Queues, retries, and delivery status
Explain store-and-forward delivery, temporary deferrals, permanent failures, and delivery-status notifications.
8 minute lesson
SMTP is a store-and-forward protocol. A sending MTA can accept a message locally, place it in a queue, and try the next server later.
A 4xx reply or unreachable destination normally keeps the message queued with increasing delays. A 5xx reply normally ends delivery for that recipient.
If delivery ultimately fails after the original submission succeeded, the system sends a delivery-status message to the envelope return path. That notification itself uses an empty return path so another failure does not create an endless loop.
A queue record needs more than message bytes. It tracks accepted recipients, completed recipients, deferred recipients, the next attempt, and the last remote reply.
[email protected] delivered 250 2.0.0
[email protected] deferred 451 4.4.1, retry at 14:30
[email protected] failed 550 5.1.1Retries should spread out with backoff. A rapid loop makes a temporary incident worse and can trigger rate limits. The sender eventually reaches its queue lifetime, stops retrying, and creates a delivery-status notification for recipients still undelivered.
Do not generate a bounce to the visible From field. Delivery status follows the envelope reverse path. If that path is empty, as it is for another bounce, the failure is logged or discarded instead of generating a new message.
“Queued” is not “delivered.” A submission API returning success may mean only that the provider accepted the job. Expose later delivery events separately in application status.
Create a queue table for three recipients using one success, one temporary failure, and one permanent failure. Write the next action for each row.
Lesson completed