Alias governance playbook for modern households and small teams

A common pattern with any privacy tool: enthusiastic adoption in week one, gentle entropy by month six. People create lots of aliases, lose track of which is which, and end up with the privacy equivalent of a sock drawer.

This is preventable with a small amount of upfront convention. None of it is hard, none of it takes long, and the difference between “we have a system” and “we had a system once” is mostly knowing what to write down.

Naming conventions are the load-bearing wall

The worst thing you can do is create aliases as opaque random strings. Yes, technically that’s the most private; in practice you can’t remember which one was for what, you can’t audit them, and you’ll either delete the wrong one by mistake or stop deleting any of them. A naming scheme is what makes the system usable over time.

A scheme that works in most contexts:

• <context>-<purpose>@yourdomain for short-lived aliases. marketplace-bike@, quotes-broadband-2026@, trial-spotify@.
• <role>@yourdomain for permanent ones. hello@, quotes@, accounts@, school@, household@.
• <person>@yourdomain for individual professional aliases. firstnamelastname@, firstname@.

The point of the scheme isn’t elegance — it’s that future-you can look at an alias name and immediately know what it was for and whether it’s still relevant.

Retirement is a habit, not an event

Aliases that never get retired are the entropy. Build retirement into the same moment you’d naturally close out the activity:

• Sold something on a marketplace? Delete the alias when you mark the listing as sold.
• Finished a job for a client? Pause the per-job alias and number when you send the final invoice.
• Booked the energy supplier? Delete the comparison-aliases the same day.
• Started a new permanent role? Pause the job-search alias once you’ve passed probation.

The retirement step takes ten seconds. Not doing it is what creates the long tail of stale aliases.

A quarterly spring clean

Once a quarter, open the alias dashboard and look at the analytics:

• Aliases that haven’t received mail in 90 days — almost certainly safe to retire.
• Aliases that suddenly went quiet after months of traffic — sometimes a relationship ended cleanly, sometimes the sender’s domain has a problem. Worth checking either way.
• Aliases attracting suspicious volume — usually one specific sender; either filter them out or retire the alias.

This works the same way for individuals (spring-cleaning your personal aliasing setup) and for small teams (reviewing what’s in shared use).

Document it once, lightly

For families and small teams, write a one-page document — yes, on paper, or in a shared note — that lists:

• Which aliases exist and what they’re for
• Who’s on the routing for each
• The agreed naming convention
• Who reviews it once a quarter

It will save an absurd amount of confusion the first time someone leaves the household, the team grows, or someone forgets why a particular alias exists at 11pm on a Tuesday.

And if it does get out of hand

It happens. The fix is the same as any drawer-full-of-tangled-wires fix: pick one rainy afternoon, audit ruthlessly, retire what isn’t used, rename what’s confusing, and start the spring-cleaning rhythm from there. The system tolerates a clean-out — there’s nothing fragile about deleting unused aliases.