Employee Offboarding Mailbox Archive: Day-of-Departure Runbook

The day an employee leaves is the day you find out whether your offboarding runbook actually works. License gets revoked too soon and the manager loses access to a customer thread mid-deal. License gets left in place and finance notices a month later. Mail gets deleted and a discovery request shows up two years later. This is the runbook for handling a departing employee's mailbox cleanly, defensibly, and quickly enough that HR can close the ticket the same day.

The decision tree before you touch anything#

Not every offboarding looks the same. Five departure types drive five different mailbox handling paths:

• Voluntary, friendly resignation, fully transitioned work — short retention, manager forwarding, standard archive
• Voluntary, but mid-project or with active customer relationships — extended manager access, customer notification handling
• Involuntary termination, no litigation indicator — same-day access cut, standard archive, longer manager access
• Involuntary termination, legal sensitivity — immediate litigation hold, no deletion, restricted access
• Death of an employee — bereavement protocols, family access requests handled by legal

The runbook below assumes a standard offboarding. Anything with a litigation flag gets handed to legal and the email migration compliance guide becomes your reference for hold mechanics.

The first hour: critical moves on day-of-departure#

Before lunchtime on the employee's last day, you complete a fixed sequence. Speed matters because each step depends on the previous one.

Step 1: Confirm the termination ticket#

The HR ticket triggers the runbook. It includes the user's UPN, the manager's UPN, the requested retention period, any litigation flags, and the access handoff list. Don't act on a Slack message or an email — wait for the system ticket.

Step 2: Disable sign-in, don't delete#

Disable the user's account in your identity provider. This logs the user out of every active session, blocks new sign-ins, and stops Outlook on their laptop from syncing. Do not delete the account. Do not remove from any groups yet.

Step 3: Revoke active sessions#

In Microsoft 365 Entra (Azure AD), trigger "Revoke sessions" on the user. In Google Workspace, use the suspend action which kills active OAuth tokens. Mobile devices stop syncing within a few minutes once the next sync attempt fails authentication.

Step 4: Set the auto-reply#

Configure an out-of-office message that gives senders the next step. A reasonable default reads: "This address is no longer monitored. For matters related to [team], please contact [manager email]. For everything else, please contact [helpdesk]." Set the autoresponder to internal and external both.

Step 5: Forwarding rule#

If your policy is to forward inbound mail to the manager for a defined window, set the forward rule now. Use server-side forwarding (configured on the mailbox), not a client-side Inbox rule, because client rules stop firing when the client is closed. Decide whether to keep a copy in the original mailbox (recommended) or forward only.

Step 6: Document the state#

Write a one-line note in the ticket recording the time of each of the above steps and the configuration you applied. Future-you, or a compliance auditor, needs this record.

The first day: mailbox conversion and access#

With sign-in disabled, you can take your time with the next phase. This is the conversion of the mailbox into a long-term archive state.

Convert to shared mailbox (Microsoft 365)#

Microsoft 365 shared mailboxes don't require a license as long as the mailbox is under 50 GB. The conversion happens in the Exchange admin center or via PowerShell. After conversion, the license can be reclaimed. The manager — or a small group — gets delegated Full Access and Send As permissions, scoped to the time window specified in the ticket.

For mailboxes over 50 GB, you have two choices: split the mailbox by exporting the archive portion to PST first, then convert, or assign a license long-term and treat the mailbox as inactive but licensed. Most organizations choose the PST export path for cost reasons.

Suspend the user (Google Workspace)#

Workspace user suspension keeps the mailbox accessible without consuming a license slot from the organization's billing — though depending on edition, Workspace charges for suspended users in some plans. Check your edition. Delegated access to the suspended mailbox is granted through the Vault, or through email delegation if the policy permits.

For deep retention — inactive mailboxes#

Microsoft 365 inactive mailboxes are the long-term archive path when you have an Exchange Online Plan 2 or Microsoft 365 E5 license and want to preserve mail without ongoing storage spend. The mailbox is preserved indefinitely once placed on litigation hold or covered by a retention policy, and the license can be reclaimed. The mail is searchable through eDiscovery but not accessible to the manager unless explicitly exported.

The preserve ex-employee mailbox guide covers the full mechanics of inactive mailboxes, including the conditions under which you can later reactivate one.

Choosing the archive format#

If your policy is to extract the mailbox to a file format and store it outside the mail system, the format choice matters because you'll live with it for years.

PST: the Microsoft 365 native#

Pros: Outlook opens it natively. Compliance Search in Microsoft 365 can produce PSTs as an eDiscovery output. Most archive systems can ingest PST.

Cons: PST is a Windows-centric format with painful corruption modes if the file is interrupted. Single files often hit 50 GB and become unwieldy. Tools to read PST on Linux or macOS exist but are second-class.

MBOX: the Google Workspace native#

Pros: Plaintext format, one file per folder, well-understood by every Unix mail tool. Google's Takeout produces MBOX. Easy to grep and search at the command line.

Cons: Folder hierarchies don't always survive cleanly. Attachments are MIME-encoded inline and can produce huge single files for power users. Outlook doesn't open MBOX natively.

EML: maximum portability#

Pros: One file per message, RFC-compliant. Every mail client opens an EML file. Easy to ingest into archive systems that work file-by-file.

Cons: A 50 GB mailbox produces hundreds of thousands of small files, which most filesystems struggle with. Folder structure must be represented by directory layout, which varies by exporter.

