Drowning in Email Aliases? Audit and Clean Up Address Sprawl
Audit your email aliases before orphan addresses become security holes.
By JustEmails Platform Team
Last month I spent an afternoon tracking down why a client's invoice had been sitting unanswered for three weeks. Three weeks. Turns out it was sent to ar@theirdomain.com, which forwarded to finance@theirdomain.com, which forwarded to a contractor who left in January. The email was sitting in a mailbox nobody had logged into since Q1.
I wish I could say this was rare. It's not.
We're the JustEmails team — JustEmails is built by Velocity Digital Labs, and we've watched this pattern enough times that we built the unified inbox specifically to make email alias management visible. But the cleanup process is the same whether you're on JustEmails, Google Workspace, Microsoft 365, or anything else: inventory, prune, document, lock down.
Here's the step-by-step audit we run on our own domains. It takes about an hour and saves you from the invoice-in-limbo scenario.
What We're Doing
By the end of this, you'll have:
- A complete inventory of every email address on your domain (mailboxes, aliases, forwards, catch-all)
- Clear ownership assigned to each address
- Orphan aliases deleted or re-routed
- A documented naming convention for role addresses
- Catch-all either disabled or pointed at a monitored inbox
This isn't glamorous work. Nobody's going to thank you for cleaning up aliases. But it's the difference between "we have email" and "we have email that actually works."
Prerequisites
- Admin access to your email provider (Google Workspace Admin Console, Microsoft 365 Admin Center, JustEmails dashboard, whatever you're running)
- 30-60 minutes of uninterrupted time
- A spreadsheet (Google Sheets, Excel, Notion table — doesn't matter)
- Access to your team roster or HR system to cross-reference employee status
Step 1: Export Every Address on Your Domain
Most email providers let you export users and aliases. The export format varies, but you're looking for:
- Primary mailbox addresses (real accounts)
- Aliases (addresses that forward to a primary)
- Distribution groups or lists
- Catch-all configuration
Google Workspace: Admin Console → Users → Download users (CSV). For aliases, you'll need to check each user individually or use the Directory API. Groups are under Directory → Groups.
Microsoft 365: Admin Center → Users → Active users → Export. Aliases are visible per-user under "Manage email aliases." Distribution lists are in Exchange Admin Center.
JustEmails: Dashboard → Domains → select domain → Export addresses. All aliases, forwards, and catch-all settings export in one file. If you're migrating from another provider, see our custom domain email setup guide for the full walkthrough.
Paste everything into a spreadsheet with these columns:
| Address | Type | Forwards To | Owner | Last Activity | Status |
|---|---|---|---|---|---|
support@ | alias | helpdesk@ | Sarah | active | keep |
billing@ | alias | (none) | ??? | unknown | investigate |
mike@ | mailbox | — | Mike Chen | active | keep |
press@ | alias | ceo@ | — | never used | delete |
The "Owner" and "Last Activity" columns are what you'll fill in during the audit. Don't skip them — I've tried to shortcut this part before and regretted it every time.
Step 2: Cross-Reference Against Your Team Roster
This is where you find the ghosts.
Pull your current employee list — whoever has access to HR data or the company directory. For each mailbox and alias in your spreadsheet, answer:
- Is this person still at the company?
- If it's a role address (support@, sales@, billing@), who's responsible for monitoring it?
- Does the forwarding target still exist and get checked?
The addresses that fail these questions are your orphans. Mark them.
Common orphan patterns we see:
firstname@for someone who leftcontractor-name@for a project that endedoldrole@that forwards tonewrole@which forwards to someone who lefttest@,dev@,staging@that nobody remembers creatingdepartment-2024@temporary addresses that became permanent
Forwarding chains are the worst. If ar@ → finance@ → karen@ and Karen left, the whole chain is broken — but you won't see it unless you trace every hop. Honestly, the number of times I've found three-hop forwarding chains that end in a deactivated mailbox is embarrassing.
Step 3: Decide What to Keep, Delete, or Re-route
For each orphan address, pick one:
Delete if:
- No legitimate mail in 90+ days
- Nobody needs the address going forward
- Not referenced in any external system (vendor portals, bank accounts, domain registrations)
Re-route if:
- The address should exist but pointed to the wrong person
- Someone else took over the role
- It's a role address that needs a new owner
Disable forwarding and monitor if:
- You're not sure what's hitting it
- Might have external dependencies you forgot about
For the "not sure" cases: point the alias at a catch-all or ops@ inbox for 30 days. If nothing important arrives, delete it. If a vendor payment reminder shows up week 3, you've just avoided a late fee.
Real talk: deleting addresses feels riskier than it is. If an important sender emails a deleted address, they get a bounce and re-send to a working one. The actual risk is keeping orphan addresses alive — that's how password reset attacks happen, and that's how emails vanish into unmonitored mailboxes. For teams evaluating their current email costs alongside this audit, we break down the true cost of Google Workspace for 100-person teams.
Step 4: Document Your Role Address Convention
Now that you've cleaned up the mess, prevent the next one.
Write down which role addresses exist and who owns them. Something like:
| Role Address | Purpose | Owner | Backup |
|---|---|---|---|
support@ | Customer support | Sarah W. | helpdesk queue |
billing@ | Invoices, AR/AP | Finance team | finance@ list |
security@ | Vulnerability reports | Alex R. | CTO |
abuse@ | Spam/phishing reports | Ops | support@ |
info@ | General inquiries | Marketing | sales@ |
Include this in your internal wiki or runbook. When someone joins, point them at it. When someone leaves, update it.
The addresses that cause problems are always the ones nobody documented. Always. events@ seemed obvious until three people thought someone else was checking it.
Strong opinion: every domain needs at minimum abuse@ and postmaster@ — RFC 2142 says these should exist and some mail systems expect them. If you deleted them during cleanup, recreate them. Point them at ops or whoever handles abuse complaints. These are also the addresses attackers probe first, so make sure they're actually monitored.
Step 5: Lock Down Catch-All
Catch-all is the config that accepts mail to any address on your domain, even non-existent ones. It's convenient for small teams ("just email us at anything@ourdomain.com!") and a security nightmare at scale.
Here's why: every spam list, every typo, every enumeration attack lands in your catch-all inbox. And if nobody monitors it, legitimate mis-addressed mail — a customer typing supprt@ instead of support@ — disappears into the noise.
My strong take: disable catch-all for domains over 10 employees. Set up explicit addresses for everything. I know it feels restrictive — "but what if someone misspells our email?" — and I get it. But the security exposure isn't worth the convenience. If you absolutely need the flexibility, enable catch-all but route it to a dedicated monitored inbox (not someone's primary) with aggressive spam filtering.
JustEmails runs catch-all through Rspamd before delivery, which cuts the spam significantly. But even with filtering, catch-all on a domain that's been around for years means 50+ junk messages a day. Someone has to skim it.
If you can't disable catch-all (maybe you promised customers they could email you at literally any address), at least:
- Route it to a team inbox, not an individual
- Review it weekly for legitimate mail
- Create explicit aliases for anything that shows up repeatedly
The goal: reduce the attack surface. Every address that exists is one more target for phishing, one more potential password reset vector, one more path into your systems. Fewer addresses, fewer problems. That's it.
Common Errors and Fixes
"I deleted an alias and now a vendor can't reach us"
Re-create the alias immediately — most providers let you add it back in seconds. Then figure out which system referenced it and update the contact email there. This is exactly why we recommend the 30-day monitoring period before deletion.
"Our catch-all is flooded with spam since we enabled it"
Either disable catch-all entirely or enable aggressive spam filtering. On JustEmails, Rspamd scoring handles this automatically. On Google Workspace, content compliance rules can quarantine catch-all traffic. On Microsoft 365, Exchange transport rules can route catch-all to a quarantine folder.
"Someone left and we can't access their mailbox"
In Google Workspace: Admin Console → Users → select user → Reset password → sign in as them. Or delegate access to their mailbox from another admin. In Microsoft 365: similar — reset password or grant full access to another user. In JustEmails: the Owner role can access any mailbox directly.
"We found forwarding to a personal Gmail"
Ugh. This happens more than you'd think. This is a security incident, not just an org problem. Someone was routing company mail to a personal account. Remove the forward, check the mailbox for sensitive data, and review when it was set up. If it was set up by a departed employee, treat it as potential data exfiltration.
Next Steps
Once your aliases are clean, keep them that way:
- Quarterly audit: 30 minutes to re-run the spreadsheet exercise. Put it on the calendar.
- Offboarding checklist: When someone leaves, aliases and forwards pointing to them get re-routed same day.
- Naming convention: New role addresses follow the documented convention. No more
temp-billing-2@. (Yes, I've seen exactly that alias in production.)
If you're managing email across multiple domains — common for agencies or SaaS companies — our guide on flat-fee vs. per-mailbox pricing covers the economics. And if you're also dealing with deliverability issues surfaced during this audit (SPF/DKIM/DMARC problems), our DMARC ramp guide walks through the safe path to p=reject.
For click fraud protection on your ad spend, ClickzProtect handles the same kind of hygiene work but for paid traffic — identifying the orphan clicks and bot patterns that drain budgets.
Frequently Asked Questions
How do I know if we have too many email aliases?
If nobody on your team can list every alias without opening the admin panel, you have too many. A more concrete signal: you discover forwarding addresses during an incident — a customer complaint hits an alias that routes to someone who left six months ago. Or spam is flooding in through a catch-all and nobody knows who created it. The threshold isn't a number; it's whether your team has documented ownership of every address and reviews that list at least once a year.
Should I delete old aliases or just disable forwarding?
Delete if the address has zero legitimate inbound in the last 90 days and you're confident no external systems reference it. Disable forwarding first if you're not sure — point it at a monitored inbox like ops@ for 30 days and watch what comes in. Anything important surfaces; anything spam-only confirms deletion is safe. The risk of deleting too fast is missing a vendor or customer who only emails that address quarterly.
What's the security risk of unmonitored aliases?
Three risks. First, password resets: if an alias routes to a departed employee's mailbox (or nowhere), an attacker who controls the old inbox can reset SaaS credentials tied to that address. Second, phishing surface: attackers probe common role addresses (billing@, finance@, ceo@) — if those exist and nobody monitors them, a spear-phish sits unread until it's too late. Third, catch-all exposure: every typo and every spam list lands in a catch-all, and if nobody reviews it, you miss both legitimate mis-addressed mail and the signal that your domain is being scraped.
How often should we audit our email aliases?
Quarterly for teams adding domains or people frequently; annually for stable orgs. The audit itself takes 30-60 minutes once you've done it before — pull the export, cross-reference against the employee roster, verify forwarding targets are active, spot-check catch-all traffic. Put it on the ops calendar the same way you'd schedule a software license review or an access audit.
Try JustEmails
Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.