Who this is for. Owners and administrators who rely on email to run the business and have never worked out what happens when it stops, or when it is damaged. It separates the four things people call “backup”, explains what actually happens to mail during an outage, and gives a short plan you can write down in an afternoon.
“We have Microsoft 365, so email is backed up” is one of the most common sentences in small-business IT, and it mixes up four different ideas. Email can fail in several distinct ways: the service goes down, a mailbox is deleted or encrypted or emptied, the domain stops pointing at your mail servers, or the account is taken over. A plan that covers one of these says nothing about the others. This guide takes them apart.
Four words that are not the same thing
| Idea | What it protects against | What it is | What it is not |
|---|---|---|---|
| Availability (continuity) | Service outage | The ability to send and receive while the main platform is unavailable | A copy of old mail |
| Retention | Accidental or malicious deletion within a window | Platform settings that keep deleted items for a period | A backup you control, or protection from an administrator or a deletion beyond the window |
| Archive / legal hold | Compliance and discovery | Preservation of messages for a defined purpose | A recovery tool for operational use |
| Backup | Loss, corruption or malicious destruction | An independent copy of mail data you can restore from, held separately from the primary service | Automatic, or tested, unless you have tested it |
Retention and legal hold are real features and genuinely useful, but they live in the same service and under the same administrative control as the mail itself. If an attacker takes over an administrator account, or the whole tenant is compromised, the thing that holds your mail and the thing that protects it are exposed together. That is the central argument for an independent copy.
What Microsoft 365 retention does by default
Exact behaviour depends on your plan and settings and changes over time, so check it for your tenant. As a rough guide, which you should confirm in Microsoft’s current documentation:
- Deleted items normally move to a recoverable area for a limited window. The default recoverable-items retention for Exchange Online is on the order of two weeks and can be raised, up to a documented maximum, by an administrator.
- A deleted mailbox, or a deleted user whose mailbox is removed, is generally recoverable for a limited number of days and then gone.
- Retention policies and litigation hold can preserve content for longer, but they are tools for preservation, designed around compliance, and they do not replace a restorable backup.
The practical question is this: if every message from the last three years vanished today, how would you get them back, from where, and how long would it take? If the answer is “I would have to check”, it is a gap to close.
What happens to mail when your server is unreachable
Email delivery is more forgiving than most services. A sending server that cannot reach your mail exchanger does not give up immediately; it queues the message and retries over a period. The SMTP specification recommends giving up only after several days (the guidance is on the order of four to five), though individual senders vary. In practice:
- A short outage of an hour or a day usually results in delay, not loss. Mail arrives when you come back.
- A long outage, or a sender with a short queue lifetime, can produce bounce messages to the sender.
- Whether senders are told “delayed” or “failed” is up to them, and customers may not wait.
Delay is not free. A payment confirmation, a password-reset message or a contract arriving a day late can be a problem, and an incident that coincides with an outage is hard to handle with no mail at all.
Secondary mail servers: be careful
An older approach is to publish a second MX record pointing at a backup server that holds mail until the primary returns. It still has uses, but it has traps:
- A backup MX that accepts any recipient and does not know your real mailboxes can become a path for spam and for backscatter.
- Attackers have long preferred the weaker, lower-priority MX because it is often less protected than the main one.
- A modern, large cloud mail service is already highly available; a naive backup server may be a less reliable component than the thing it backs up.
If you add one, make it a service that knows your valid recipients and applies the same filtering, and test failover deliberately.
DNS: the single point of failure that is easy to forget
Everything above depends on your DNS pointing mail where you expect. Whoever can change your DNS can redirect all your mail, and many organisations give less thought to protecting their registrar and DNS accounts than to their mailboxes.
- Put MFA on the registrar and the DNS provider accounts, with a recovery path you control.
- Turn on registrar lock features, and auto-renew the domain with a payment method that does not expire.
- Know who can change MX, SPF, DKIM and DMARC records, and keep a copy of the correct values outside DNS itself.
- Watch for changes. A monitoring tool or even a scheduled check of the current records against your saved copy will notice a record that was changed.
- Mind your TTLs. A very long TTL on MX records slows any planned change; a short one speeds it up but is not a defence against anything.
An expired domain stops all mail and invites hijacking. It is mundane and it happens.
Authentication and failover
If you use a backup relay or a different outbound path during an outage, the mail it sends still has to pass authentication. A message sent from an address your SPF record does not list will fail SPF, and if your DMARC policy is reject a sending path that does not sign with your domain’s DKIM will see its mail refused. Before you rely on any fallback sending method, confirm it is included in SPF and signs aligned DKIM. The reasoning is in SPF, DKIM and DMARC. Decide in advance whether the outage plan is “send from a different channel” or “send through the fallback”, and write it down.
Communication when email is the thing that is broken
An incident that takes email down also takes down the normal way you would tell people. Decide in advance:
- A channel for staff that does not depend on your mail platform, such as a chat service or a phone tree.
- A contact list stored somewhere that does not need your mail to open: a printed copy, or a file outside the platform.
- Who tells customers, and how: a status line on the website, a message on the main phone number, a post on a social account.
- Who decides that an outage is serious enough to trigger the plan.
A one-page continuity plan
You do not need a long document. You need answers written down and a copy outside the system.
EMAIL CONTINUITY: ONE PAGE
1. What would we lose in each failure?
- Service outage: delay in sending and receiving
- Mailbox deletion: mail from the last [retention window] recoverable; older mail?
- Tenant compromise: all of the above plus access to the backup if it is in the same tenant
- DNS / domain failure: all inbound mail
2. How do we recover, and how long do we expect it to take?
- Restore from [backup product], last test-restore on [date], took [time]
- DNS access: [who], MFA held by [who], recovery contact [who]
3. How do we talk while mail is down?
- Staff: [channel]
- Customers: [channel] spokesperson [who]
4. Who decides to invoke this plan? [name], deputy [name]
5. When did we last test it? [date]. Next test: [date]Fill in the blanks. The blank you cannot fill in is the finding.
People leave, and so does their mail
One of the most ordinary ways to lose mail is not an attack or an outage but an offboarding. When a person leaves and their licence is removed, their mailbox may be deleted after a grace period, and with it every message, contact and calendar entry that nobody copied. Decide per role what happens instead: convert the mailbox to a shared one and give a manager delegated access, keep it on hold for an agreed time, or export it. Whichever you choose, write the rule down, because the person who remembers it is rarely the one doing the offboarding two years later. Check how your own tenant treats a mailbox when a licence is removed instead of assuming it matches what a colleague remembers.
Offboarding is also when forwarding is most often set up “temporarily”. Give each such forward an end date, because a forward to a former employee’s personal address is a data leak with a good excuse.
Test the restore
A backup that has never been restored is a hypothesis. Pick one mailbox, restore a handful of messages, and note how long it took and what was missing. Do it before you need it, and put the date of the test in the plan. Backups also need protecting as carefully as the mail they hold: separate credentials, MFA, and administrators who are not the same people who administer the tenant if you can manage it.
How this fails
- “Retention” mistaken for backup. It lives in the same service and window as the mail.
- The backup is in the compromised tenant. An attacker who controls administration can reach it.
- Backups never tested. The first restore is during an incident, and it does not work.
- A forgotten domain renewal. The business is offline because of an expired card.
- A backup MX that accepts everything. It becomes a spam and backscatter relay.
- No out-of-band communication plan. The outage is announced by email.
- Fallback sending that fails DMARC. The messages you send during the outage are refused.
What to do next
Write the one-page plan this week, including the restore date you cannot yet fill in, then test one restore. Use the email security readiness assessment to see how continuity compares with your other controls, and read Microsoft 365 security for the settings, including auditing and retention, that decide how much you can recover.