Plus Addressing: One Inbox, Infinite Trackable Addresses

Most people sign up for a newsletter, a SaaS trial, and their bank using the exact same address: [email protected]. Then one day a spam wave hits that address and there's no way to know who sold or leaked it. Plus addressing fixes both problems — disposable per-service addresses and a built-in leak detector — using a feature that already works on your domain right now, with zero configuration.

The trick: everything between a + and the @ is ignored for routing but preserved in the headers.

[email protected]    → delivered to [email protected]
[email protected] → delivered to [email protected]
[email protected] → delivered to [email protected]

All three land in the same inbox. But each carries a tag you chose, and that tag survives all the way to the To: header of every message sent to it. You never created these addresses — they exist the moment someone sends mail to them.

Why the tag is the whole point

The value isn't the extra inbox. It's that the tag tells you where the address came from long after you've forgotten signing up.

Say you used [email protected] to buy something eighteen months ago. Today you get a "crypto opportunity" blast at that exact address. You now know, with certainty, that Acme Store either sold your address or got breached. No other service had that string. You filter it, report it, and move on — instead of wondering which of forty signups was the leak.

This is leak detection you get for free, retroactively, just by being slightly disciplined about the tag you type into signup forms.

Filtering on the tag

Because the tag is preserved, you can build inbox rules against it. In Biza Email, filters can match the full recipient address including the +tag:

{
  "match": { "to_contains": "+receipts" },
  "actions": [
    { "move_to": "Receipts" },
    { "mark_read": false }
  ]
}

Now every shop you signed up to as you+receipts@ files itself, no matter which shop it is. A few tags worth standardizing on:

Tag	Use
+receipts	Order confirmations, invoices
+newsletters	Anything you skim, not urgent
+2fa	Account-security mail you want surfaced instantly
+throwaway	One-time trials you expect to abandon

The filter matches the tag, not the sender, so it keeps working even when a service switches its sending domain or relays through a new provider.

Killing an address when it goes bad

Here's the part people miss: you can't delete a plus address, because it was never a real mailbox — but you don't need to. When you+that-sketchy-shop@ starts getting spam, you write one rule that sends that exact tag to the bin:

{
  "match": { "to_exact": "[email protected]" },
  "actions": [ { "discard": true } ]
}

The spammer keeps mailing into a black hole. Your real address stays clean. And mail to every other tag is completely unaffected, because each one is independent.

The honest limitations

Plus addressing is genuinely useful, but it is not a privacy fortress. Be clear-eyed about three things:

1. It's trivially strippable. The +tag convention is well known. A motivated spammer can mechanically rewrite [email protected] back to [email protected] and mail you directly. It defeats lazy list-sellers and casual leaks; it does not defeat someone specifically targeting you. For a hard wall, use a real distinct alias (a separate address with its own mailbox routing), not a plus tag.

2. Some signup forms reject the +. A surprising number of web forms run a too-strict regex that bans + in email fields, even though it's valid per RFC 5321. When that happens you can't use the trick on that service — note it and move on, or use a dedicated alias instead.

3. The tag is visible to the recipient. you+chase-bank@ tells Chase you tagged them "chase-bank." That's harmless, but if you tagged something +scam-probably, the recipient sees it too. Keep tags descriptive, not editorial.

Plus addressing vs. real aliases

It's worth knowing exactly where the line sits, because they solve overlapping but different problems:

• Plus addressing is free, infinite, and instant — no setup, no limit, created on first use. The cost is that it's guessable and strippable, and it always lands in the one mailbox before the +.
• A real alias (sales@, press@, a uniquely-named contact address) can route to a different mailbox or a shared team inbox, can be deleted at the source so mail to it genuinely stops, and can't be reverse-engineered back to another address. The cost is that you have to create each one deliberately.

A practical split: use plus tags for the long tail of self-serve signups where you just want filtering and leak-detection, and reserve real aliases for addresses you publish, hand to a team, or need to be able to fully shut off at the routing layer.

Start with three tags

You don't need a system. You need three tags you'll actually remember to type: +receipts for anything that buys you something, +news for anything you subscribed to, and a unique per-service tag for the handful of accounts that matter (banking, primary identity providers). Wire two filters — one to file receipts, one to surface +2fa — and you've turned a single mailbox into a labeled, leak-aware system without creating a single new account.

The next time spam shows up tagged with a name you recognize, you'll know exactly who to blame. That alone is worth the few extra keystrokes.