# Email aliasing — a fresh address for every service > Your email is the master key to every account that uses it for recovery. Hand out a different alias to each service and a breach, a data broker, or a support-desk attacker can't pivot from one inbox to your whole life. Markdown twin of https://xmr.club/opsec/03-email-aliasing. CC-BY-4.0. Attribute "xmr.club". ## At a glance - Canonical: https://xmr.club/opsec/03-email-aliasing - Series: #OPSEC52 — weekly threat-model-first OPSEC cards - Week: 03 - Pillar: Digital identity compartmentalization - Difficulty: beginner - Cost: $0 (free alias tiers; ~$30/yr for a custom domain) - Published: 2026-06-15 ## Body # OPSEC52 / Week 3 — Email aliasing > Your email is the master key to every account that uses it for recovery. Hand out a different alias to each service and a breach, a data broker, or a support-desk attacker can't pivot from one inbox to your whole life. **Threat model:** a correlator stitching your accounts together through a shared email — data brokers and breach-aggregators that index leaked addresses, marketers selling your contact graph, and account-recovery attackers pivoting off your single real inbox. Last week we built the wall: [one persona per purpose](/opsec/02-identity-compartmentalization). This week we harden the single most-reused identifier behind those walls — your email address. It's the one detail almost everyone still shares across every context, and it quietly links them all. ## Why your email is the real master key A reused email is worse than a reused username, because it's not just a label — it's a *control channel*. Whoever owns that inbox can reset the password on every account attached to it. So one address used everywhere does two things at once: it **correlates** your accounts (the same string shows up in every breach dump, and brokers join on it), and it **centralizes** your risk (one compromised inbox unlocks everything). When your address surfaces in the next leak — and it will — anyone can paste it into a breach-search tool and instantly see the full list of services you use. That list *is* a profile. ## Aliases, not a second inbox The fix isn't "make a second Gmail." A second inbox is just a second thing to check, and you'll still reuse it. The fix is **aliases**: a unique, disposable address per service that all forward into one inbox you actually read. Outbound replies come *from* the alias, so the service never learns your real address. Burn an alias the moment it starts getting spam or shows up in a breach — the underlying inbox is untouched, and you learn exactly which service leaked you. ## Three ways to do it 1. **An alias service** — SimpleLogin, addy.io (formerly AnonAddy), or Proton Pass's built-in aliases. Generate a fresh random address per signup, forward to your real inbox, reply through the alias. Free tiers cover most people; this is the lowest-effort start. 2. **A catch-all on your own domain** — register a cheap domain (~$30/yr), point a catch-all at your inbox, and invent addresses on the fly: `netflix@yourdomain`, `forum-x@yourdomain`. No service to depend on, infinite aliases, and you own the namespace. The trade-off: the domain itself is now a (pseudonymous) identifier, so don't register it with your real name if the contexts are sensitive. 3. **Plus-addressing** (`you+netflix@gmail.com`) — better than nothing, but **weak**: anyone can strip `+netflix` to recover your base address, so it gives you *labelling* but not *unlinkability*. Use it for sorting, never for compartmentalization. ## The breach test Here's the payoff. With per-service aliases, a leak becomes a *signal* instead of a disaster. Spam arriving at `forum-x@yourdomain`? That forum sold or leaked your data — and only that alias is burned. Compare that to the shared-inbox world, where a breach somewhere you forgot about ten years ago still has your live, everyday address. Aliasing turns "my email is everywhere" into "each address has exactly one job, and I can revoke any of them." ## Don't re-link what you just separated Aliasing only holds if the rest of the wall holds. Two failure modes undo it instantly: setting the alias's **recovery** back to the same shared inbox under your name (you've re-centralized the master key), and pairing a "private" alias with a **KYC'd payment rail** in the same checkout. Keep the recovery path inside the persona, and pay private contexts with XMR or a no-KYC card. ## This week's checklist - [ ] Pick an alias method — start with [a service](/email/protonmail) if you want zero setup, or a catch-all domain if you want ownership. - [ ] Generate a **fresh alias for the next account you create** — don't migrate everything at once, just stop the bleeding. - [ ] Replace the email on your **2–3 highest-value accounts** (exchange, primary email recovery, anything financial) with dedicated aliases. - [ ] Run your real address through a breach-search tool once, so you know what's already out there. - [ ] Confirm no alias's **recovery** falls back to a shared, real-name inbox. Your email is the thread everything else hangs from. Cut it into one thread per account and there's nothing left to pull. **See also:** [OPSEC52 Week 2 — Identity compartmentalization](/opsec/02-identity-compartmentalization) · [OPSEC52 Week 1 — VPN exit discipline](/opsec/01-vpn-exit-discipline) · xmr.club [private email providers](/email/protonmail). *Curated by [Cyber Satoshi](https://x.com/xbtoshi)* ## Related - HTML: https://xmr.club/opsec/03-email-aliasing - Series index: https://xmr.club/opsec - Twin index: https://xmr.club/llm/opsec.txt