# What happens to email when your mail server is down?

URL: https://iblockspam.com/blog/what-happens-to-email-when-server-is-down
Last updated: 2026-10-09
Published: 2026-10-09
Topic: Running email day to day
Author: iBlockSpam Team

> Senders retry when your mail server is down, but not forever. How SMTP retries work, 4xx vs 5xx errors, what senders see, and how outage spooling helps.

## Short answer

Usually it waits. When your server can't be reached, sending servers treat it as a temporary failure and keep the message in their queue. RFC 5321 says to retry at intervals of at least 30 minutes and to give up after at least 4-5 days. Many senders give up sooner, though: Exchange Online stops after 24 hours and bounces the message.

When your mail server goes offline, incoming email doesn't vanish. SMTP was designed for unreliable networks, so the sending server keeps each message and tries again later. The risk is in the details: how long each sender waits, and what kind of error your domain returns while it's down.

## What happens to a message when your server can't be reached?

Every message to your domain starts with a DNS lookup. The sending server looks up your MX records and tries each host in order. Per [RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1), "lower numbers are more preferred than higher ones." If you're unsure what your domain publishes, check it with the [MX Lookup](https://iblockspam.com/tools/mx-lookup) tool.

If none of those hosts answer, the sender doesn't give up. [RFC 5321, section 3.8](https://www.rfc-editor.org/rfc/rfc5321.html#section-3.8) treats connection failures as temporary: a client whose connection fails should act as if it had received a `451` reply. [Section 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) then says mail that can't be sent immediately must be queued and retried, so the message goes back into the sender's queue.

The same section sets out the retry strategy:

- "The sender MUST delay retrying a particular destination after one attempt has failed."
- "In general, the retry interval SHOULD be at least 30 minutes."
- "The give-up time generally needs to be at least 4-5 days."

So a sender that follows the RFC will keep trying for days. Your server comes back, the next retry succeeds, and the message arrives late but intact.

### Not every sender waits 4-5 days

"Generally needs to be" is guidance, not a rule. Each mail system picks its own give-up time. Microsoft documents that when Exchange Online gets temporary errors, it "repeatedly tries to deliver the message over 24 hours," and only then returns a [4.4.7 non-delivery report](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-550-4-4-7-in-exchange-online) to the sender.

That matters, because a large share of business mail comes from Microsoft 365. If your server is down for a day and a half, many of those senders will already have received a bounce. Other systems use different limits, and you can't control any of them.

## 4xx vs 5xx: why the error code decides everything

What your domain returns during an outage matters more than how long the outage lasts. SMTP replies come in classes. [RFC 5321, section 4.2.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1) describes a 4yz reply as one where "the error condition is temporary, and the action may be requested again." For a 5yz reply, the client "SHOULD NOT repeat the exact request."

Enhanced status codes from [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html) add detail to the same split. Class 4 is a "persistent transient failure"; class 5 is "not likely to be resolved by resending the message in the current form."

