What is store-and-forward reliability?

Store-and-forward reliability is why email still gets through even when receiving servers are temporarily offline. If the destination server isn't available (server restart, network issue, scheduled maintenance), the sending server doesn't just give up. It holds the message in a queue and tries again later.

This is different from instant messaging apps, where the message either delivers immediately or fails. Email servers retry for days (usually 72 hours) before giving up. That's why you might send an email at 3 PM, and it arrives at 3:02 PM because the recipient's server was down for two minutes. You never knew there was a problem.

Here's what actually happens: Your email reaches your ESP's sending server. That server tries to connect to the recipient's mail server (using SMTP). If the connection fails or the server rejects the message with a temporary error code (like "4xx" responses), your ESP's server stores the message locally and schedules retry attempts. It'll try again in 5 minutes, then 15 minutes, then an hour, gradually spacing out attempts over the next few days. If the recipient's server comes back online during that window, the message delivers. If not, it bounces back to you as a permanent failure after the retry period expires.

For senders, this means you don't need to monitor every single outage at every recipient domain. The infrastructure handles it. But there's a catch: if the delay is long (like 12+ hours), the recipient might think your email is late or outdated by the time it arrives. That's especially awkward for time-sensitive emails like flash sales or event reminders.

The retry schedule varies by ESP. Postmark retries for 48 hours. AWS SES retries for up to 14 days if you configure extended retry policies. Most marketing ESPs default to 72 hours. You usually can't control the retry schedule directly (it's infrastructure-level), but knowing it exists helps you understand why some messages show up late.

Store-and-forward is also why you might see emails delayed during high-traffic events like Black Friday. Receiving servers get overwhelmed, start issuing temporary rejections ("try again later"), and your messages sit in the queue until the server clears its backlog. The email still delivers, just slower than usual.

One thing store-and-forward doesn't save you from: permanent failures. If the recipient's server says "this mailbox doesn't exist" or "rejected for policy reasons" (5xx error codes), your ESP won't retry. The message bounces immediately. Store-and-forward only kicks in for temporary issues.