Notebookcheck first highlighted the issue in reporting published September 16. Its central finding holds up against Google and Microsoft’s own documentation, but the sharper conclusion is not that either vendor recommends private-account recovery through work mail. They do not. Rather, both vendors provide—and in Google’s case specifically document—a way to preserve delivery to an ex-employee’s address for business reasons. If that address remains registered as recovery information elsewhere, the organization that now receives the mail may receive password-reset links and security codes intended for its former employee.
For Windows and Microsoft 365 administrators, this is an offboarding problem with two owners and no automatic handoff. IT can remove corporate access perfectly while an employee’s personal recovery settings still point at a mailbox, alias, or forwarder the company controls. The former employee, meanwhile, may believe the address disappeared on their final day when it has actually become a live route into a manager’s or successor’s inbox.
Google’s alias guidance keeps delivery alive
Google’s Workspace administrator documentation says that when an employee has left and their account has been deleted, the administrator can add the prior address as an email alias for a current user to forward messages sent to the former employee. Google defines an alias as an alternate address whose messages are automatically routed to the primary inbox of the assigned user.
That is a deliberate, supported business-continuity feature. It is commonly used so suppliers, customers, and automated systems that still address [email][email protected][/email] do not lose contact with the company. It is also not a temporary bounce message: an alias remains active until an administrator removes it or changes the configuration.
One detail in Notebookcheck’s account needs careful reading. Google’s 20-day period is principally the window after deletion during which the old Workspace address can be restored or reassigned; it is not a 20-day expiry for mail once the address has been reassigned as an alias. Google says reassignment can take up to 24 hours. Once the alias is attached to a current user, messages sent to the former address follow that user’s mailbox rules until the alias is removed.
Google’s documentation also tells administrators to reduce the company’s risk when an employee departs by revoking sessions and security keys and removing the employee’s recovery phone number and recovery email from the managed account. That advice protects the organization against a former employee regaining entry to corporate services. It does not and cannot inventory private accounts where the employee listed the work address as a recovery method.
The resulting blind spot is simple: the former employee may no longer be able to use the corporate account, while the company can still receive messages addressed to it.
Microsoft 365 makes the retention choice more explicit
Microsoft’s current Microsoft 365 offboarding guidance similarly tells administrators they can keep a departed worker’s address active by forwarding mail to another employee or converting the mailbox to a shared mailbox. The stated purpose is the same: preserving messages from customers or partners who continue to use the prior address.
The implementation matters. Microsoft’s documentation says that deleting the former employee’s account stops new email to that account from being received. It also warns administrators not to delete an account that has forwarding configured or has been converted to a shared mailbox, because those functions depend on the account or mailbox object remaining in place. A shared mailbox can generally operate without its own license, while a mailbox using direct forwarding may retain licensing requirements.
This is where many offboarding checklists turn a retention timer into false reassurance. Microsoft 365 does retain a deleted user’s mailbox data for a limited recovery period by default, but that clock describes deletion and recoverability. It does not impose an expiry date on a mailbox the organization deliberately keeps active as a shared mailbox or on an address that remains assigned and able to receive mail.
Administrators should therefore distinguish among three very different states:
- A deleted Microsoft 365 user no longer receives new mail at that address, although mailbox data can remain recoverable for the platform’s retention period.
- A shared mailbox can continue accepting new messages and can be opened by every user granted access.
- A forwarded mailbox can continue delivering new mail to a successor while the underlying mailbox remains active.
The exact recipient configuration—not the date on which a worker left—determines whether an old address is still a usable delivery channel.
The recovery risk is real, but it is service-specific
An inbox is not a universal master key. Modern services vary widely in how they handle forgotten-password requests, device recognition, authenticator apps, passkeys, recovery codes, telephone verification, and fraud checks. A service that requires a second factor a former employer cannot access may stop a reset attempt even if the employer receives the initial email.
But email remains a high-value recovery factor because it is often the only one an account holder configured years earlier. Netflix, for example, documents password-reset options involving email and phone-based verification. Microsoft accounts also use configured security information to verify identity. If an old work address is the only viable recovery destination for a personal account, its continued operation can produce either an account-lockout problem for the former employee or an opportunity for whoever now controls the inbox to initiate recovery.
The distinction is important. There is no public record establishing that Google Workspace aliasing or normal Microsoft 365 offboarding has produced a documented wave of private-account takeovers. That claim would go beyond the evidence. What is established is the technical precondition: vendors document ways to continue delivery to a former employee’s named address, and recovery flows at many online services rely partly or entirely on email.
A separate 2025 investigation by Truffle Security researcher Dylan Ayrey shows why identity tied solely to an email address can age badly. Ayrey acquired a lapsed startup domain, recreated former employee addresses, and reported access to third-party accounts that accepted those Google identities. Ars Technica independently reported Google’s response: it pointed developers toward Google’s immutable sub OpenID Connect identifier rather than treating an email address as the durable identity key.
That is not the same event as a company forwarding an ex-employee’s mail. The mechanism is different. The security lesson is the same: an email address is a routing identifier, not reliable proof that the original human still controls it.
Germany’s guidance highlights the privacy collision
The technical advice also has a privacy dimension that varies by jurisdiction. The data-protection commissioner for Saxony-Anhalt, Germany, published guidance in August 2025 stating that named employee mailboxes should generally be deactivated immediately when employment ends. The regulator argues that continued processing of personal data in a mailbox such as [email][email protected][/email] may no longer have a contractual basis after the individual leaves.
Its guidance takes a stronger position than the default continuity workflows promoted by Google and Microsoft. It says forwarding a named mailbox to a successor, or giving others access to it, is generally impermissible; an automatic absence notice directing senders to a new contact is the safer pattern. The reasoning is that personal messages can still arrive even where private use of work email was prohibited, and a successor’s access to those messages lacks a clear legal basis.
That does not make a German state regulator’s guidance a universal rule for every employer or every Microsoft 365 tenant. Records-retention duties, litigation holds, regulated-industry requirements, local employment law, and the distinction between a named mailbox and a functional address all change the analysis. It does show why “keep it running forever” is not a neutral administrative default when the address identifies a person.
A functional mailbox—such as billing@, support@, or sales@—avoids much of this problem. It signals a business role rather than impersonating a person who no longer works there. Organizations that need durable customer contact should move external correspondence toward those role addresses before staff departures, rather than treating an individual’s mailbox as permanent company infrastructure.
Offboarding needs an inbound-mail decision
Most departure procedures focus on disabling sign-in, revoking tokens, wiping managed devices, transferring OneDrive or Google Drive data, preserving records, and removing licenses. Those are essential controls. They do not answer the separate question of what should happen when an email arrives for the person after they leave.
For administrators, the practical fix is to make that decision explicit and time-bounded. Before enabling a forward or creating a shared mailbox, determine whether the organization needs historical data, new inbound messages, or merely a way to tell senders that the contact has changed. Those are different requirements and should not default to the broadest access arrangement.
A defensible process should include the following:
- Disable the former employee’s ability to sign in before any mailbox handover, including active sessions, OAuth tokens, recovery methods, security keys, and managed-device access.
- Prefer a short-lived automatic reply that names a replacement functional address when business continuity does not require reading new mail sent to the old named address.
- If forwarding is necessary, limit the duration, recipient group, and purpose, and document who approved access to the former employee’s communications.
- Review aliases, proxy addresses, transport rules, shared-mailbox members, delegation, and mailbox forwarding rules rather than checking only whether the user object was deleted.
- Move external-facing workflows to role-based addresses before a departure whenever possible.
Former employees have a separate, immediate task. Before losing access to the workplace account, check every personal account where the work address might appear as a sign-in name, recovery email, security-notification address, or contact address. Update it to a personal address controlled independently of the employer, add a recovery phone or authenticator where appropriate, and save backup codes where the service provides them.
Google’s consumer-account help does tell users to update recovery information when an old email address closes and notes that it may send verification codes to prior recovery information for seven days after a change. That grace period is a security safeguard, not a reason to postpone the update. Change recovery settings before the final workday, while both the old corporate inbox and the new personal route are still available.
The concrete takeaway is uncomfortable but straightforward: handing back a laptop does not end a company email address’s life. In Google Workspace and Microsoft 365, it may continue receiving mail for months or years by design. Treat that address as potentially controlled by the former employer from the moment employment ends—and remove it from private account recovery settings before someone else receives the next reset link.