| What the sender gets | Class | What the sender does | Typical outage cause |
|---|---|---|---|
| No answer, connection refused or timed out | Treated as 4xx | Queues and retries | Server or network down |
| `421` service not available | 4xx | Queues and retries | Server shutting down or overloaded |
| `450` / `451` temporary failure | 4xx | Queues and retries | Mailbox store or directory temporarily unavailable |
| [`4.4.7`](https://iblockspam.com/smtp-errors/550-4-4-7) message expired | Final bounce after 4xx retries | Gives up, sends non-delivery report | Outage lasted longer than the sender's queue limit |
| `550` / `5.x.x` permanent failure | 5xx | Bounces immediately | Misconfiguration, such as unknown recipients or relay denied |

The dangerous case is the last row. A server that is completely off is, oddly, the safer failure: senders see no answer and retry. A server that is half up and answering with permanent errors, for example rejecting every recipient as unknown because its directory hasn't loaded, causes immediate bounces. No retry will ever happen for those messages.

The same thing happens after a botched migration. If your MX points to a host that no longer accepts mail for your domain, it may answer [`550 5.4.1 Relay Access Denied`](https://iblockspam.com/smtp-errors/550-5-4-1), and every message bounces at once. Our guide to [changing MX records without losing email](https://iblockspam.com/blog/change-mx-records-without-losing-email) covers how to avoid that.

## What do senders see while your server is down?

During the retry window, most senders see nothing at all. The message sits in their outbox's queue, not yours.

Some systems send a warning after a delay. [RFC 3464](https://www.rfc-editor.org/rfc/rfc3464.html#section-2.3.3) defines a delivery status notification with the action "delayed," meaning the reporting server has "so far been unable to deliver or relay the message, but it will continue to attempt to do so." Whether a sender gets one, and when, depends on their system.

When the sender finally gives up, they get a non-delivery report, often called a bounce. RFC 3464 calls this action "failed": the reporting server has abandoned delivery. The bounce usually contains:

- The recipient address that failed.
- The last reply code, for example `4.4.7` from Exchange Online.
- The name of the host it was trying to reach.

Google publishes the codes Gmail uses, including temporary ones such as [`421 4.7.0`](https://iblockspam.com/smtp-errors/421-4-7-0) "Connection expired, try reconnecting" and `451 4.3.0` "Email server has temporarily rejected this message" ([Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)). When a customer forwards you a bounce, the code tells you whether their server retried or gave up. If you don't recognize a code, look it up in our [SMTP error code reference](https://iblockspam.com/tools/smtp-error-codes).

## Does a backup MX help?

A secondary MX host with a higher preference number will accept mail when the primary is down, then pass it on later. That solves the queueing problem, but it can create a filtering problem. Any MX host you publish is public, and nothing stops a sender from connecting to the backup directly, even when the primary is up. If your backup accepts mail without the same spam and spoofing checks, it becomes a side door around your filter.

Our guide to [MX records](https://iblockspam.com/blog/what-is-an-mx-record) explains why a filtering service should usually be your only MX, rather than one of several.

## How outage spooling at a gateway helps

An MX-level filtering gateway sits between the internet and your mail server. Senders connect to the gateway, not to you. That changes what happens in an outage:

1. The sender connects to the gateway, which is up, and the message is accepted with a `250` reply. From the sender's point of view, delivery succeeded.
2. The gateway filters the message for spam, malware and spoofing.
3. The gateway tries to pass the clean message to your server. Your server is down, so the attempt fails.
4. Instead of bouncing, the gateway holds (spools) the message and retries.
5. When your server comes back, the queued messages are delivered.

This works because the gateway runs somewhere other than your server; an on-premise filter in the same building usually goes down with it ([hosted vs on-premise spam filters](https://iblockspam.com/blog/hosted-vs-on-premise-spam-filter) compares the two). The effect is that the sender's give-up time no longer matters. A sender that would bounce after 24 hours never needs to retry, because the gateway accepted the message on the first attempt. What counts now is how long the gateway will hold mail for you.

iBlockSpam holds mail for [up to 5 days](https://iblockspam.com/features/outage-spooling) when your mail server is unreachable, then delivers it when the server returns. You can see where spooling fits in the mail flow on [how it works](https://iblockspam.com/how-it-works).

### What spooling doesn't cover

Be clear about the limits:

- **Outages longer than the spool window.** Five days covers most incidents, including a long weekend. It doesn't cover a server that stays down for weeks. Plan for that separately.
- **DNS problems.** If your MX records are deleted or your domain expires, senders can't find the gateway in the first place. Spooling only helps when mail can reach it.
- **Permanent errors from your server.** If your server is up but rejects recipients with `5xx` codes, the gateway gets a permanent answer. Fix the configuration rather than relying on the queue.
- **Internal mail.** Messages between users on the same platform, for example inside one Microsoft 365 tenant, usually don't pass through an inbound gateway.

## What should you do during a mail server outage?

Work through this list when your mail server or hosting goes down:

1. **Confirm the scope.** Is it the server, the network, or DNS? Run the [Email Health Check](https://iblockspam.com/tools/email-health-check) to confirm your MX records still resolve.
2. **Avoid permanent errors.** If the server is partly up, make sure it returns temporary (`4xx`) errors, not `5xx`, while it recovers. Taking it fully offline is safer than letting it reject recipients.
3. **Don't change MX records in a panic.** Pointing MX at an untested host can turn a delay into immediate bounces. Changes also take time to spread, because resolvers cache the old records until the TTL expires.
4. **Tell key contacts.** If the outage may outlast a day, warn customers and suppliers that their messages could bounce, especially those on Microsoft 365.
5. **Watch for bounces after recovery.** Ask people to forward any non-delivery reports. Read the code: `4.4.7` means the sender gave up after retrying; a `5.x.x` code means a permanent rejection.
6. **Check headers on late mail.** Open a delayed message in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer). The `Received` timestamps show where the message waited and for how long.
7. **Review your design.** If one outage caused bounces, consider holding mail at the filtering layer so the next one doesn't.

## Next steps

- Look up your current MX records with the [MX Lookup](https://iblockspam.com/tools/mx-lookup) and note which host receives mail first.
- If you run a backup MX, check that it filters as strictly as your primary, or remove it.
- Decide how long your business can tolerate mail being unavailable, and compare that with the 24-hour limit some senders use.
- If you want mail held at the filtering layer during outages, see how iBlockSpam's [outage spooling](https://iblockspam.com/features/outage-spooling) works with [Microsoft 365](https://iblockspam.com/platforms/microsoft-365) and other platforms.

Browse more guides on [running email day to day](https://iblockspam.com/blog/topic/operations).

## Frequently asked questions

### Is email lost if my mail server is down?

Usually not, at least at first. Sending servers keep the message and retry. RFC 5321 suggests trying for at least 4-5 days, but each sender sets its own limit, and some give up after a day. Mail sent to you during a long outage can bounce back to the sender.

### How long do senders keep retrying?

RFC 5321 recommends a retry interval of at least 30 minutes and a give-up time of at least 4-5 days. Real systems vary. Microsoft documents that Exchange Online retries for 24 hours before it sends the sender a 4.4.7 'message expired' bounce.

### Will the sender know my server is down?

Not straight away. While a message is queued, the sender usually sees nothing. Some systems send a 'delivery delayed' notice after a few hours. If the sending server finally gives up, the sender gets a bounce message explaining that delivery failed.

### Does a backup MX record solve outages?

It can hold mail, but a backup MX that doesn't filter gives spammers a way around your spam filter. Holding mail at the filtering gateway itself gives you the same queueing without that bypass.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol, section 4.5.4.1 Sending Strategy](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1)
- [RFC 5321, section 4.2.1: Reply Code Severities and Theory](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1)
- [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html)
- [RFC 3464: An Extensible Message Format for Delivery Status Notifications, section 2.3.3](https://www.rfc-editor.org/rfc/rfc3464.html#section-2.3.3)
- [Microsoft Learn: Fix NDR error 550 4.4.7 in Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-550-4-4-7-in-exchange-online)
- [Google Workspace Admin Help: Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/what-happens-to-email-when-server-is-down (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt