The Short Answer
In most cases the email is delayed, not lost. When a mail provider cannot accept a message, it answers with a temporary error and the sending server keeps the message in a queue and tries again. The message is lost only if the outage outlasts the sender's retry period. In the Microsoft 365 outage that began on November 12, 2026, sending services reported that queued mail was not lost, but that messages with short expiry times did bounce.
How Email Retries Work
The email standard, RFC 5321, tells sending servers what to do when delivery fails temporarily.
- Wait, then retry: the sender "MUST delay retrying" and the interval "SHOULD be at least 30 minutes".
- Keep trying for days: "the give-up time generally needs to be at least 4-5 days".
- Temporary versus permanent: error codes starting with 4 mean try again. Codes starting with 5 are permanent failures.
During the November 2026 outage, senders saw Microsoft return a temporary error, "421 4.3.2", meaning too many concurrent connections. That is a "try again later" answer.
How Long Senders Actually Keep Trying
Real services give up sooner than the standard suggests, and they differ.
| Sending service | Retry period | Source |
|---|---|---|
| Twilio SendGrid | 72 hours from the first deferral | SendGrid documentation |
| Exchange Online, as a sender | 24 hours by default, then a non-delivery report | Microsoft documentation |
| Amazon SES | "An extended period of time". The exact window is not published | AWS documentation |
| Mailchimp | Not stated. A down server counts as a soft bounce | Mailchimp help |
| Gmail and Google Workspace | No official figure found | Not applicable |
If a message has its own short expiry, such as a one-time passcode or a flash-sale email set to expire in a few hours, it can bounce well before these limits.
What Microsoft Did in November 2026
On November 13, Microsoft said it was "extending the email timeout window to 48 hours to help protect delayed messages while service recovery continues". Microsoft did not say exactly which messages this covers. Exchange Online's own queues normally expire messages after one day, so the most likely reading is that mail already inside Microsoft's systems got twice as long before bouncing. That is our inference. The extension did not protect mail still waiting on an outside sender's servers, which followed that sender's own retry period. By 14:01 UTC on November 13, Microsoft reported email queues significantly reduced.
If You Sent a Personal or Work Email
- Do not resend straight away. If your first message is queued, a resend arrives as a duplicate.
- Watch for a bounce notice. No notice usually means the message is still queued or was delivered late.
- For anything urgent, use another channel and say that an email is on its way.
If You Send Marketing or Transactional Email
During the outage
- Leave the queue alone. SparkPost told customers during this outage: "please don't send these messages again. Resending creates duplicates once the queued mail goes through."
- Hold non-urgent campaigns to the affected provider if your platform lets you segment by mailbox domain. A large share of business addresses are on Microsoft 365.
- Send time-critical messages another way. Passcodes and receipts with short expiry are the ones that bounce.
After the outage
- Resend only what expired. SparkPost's advice after recovery was to resend time-sensitive messages that had expired, not everything.
- Do not suppress addresses that bounced in the window. They are valid addresses that were unreachable for a day.
- Mark the dates in your reporting. Open and click rates for campaigns sent just before or during the outage will look worse for reasons that have nothing to do with the email.
- Expect a burst. When queues drain, recipients get a day of email at once, and yours competes with all of it.
Does a Deferral Hurt Sender Reputation?
A temporary deferral is not a bounce. Amazon SES states that "only hard bounces count toward your bounce rate". Deliverability writer Al Iverson puts it this way: "A 4xx inherently means: try again." The risk appears only when a deferral expires and your platform records it as a bounce, or when you resend heavily into a provider that is still struggling.
Soft Bounce and Hard Bounce
| Term | Meaning | Example |
|---|---|---|
| Deferral | A temporary refusal. The sender will retry | The provider is overloaded |
| Soft bounce | A temporary delivery failure | Mailbox full, or the recipient's server is down |
| Hard bounce | A permanent failure. The sender should stop | The address does not exist |
Mailchimp lists "recipient email server is down or offline" as a soft bounce, and allows 7 soft bounces for an address with no activity, or up to 15 for one with past activity, before treating it as a hard bounce.
For the Outage Itself
See the Microsoft 365 outage timeline for what failed and when, and the incident ID entry for how to follow Microsoft's updates.
Sources
RFC 5321, section 4.5.4.1; SendGrid on deferrals; Amazon SES on bounces; Mailchimp on soft and hard bounces; Microsoft on queued messages; SparkPost's incident notice; Spam Resource on deferrals. Microsoft's wording is from its admin centre updates for incident EX1550543.