How to recover deleted emails, files and mailboxes in Microsoft 365 (and the deadlines that apply)

The call comes in at ten to five. A folder is missing from a SharePoint library, or a departed staff member's mailbox has just been needed for a dispute, or somebody emptied Deleted Items and then realised what was in it. The first question is never how to recover it. The first question is when it was deleted, because Microsoft 365 recovery is a set of separate mechanisms with separate clocks, and the answer to what is possible depends almost entirely on where the deletion sits on those clocks.

This guide sets out each recovery path in the order to try it, with the deadlines that apply, and finishes on where recovery stops and something else is needed. Everything here is a native Microsoft 365 capability; none of it requires an add-on product.

The clocks, in one place

Before touching anything, work out which window applies. These are the defaults; holds and retention policies can extend some of them, and the details follow in each section.

• Email a user deleted: sits in Deleted Items until that folder is emptied, then in the Recoverable Items folder for 14 days by default, which an administrator can raise to a maximum of 30 days.
• A deleted user account: restorable for 30 days from the Microsoft 365 admin center, and restoring it restores the mailbox.
• A file or folder in SharePoint or OneDrive: 93 days in total from the moment it was deleted from its original location, spanning both recycle bins.
• A whole document library or OneDrive that needs rolling back: up to 30 days, using the restore-to-a-point-in-time capability.
• A deleted SharePoint site: retained for 93 days, after which the site, its content and its settings are permanently deleted.
• A deleted user's OneDrive: a default retention period of 30 days, configurable, after which it moves to the site collection recycle bin for 93 days and needs PowerShell to restore.

Recovering deleted email

Work through these in order. Each step reaches further back than the last and takes more effort.

Step 1: the Deleted Items folder

The obvious one, and it resolves more calls than anything else. If the user deleted the message normally and has not emptied the folder, it is still there and can be dragged back. Check that the folder is actually being viewed rather than a search result, and check the user is looking in the right mailbox if they have several open.

Step 2: recover items from the Recoverable Items folder

An item moves into the Recoverable Items folder, and specifically into its Deletions subfolder, when a user deletes an item from the Deleted Items folder, empties the Deleted Items folder, or permanently deletes an item with Shift and Delete. It stays there for 14 days by default.

Users can retrieve items themselves using the recover deleted items feature in Outlook or Outlook on the web, without an administrator. That is worth telling staff about once, because it turns a service desk ticket into a thirty-second self-service action. In Outlook on the web the option appears within the Deleted Items folder as a link to recover items recently removed from that folder.

Step 3: extend the window before you need it

Fourteen days is short. A staff member who deletes something on their last day before four weeks of leave is beyond recovery before they get back. The retention period can be raised to the Exchange Online maximum of 30 days per mailbox:

Or across every user mailbox in the organisation:

One related point: where a mailbox is on litigation hold, the deleted item retention limit is ignored and content is preserved regardless. That is a compliance mechanism rather than a recovery convenience, but it changes what is available in an investigation.

Recovering a mailbox after the account was deleted

This is the higher-stakes version, and the 30-day window is not negotiable once it has passed.

1. 1In the Microsoft 365 admin center, open Users and then Deleted users.
2. 2Select the user and choose to restore them. Restoring within 30 days of deletion restores the account and all associated data, and the mailbox is fully restored.
3. 3Follow the prompts to set a password. The restore sets a new one, so plan how it will be delivered securely.
4. 4Assign a licence afterwards if the account is going to be used, and make sure one is available before you start.
5. 5If the user is not listed, too much time has probably elapsed. That is the point at which the paths in the next section are the only ones left.

Two conflicts show up regularly and both are recoverable. A user name conflict occurs when the same user name was reused for a new account after the deletion, and is resolved either by renaming the active account or by giving the restored account a different primary address. A proxy address conflict occurs when a proxy address from the deleted account was assigned to another account; restoring removes the conflicting proxy addresses from the account being restored.

For the ordinary departure, the cleaner pattern is not to delete the mailbox at all. Convert the departing staff member's mailbox to a shared mailbox so the address stays answerable and the history stays intact, then reclaim the licence. That avoids the recovery question entirely and is covered in our guide to setting up a shared mailbox in Microsoft 365.

Recovering files from SharePoint and OneDrive

Files have a longer window than email and a two-stage structure that is frequently misunderstood as two separate 93-day periods. It is not; it is one.

The two recycle bins

Items deleted from a SharePoint site or a OneDrive go to the site recycle bin, the first stage, where a user can restore them. If they are deleted from there, or that recycle bin is emptied, they move to the site collection recycle bin, the second stage, where a site collection administrator can restore them. Items are retained for 93 days from the time they were deleted from their original location. The second stage holds them for the remainder of those 93 days; it does not restart the clock.

