Who is holding your mail

Almost every organization that moved its mail to a cloud tenant quietly stopped thinking about backing it up, and the reasoning was sound at the time. The old mail server was the fragile thing in the building. It had a single disk array, a tape rotation somebody had to remember, and a recovery procedure that had been tested once. Handing it to a provider running it at a scale nobody in the building could match was the right call.

What did not carry over is the distinction the old server made obvious and the new one hides. A provider promises the service will be there. That is a different promise from the data in it still being there, and the two get conflated because nothing on the invoice separates them.

What is the provider actually promising?¶

The provider is promising availability and durability of the platform, and it publishes the boundary rather than hiding it. Microsoft's shared responsibility matrix (opens in a new tab) puts customer data, configurations and settings, and identities and users in the customer's column for every deployment type it lists, software as a service included. Its own summary sentence is that "for all cloud deployment types, you own your data and identities", and the page lists data among the responsibilities you retain regardless of what you have bought.

That is not a disclaimer buried in an agreement. It is the vendor's architecture documentation, and it is the most useful thing to put in front of somebody who believes the platform is backing them up, because it is not our claim and it is not a competitor's claim. Microsoft's own note on that page is worth keeping in view. It describes the matrix as governance guidance rather than a statement of contractual terms, so it settles who is expected to do the work and not what anybody is legally owed.

The reason any provider draws the line there is structural rather than commercial, which is why shopping for one that does not is a waste of an afternoon. A provider cannot distinguish a deletion you regret from a deletion you intended, because the two arrive as identical instructions from an authenticated client. Replication faithfully copies both.

Why does replication not protect a deleted message?¶

Replication protects against the copy being lost, and a deletion is not a loss of the copy. It is an instruction, issued by an authenticated client, that the system is built to carry out everywhere. Five replicas of a mailbox means the deletion reaches five replicas, promptly and correctly, which is the system working.

This is why durability figures are the wrong number to reach for in this argument. A platform can be engineered so that losing a message to hardware failure is close to impossible, and that engineering does nothing at all about the three events that destroy mail in practice. Those events are worth naming, because each has a different answer.

• A compromised account tidying up after itself. An attacker with a session does not only read; they delete the notifications, the reply thread and the rule they created, and they do it with the account's own permissions, which means every action looks legitimate to the platform.
• A departed employee whose license was reclaimed. Removing the license is the cost-saving step somebody does in month one, and on several platforms it starts a clock on the mailbox that nobody in the room knows is running.
• A sync client doing its job during a ransomware event. Files encrypted on a laptop are files changed, and a folder-sync client replicates changes upward exactly as designed.

Where do the recovery windows actually end?¶

Recovery windows end at whatever the tenant's retention is configured to, which for most organizations is whatever the default was on the day the tenant was created. The platforms do provide real recovery paths, and they are worth knowing precisely. There is a deleted items folder, a recoverable items area behind it that users cannot see, a retention policy that can hold content beyond deletion, and a litigation or legal hold that changes the rules again.

The defaults are measured in days and weeks. The incidents that need them are discovered in months. A fraudulent invoice paid in March is noticed when the real supplier chases in July, and the thread that would show what happened was inside a window that closed in April. Nothing failed. The window was shorter than the question.

Two things make this worse than a plain configuration problem. Retention settings are edited by whoever is solving a storage complaint that week, usually without a record of the change or its reason, so the effective window is often not the one anybody would describe. And holds interact: a policy that looks like it retains everything can be scoped to a group somebody left, or to mailboxes that existed when it was written.

Is a third-party backup product the answer?¶

Sometimes, and it is worth being honest that a backup product is a real cost with real failure modes rather than an obvious yes. It is another vendor holding a full copy of the organization's correspondence, which is a new place to be breached and a new set of access decisions to get right. It bills per seat, forever. And a copy nobody has ever restored from has the same evidentiary value as no copy at all.

Consider a small organization whose mail carries no regulatory obligation and whose worst case is inconvenience. Configuring retention deliberately, recording what it was set to and why, and switching on the platform's own recovery features is a defensible answer there, and it costs nothing per seat. The decision turns on obligation and consequence rather than on size.

Buy the product when one of three things is true. Somebody outside the organization can compel production of correspondence, whether a regulator, an auditor, an insurer or a court. The mail contains the only record of a commercial commitment, which is true of more small firms than admit it. Or the recovery window a real investigation would need is longer than the window the tenant is configured for, and extending it in-platform is not available on the license you hold.

The four questions to settle now¶

Each of these has a specific answer, and the value is in discovering which ones nobody in the organization can give. A question that produces a pause is the finding.

1. 1.If a message is deleted today and nobody notices for nine months, is it recoverable, and from where? Name the mechanism rather than the vendor.
2. 2.When an employee leaves and their license is reclaimed, what happens to the mailbox, and after how long does that become irreversible?
3. 3.Who can change the retention configuration, and where is the record of the last time it changed and why?
4. 4.When was a restore last performed, by whom, and how long did it take from request to the message in somebody's hands?