The PST, MBOX, EML migration guide covers conversion paths between these formats in detail. For offboarding specifically, the rule is: match the format to the source provider, then standardize on a single archive format across the org if you can.

Who keeps access — and for how long#

Access management is where most offboarding runbooks quietly leak. Managers get access "temporarily" and still have it three years later. Customer-facing inboxes get shared with the entire team and the audit trail vanishes.

The default access window#

Thirty days of full delegated access for the direct manager is the standard starting point. For roles with longer customer engagement cycles — enterprise sales, account management, professional services — extend to 90 days with explicit re-approval at day 30. For executives, expect HR or legal to specify.

After the active access window, the mailbox moves to archived state. Read-only access requires a ticket and a justification, logged and reviewed by compliance.

Documenting access grants#

Every grant of delegated access needs a record: who got access, when, why, for how long, and who approved. Microsoft 365 mailbox audit logging captures the access events but not the business reason. Build the access record in your ticketing system as the system of record, with the technical implementation referenced from there.

Revoking access automatically#

The standard pattern is a scheduled job that runs daily, finds access grants past their expiry, and revokes them. Without automation, expired grants linger indefinitely. The job is fifty lines of PowerShell or Google Apps Script, and pays for itself the first time you survive an audit.

Retention periods that match your policy#

Retention is a policy question disguised as a technical question. The technical answer is whatever your policy says, applied consistently. Common patterns:

• General staff: 12 months from termination, then delete
• Sales, customer-facing: 36 months
• Finance, accounting: 7 years (driven by tax record requirements in most jurisdictions)
• HR: 7 years (driven by employment law statute of limitations)
• Legal, executive, regulated functions: Indefinite, with review every 5 years
• Anyone subject to litigation hold: Indefinite until the hold is released

If you operate in the EU or handle EU data subject mail, GDPR adds constraints on indefinite retention. The GDPR email migration guide covers the specific obligations for ex-employee data, including the rules on data minimization and storage limitation.

Tagging mailboxes with their retention class#

The practical pattern: put each ex-employee mailbox into a retention bucket on day one of offboarding. Microsoft 365 retention policies and Google Workspace Vault retention rules can do this at the org level. Tag once, let the policy enforce, and don't rely on humans to remember.

Legal holds: when normal retention rules don't apply#

A legal hold suspends your normal retention. The moment any of the following happens, you stop deleting and start preserving:

• Notification from legal counsel of pending or anticipated litigation
• Receipt of a subpoena, civil investigative demand, or regulatory request
• Internal investigation triggered by an HR complaint
• Government inquiry or audit notification

Implementation in Microsoft 365: place the user on litigation hold or in-place hold. The mailbox can be inactive but the hold preserves all content indefinitely. In Google Workspace, set a Vault hold scoped to the user. Both options preserve content even if the user's account is later deleted.

Holds are not your decision. They come from legal. Your job is to apply them within the SLA they specify (often 24 hours from notification) and to never delete held content without written release.

Beyond the mailbox: the rest of the offboarding#

A complete offboarding archive covers more than mail. The runbook needs sections for:

• OneDrive / Drive content: Transfer ownership to the manager, or archive to a team folder. Default Microsoft 365 behavior gives the manager 30 days of read access before content is purged.
• Teams chats: Personal chat history follows the user. Channel messages remain in the team. Apply Teams retention policies separately from mailbox retention.
• SharePoint sites: If the user was a site owner, reassign ownership to the manager or a service account.
• Mobile devices: Wipe corporate data via MDM. Personal phones with corporate accounts get a selective wipe; corporate-issued phones get a full wipe.
• Third-party SaaS: Every app the user accessed through SSO needs deprovisioning. Some apps need a data export first.
• Licenses: Reclaim Microsoft 365, Workspace, Adobe, Zoom, and any other per-seat licenses. This is where the cost savings of a clean offboarding actually land.

A complete day-of-departure timeline#

A reference timeline for a standard offboarding, assuming a 5pm departure on Friday:

• 5:00 PM Friday: HR ticket created, account disabled, sessions revoked, auto-reply set, forwarding configured.
• 5:30 PM Friday: Mobile devices wiped via MDM. SSO sessions terminated.
• Monday morning: Mailbox converted to shared, license reclaimed, delegated access granted to manager.
• Monday afternoon: OneDrive ownership transferred to manager, SharePoint sites reassigned, Teams retention applied.
• Day 7: First check-in with manager — anything that requires extension?
• Day 30: Forwarding rule disabled, auto-reply updated to redirect-only message.
• Day 90: Manager access revoked (or extended if business case approved).
• Day 365 (or per retention class): Mailbox moved to inactive state, archive exported if policy requires.
• End of retention period: Mailbox deleted after final review confirms no holds in place.

The complete email migration guide covers the broader patterns for any mail movement; the offboarding runbook here is the specific application of those patterns to a single departing user.

Testing the runbook before you need it#

The offboarding runbook is the kind of process that gets exercised in stressful conditions — terminations are rarely planned. Test it quarterly with a fake departure on a test account. Walk every step. Time each phase. Identify which steps require manual intervention that could be automated. Build the automation. Test again next quarter.

The organizations that survive an audit of their offboarding process are the ones who can show a tested runbook, evidence of consistent execution against it, and a clear retention policy applied uniformly. The tool you use to extract the mailbox is the easy part — the discipline of running the runbook the same way every time is the hard part.