• Restore from the first stage from the site's own recycle bin, which any user with access can reach.
• The second-stage recycle bin is reached from the bottom of the recycle bin page and requires site collection administrator rights.
• The site collection recycle bin has a quota. If it is exceeded, it starts purging the oldest items, which means a very busy site can lose items before the 93 days are up.
• The recycle bin is not indexed, so search will not find content sitting in it, and an eDiscovery hold cannot reach content there either.

Restoring a previous version instead

Where the problem is an overwrite rather than a deletion, the recycle bins are the wrong tool. Version history on the file lets you restore an earlier version in place. This is the fix for the spreadsheet somebody saved over, and for the document a workflow or a sync client damaged. It depends on versioning being enabled with a sensible number of versions retained, which is worth confirming across libraries rather than assuming.

Rolling back a whole library or OneDrive

When the damage is wide rather than deep, restoring files one at a time is not viable. A document library or a OneDrive can be restored to a previous point in time within the last 30 days, from the library or OneDrive settings. This is the tool for a mass deletion, a bulk overwrite, or a sync client that has replicated damage across thousands of files.

• It affects the whole library or OneDrive, not a single file, so it undoes every change since the chosen point including changes people wanted to keep. Choose the timestamp deliberately.
• It reaches back 30 days, not 93. It is a separate and shorter clock to the recycle bin.
• It depends on version history, so a library configured to keep very few versions gives it less to work with and reduces how effective it is.

Recovering a deleted SharePoint site

Deleted sites are retained for 93 days. After that, the site and all its content and settings are permanently deleted, including lists, libraries, pages and any subsites. Restoring one is straightforward: open the deleted sites list in the SharePoint admin center with at least the SharePoint Administrator role, select the site, and restore it. The restore control only appears when a single site is selected.

Recovering a departed staff member's OneDrive

This one runs on its own sequence and it starts automatically the moment the user account is deleted from Microsoft Entra ID. Nothing else triggers it, not blocking sign-in and not removing the licence.

1. 1The account deletion synchronises to SharePoint and the OneDrive is marked for deletion. The default retention period is 30 days and can be changed in the SharePoint admin center, or with the Set-SPOTenant cmdlet and its orphaned personal sites retention period parameter.
2. 2By default the deleted user's manager is automatically given access to the OneDrive and receives an email telling them so, and telling them when it will be deleted. Where no manager is set, a secondary owner nominated in the SharePoint admin center receives it instead.
3. 3A reminder email goes to the manager or secondary owner seven days before the retention period expires.
4. 4After that, the OneDrive moves to the site collection recycle bin, where it is kept for 93 days. Shared content in it is no longer accessible during that period, and restoring it requires PowerShell rather than the admin centre interface.

Access delegation is worth confirming rather than assuming, because if it is disabled, or no manager and no secondary owner is set, nobody is given access and nobody is warned the OneDrive is about to be deleted. It is configured through the user profiles area of the SharePoint admin center's additional features, under the My Site cleanup settings, where both the delegation setting and the secondary owner account live.

Where recovery stops and backup starts

Everything above is deletion recovery. It is genuinely good, and it resolves the overwhelming majority of day-to-day incidents without anybody buying anything. It is not a backup, and the difference matters on exactly the days it is expensive.

• Every window has an end. At day 94 the recycle bins are empty and the site is gone. Nothing in the native tooling reaches past that.
• Ransomware that encrypts files in place creates new versions rather than deletions. Version history and the 30-day library rollback can undo it if it is found quickly; if the encryption predates the rollback window, they cannot.
• A deliberate deletion by someone with administrative access can empty the recycle bins as part of the same action.
• A restore of a whole library to a point in time is a blunt instrument. It cannot separate the damage from the legitimate work done since.
• Retention policies preserve content for compliance. They are not designed to return a working environment to a business quickly, and using them as though they were is where organisations discover the difference under pressure.

There is an Australian records angle here too. Employee records generally have to be kept for seven years, and the ATO expects most business records to be kept for five. Neither obligation is satisfied by a 93-day recycle bin, and a business that assumes Microsoft 365 is holding its history indefinitely is usually assuming it about records with a statutory life several times longer than any window in this guide.

The checks worth doing before the next incident

1. 1Confirm the deleted item retention period actually in force on mailboxes, and whether mailboxes created since the last bulk change inherited 14 days rather than 30.
2. 2Confirm that OneDrive access delegation is enabled and a secondary owner account is set, so a departing staff member's files land with a human rather than nowhere.
3. 3Confirm versioning settings on the libraries that hold the business's important content, since both version restore and the 30-day rollback depend on them.
4. 4Write down the offboarding sequence: convert to shared mailbox, transfer OneDrive content, then remove the licence, then delete the account, in that order and not the reverse.
5. 5Decide deliberately whether any mailboxes need a hold applied before deletion so they become inactive mailboxes, because that decision cannot be made retrospectively.
6. 6Test one recovery of each type on something unimportant. A recovery procedure nobody has run is a document, not a capability.