The one-alias-per-site workflow

The theory of aliases fits in one sentence: give every site its own address, and you can identify and revoke any of them independently. The practice is a handful of small decisions — what to name things, what to write down, when to pause, when to delete — and getting those decisions settled once means never making them again.

Here's a workflow that holds up past the fiftieth alias. Adjust freely; the load-bearing part is consistency, not the specifics.

Naming: site first, always

Put the site's name at the front of the alias: ryanair@, figma@, hardwarestore@emailforward.xyz. Resist the urge to be clever or random — six months from now, purple-otter-42@ tells you nothing, while ryanair@ is self-documenting in the From line of your inbox.

Two useful refinements:

• Disambiguate purpose, not date. If one site gets two aliases, suffix the reason: github-notifications@ vs. github-account@. Dates in alias names age badly; purposes don't.
• Keep it typeable. You'll occasionally read an alias aloud to a support agent. acme@ survives that; acme.x7-tmp@ doesn't.

The one exception: for sites you don't want to be associable with you at all, a random alias is the point. Name those in the notes instead.

Tags and notes: the memory you'll want later

Every alias here takes tags and a free-text note. The temptation is to skip them because the name seems obvious. The name tells you who; tags and notes tell you why and what state things are in.

A small tag vocabulary goes a long way:

• shopping, finance, newsletter, trial — category, so you can sweep related aliases together.
• trusted — senders you'd actually miss. Useful when bulk-pausing everything else.
• expendable — signups you already suspect. First candidates for deletion.

Notes are for the things tags can't hold: "gave this to the conference WiFi", "shared with the landlord", "trial ends in March". Thirty seconds at creation time, and future-you stops having to reconstruct history from message logs.

Speaking of which: each alias keeps a message history, so even with an empty note you can usually work out what an alias was for by looking at what it received.

The lifecycle: active, paused, expiring, gone

An alias isn't just on or off. The useful states, in order of increasing finality:

Active with rules. The default. If a sender gets noisy but the alias still matters, add a per-alias rule — block that sender, or drop subjects matching a pattern like (?i)webinar. Surgical, reversible.

Paused. Mail is dropped, the address keeps existing. This is the workhorse state. Pause after any signup where you only needed the verification email — the account works, the marketing never arrives, and you can unpause for a password reset years later. Pause is also the right first response to spam: it stops the flow immediately while you decide whether the alias deserves a rule or a funeral.

Expiring. For aliases with a known shelf life — a trial, a house hunt, an event — set an expiry date at creation and let it shut itself off. Better than a to-do you won't do.

Deleted. The address stops existing. Correct for compromised aliases and for services you've formally closed accounts with. Wrong for anything with a live account attached, because deletion takes the recovery path with it — temp-mail users learn this the hard way. When in doubt, pause instead; a paused alias costs you nothing.

The signup ritual, end to end

The whole thing, in real time:

1. Site asks for an email. Open /create, type the site's name as the alias. A few seconds, no login.
2. Add a tag and a one-line note. Ten more seconds.
3. Sign up with the alias. Verification email forwards to your inbox (or to Telegram, which is faster for codes that expire in minutes).
4. Decide the alias's future now, while context is fresh: leave active, pause, or set an expiry.

Step 4 is the one people skip and shouldn't. The best moment to decide whether you want a site's email is the moment you can still remember signing up.

Periodic maintenance, kept honest

You don't need a weekly review. Twice a year is plenty:

• Skim the alias list (or export it — CSV/JSON export exists precisely for spreadsheet people).
• Anything tagged expendable that's been silent for months: delete.
• Anything active that only ever received marketing: pause.
• Anything whose note you can't decipher: improve the note or admit defeat and pause it.

If you're automating, the REST API does everything the UI does — some people generate aliases from their password manager's new-entry hook, which removes even the ten seconds.

What this buys you

After a few months the system runs itself: every sender is individually addressable, spam arrives pre-attributed, and "unsubscribe" becomes a button you own rather than a link you hope works. The per-signup cost is under a minute; the alternative is one address whose relationships you can neither see nor sever.

Start with the next signup, not with a migration. The getting started guide has the details.