Microsoft does not back up your email: shared responsibility explained for SMBs

“Our email is in the cloud, so it is backed up.” We hear this at almost every audit. It is wrong. Microsoft guarantees that its platform stays available, not that your data stays recoverable whatever happens: that is the shared responsibility model. In practice, the Microsoft 365 recycle bin and retention cover small everyday mistakes, but not a deletion discovered too late, ransomware encrypting OneDrive or a hijacked admin account. For those, you need a backup that is independent of the tenant. Here is what Microsoft does, what it does not do, and the method we apply for SMBs in Morocco and elsewhere.

Shared responsibility in one table

The principle is the same as in an office building: the landlord maintains the structure, the lifts and the power, but what is in your cabinets remains your responsibility.

Area	Microsoft	Your company
Datacenters, power, hardware	Yes	No
Replication across datacenters	Yes	No
Service availability (SLA)	Yes	No
Mailbox content, files, conversations	No	Yes
Accounts, passwords, MFA, access rights	Tools provided	Configuration and follow-up
Deletions, mistakes, malicious insiders	No	Yes
Long-term retention for legal duties	Tools provided	Choice and configuration

Microsoft commits to the infrastructure: if a datacenter fails, your mailboxes stay reachable from another. That resilience is real and far better than a mail server in a cupboard. But replication copies mistakes too: a deleted or encrypted file is deleted or encrypted everywhere, instantly.

What Microsoft 365 actually keeps

Native mechanisms exist, but each has a limited lifetime and a precise scope.

Service	Native mechanism	Main limit
Exchange Online	Deleted Items, then Recoverable Items	30 days then 14 days by default, extendable to 30
OneDrive and SharePoint	Two-stage recycle bin, version history	93 days in total for the recycle bin; versions do not protect against deletion
Teams	Chats stored in Exchange, files in SharePoint	Depends on the two mechanisms above
Deleted account	Mailbox and OneDrive kept temporarily	30 days by default, then deleted
Retention and litigation hold	Compliance policies, depending on licence	Same tenant, same admins, awkward restores

These are default settings documented by Microsoft; some can be changed. Check your own tenant rather than assuming.

Six situations where the recycle bin is not enough

• Deletion discovered too late. An employee empties their mailbox or OneDrive before leaving. Nobody notices for months, until a customer asks about an old exchange. The recycle bin windows have long passed.
• A leaver. The licence is removed to save money, and the mailbox and OneDrive are deleted after 30 days. Contracts, quotes and customer history go with them.
• Ransomware. An encrypted laptop syncs encrypted files to OneDrive and SharePoint. Version history helps, provided it is enabled, covers every affected file and was not purged by the attacker. Restoring thousands of files one by one is not a plan.
• Compromised admin account. An attacker who gains admin access, for example through a phishing campaign, can delete mailboxes, empty recycle bins and change retention policies. Everything in the tenant is within reach.
• Admin error. A retention or deletion policy with the wrong scope applies tenant-wide. A clean-up script run against the wrong group does the rest.
• Retention duty or dispute. An inspection, a lawsuit or the requirements of Morocco’s data protection law 09-08 may require you to find a specific document, as of a specific date, long after it was deleted.

Retention, litigation hold, archiving: why they are not a backup

Business Premium and E3 plans give access to retention policies and litigation hold. They are good compliance tools: they prevent permanent deletion of certain content for a chosen period. But they fail the three tests of a backup.

1. Independence. They live in the same tenant, protected by the same credentials. A compromised admin can switch them off.
2. Simple restore. Finding retained content goes through compliance searches and exports, not a “restore this mailbox as it was on Tuesday”.
3. Off-site copy. No copy exists outside Microsoft. If you lose access to the tenant, you lose everything.

Retention complements a backup; it does not replace it.

What a real Microsoft 365 backup must cover

A third-party backup copies Exchange, OneDrive, SharePoint and Teams every day to storage independent of the tenant. To be useful, it must:

• cover every service, including shared mailboxes, SharePoint sites created by Teams and the OneDrive of former employees;
• store copies outside the tenant, on immutable object storage that neither a Microsoft admin nor an attacker can change during the lock period;
• allow granular restores: a message, an attachment, a file, a folder, a whole mailbox or a site, to a given date;
• keep data as long as your obligations require, regardless of active licences;
• be monitored: a failing job must raise an alert, not be discovered three months later.

We deploy Veeam Backup for Microsoft 365 with immutable object storage, often the same used for server backups. The principle is the 3-2-1 rule we detail in our article on immutable backup, and the Veeam settings that matter are covered in our Veeam best practices.

The method, step by step

1. Take stock of the tenant. Licences, number of mailboxes (shared ones included), SharePoint sites, Teams, disabled accounts whose data must be kept.
2. Check native settings. Recoverable Items duration, version history, whether retention policies are active, admin accounts and MFA.
3. Rank the data. Leadership mailboxes, shared addresses such as contact or accounting, contract libraries: what must be restored first.
4. Define the policy. Frequency (at least daily), retention period, storage location, immutability period.
5. Deploy and secure. Dedicated service account, least privilege, backup console protected by MFA and separate from Microsoft 365 accounts.
6. Test and document. Actually restore a message, a file and a site, record the result, and write down who can trigger a restore and how. The test belongs in your disaster recovery plan.

The mistakes we see most

1. Believing Microsoft’s replication is a backup: it replicates deletions and encryption too.
2. Backing up Exchange but forgetting OneDrive, SharePoint and Teams, where most files now live.
3. Removing a leaver’s licence before their data has been backed up or transferred.
4. Storing backups with the same credentials as the tenant, or on storage writable from the company network.
5. Never testing a restore: the first attempt happens on the day of the incident.
6. Leaving admin accounts without MFA, which makes every other protection fragile. Our MFA rollout guide explains how to fix it.

Checklist

• Every service covered: Exchange, shared mailboxes, OneDrive, SharePoint, Teams.
• At least daily backup, monitored, with an alert on failure.
• Storage outside the tenant, immutable, with separate credentials.
• Retention period aligned with your legal and contractual obligations.
• Leaver procedure: backup verified before any licence is removed.
• MFA on every Microsoft 365 admin account and on the backup console.
• Restore test performed, dated and documented.
• People authorised to request a restore identified.

How we do it

We start with a tenant audit: licences, retention settings, admin accounts, sensitive data. We then deploy Veeam Backup for Microsoft 365 to immutable storage, wire its alerts into our 24/7 monitoring and perform a first restore in front of you. Tests are then repeated periodically and recorded in the service report. It is all part of our managed Microsoft 365 cloud offer, alongside our work as a Microsoft partner. If you are leaving shared hosting, it is also the right moment to put backup in place from day one, as in our cPanel to Microsoft 365 migration guide. Our case studies show this kind of project in other companies.

Want to know what would happen if an account in your tenant were deleted tomorrow? The initial audit is free: contact us, we reply within 24 business hours.