Security Risks of Reassigning Former Employee Email Aliases

Someone in your organization just left. IT has the laptop, HR has the exit paperwork, and the decision gets made: reassign their email alias to the new hire. It seems like the right call. The address has brand recognition, clients know it, and the replacement needs every advantage they can get.

The problem is what happens next.

That alias -- the one that looked clean when the transfer happened -- keeps receiving mail from external senders who saved it months or years ago. Password resets. Confidential replies. Automated notifications. The new owner opens their inbox and finds someone else's business.

This is not a hypothetical. It happens every time an alias gets reassigned without proper review.

What is an SMTP alias, really?

An SMTP alias is a forwarding address. The alias has no mailbox of its own. It forwards all incoming mail to one or more primary accounts.

For example, an organization might configure firstname.lastname@company.com as an alias pointing to f.lastname@company.com. Both addresses deliver to the same inbox. The alias exists for branding, catch-all routing, or role-based addresses like support@company.com that need to reach a team rather than one person.

The detail that matters for offboarding: the alias has no independent lifecycle. It is tied to the primary mailbox it forwards to. When that mailbox is deleted, reassigned, or soft-deleted, the alias's behavior changes based on platform settings -- and those settings are not always obvious.

Why aliases survive in address books after someone leaves

When colleagues, clients, vendors, and automated systems save an email contact, they save what they see. If they see firstname.lastname@company.com because it appeared as the From address on a message, that is what goes into their address book -- even if it was always an alias, not a primary account.

The person who saved that address often has no idea it was an alias. To them, it worked. They used it. They kept using it.

Months after the original owner has left, those saved addresses still generate mail. And if the alias has been reassigned to a new person, that mail lands in the new inbox -- with no warning, no context, no preparation.

The four risk categories

Password reset emails

External services -- SaaS tools, vendor portals, cloud applications -- use an employee's work email as an account identifier. When someone requests a password reset, the link goes to whatever address is on file.

If that address is a former employee's alias, and the alias has been reassigned, the password reset link arrives in the new owner's inbox. Depending on the service and whether the original account is still active, the new owner may be able to access the former employee's external accounts.

This is not a theoretical attack scenario. It is a consequence of normal password reset flows combined with alias reassignment.

Confidential business email replies

When someone sent a message to the former employee's alias, they may receive replies, forwards, or follow-ups from that original thread long after the person has left. If the conversation continues after the alias has been reassigned, those messages reach the new owner -- potentially with full context from the original exchange.

For roles in finance, legal, executive administration, or HR, this can mean receiving payroll data, contract negotiations, board communications, or disciplinary discussions intended for a predecessor.

Automated system notifications

HR systems, project management platforms, security tools, and internal automation send status updates, approval requests, alerts, and audit logs to email addresses stored in their databases. These notifications often arrive asynchronously -- weeks or months after the triggering event.

An alias can be reassigned and old notifications can keep arriving long after the handover appears complete. This is especially true for annual or quarterly automated reports.

Calendar invites and meeting data

Meeting invitations sent to an alias include attendee lists, meeting titles, agenda descriptions, and sometimes attached documents. A reassigned alias means a new owner receiving invitations for meetings they were never part of, exposing context about the former employee's final weeks at the company.

What actually happens in Microsoft 365 and Google Workspace

Microsoft 365: An alias is added as a proxy address on the primary mailbox. If the mailbox is soft-deleted (recycled), the alias may continue accepting mail during the 30-day soft-delete window. If the admin adds the alias to a different mailbox during that window, mail continues to flow there.

The practical risk: an admin adds the former employee's alias to a new user's mailbox. From that moment, any mail for the alias -- including misdirected password resets and confidential replies -- arrives in the new inbox. There is no built-in warning to the new owner about what they may receive.

Google Workspace: Aliases behave similarly but with different retention windows. Google Workspace can hold mail for a deleted account during a grace period before permanent removal. During that window, mail addressed to the alias may bounce or be rerouted, depending on how the admin configured the alias before deletion.

The common failure mode in both platforms: an admin reassigns the alias without checking what mail is still flowing to it, and without briefing the new alias owner about what they might find in their inbox.

How to reduce alias reassignment risk

Audit mail flow before reassignment

Before assigning an alias to a new user, check whether it is still receiving mail. In Microsoft 365, use the message trace tool. In Google Workspace, check the admin email logs. If the alias has active mail flow, investigate what is sending to it before routing it to a new inbox.

This is where aggregate report monitoring becomes useful. DMARC aggregate reports show which domains and IP addresses are sending mail authenticated as your domain -- including mail sent to specific addresses. Reviewing those reports before reassigning an alias tells you whether external systems are still using that address as an account identifier. DMARCFlow makes this straightforward by presenting aggregate report data in a readable format, so you can spot unexpected sending sources before they become a problem for the new alias owner.

Disable, do not delete

When an employee leaves, disable their primary account and review which aliases were attached before reassigning anything. Deleting the account outright can cause mail to bounce unexpectedly and may trigger forwarding rules that create compliance gaps. Soft-delete gives you a recovery window and time to audit.

Brief the new alias owner

If you do reassign an alias, tell the new owner exactly what they may receive and why. A former employee's HR notifications, password resets, and calendar invites are not what most people expect to find on day one. Setting that expectation prevents confusion and reduces the risk that sensitive mail sits unread.

Set expectations with external contacts

Where possible, notify key external contacts when an individual address changes. This matters most for role-based aliases -- ceo@company.com, finance@company.com, or equivalent addresses that outlast any single employee. A proactive change notification reduces the volume of misdirected mail over time.

Use role-based shared mailboxes instead of personal aliases

For ongoing business functions, use shared mailboxes or distribution lists instead of personal aliases. These have their own security and retention policies, are not tied to a single person's identity, and are easier to audit. They do not inherit the same alias-inheritance risk because they are not attached to a departing individual's account.

A simple decision framework for admins

Before reassigning any former employee's email alias, answer three questions:

1. Is this alias still receiving mail? Check message logs before doing anything else.
2. Is the new owner prepared to receive unexpected mail for this address? Brief them on what they might see and why.
3. Is there a better option? A shared mailbox, a distribution list, or a new dedicated address may serve the business better without the inheritance risk.

The short version: aliases attached to individual accounts carry forward risk. The longer something was in use, the more likely it has accumulated saved addresses in external systems, active sessions, and automated subscriptions. Treat that alias as a potential floodgate, not a clean redirect.

Frequently asked questions

How long should you wait before reassigning an alias?

There is no universally safe waiting period. The real answer depends on how many external systems use that address as an account identifier and how quickly those systems can be updated. In practice, aliases for individual employees should be reviewed and either retired or formally transferred within 30 days of departure -- not left in limbo.

Can you safely reassign an alias after a certain time?

The risk decreases over time as external systems cycle through password resets and account recovery flows. However, low-volume senders -- annual reports, quarterly statements, intermittent notifications -- may continue for years. Treat every reassignment as a new decision, not a routine handoff.

Are shared mailboxes safer than aliases?

Generally yes. Shared mailboxes have their own credentials and permissions, are not tied to a single person's identity, and are easier to audit. They do not inherit the same alias-inheritance risk because they are not attached to a former employee's account.

What should you do if you receive mail intended for a former employee?

Do not delete it unread if it appears to be sensitive. Forward it to IT or your security team, especially if it contains password reset links, financial data, or personal information. Then update the sender's address book if you can.

---

Oliver Higgs is the founder of DMARCFlow, a tool that helps organizations monitor and interpret their DMARC aggregate reports.