How to Find Out Which Website Leaked Your Email Address

I run AliasFleet, an email-alias service. One of its features, vendor leak detection, answers a question every developer has asked at least once: which site leaked my address? The mechanism behind it is simple, and that is the point. Let me walk through how it works under the hood.

Your address is a join key

Think of your single email address the way you would think of a database key. It appears in the users table of every service you ever signed up for. When any of those databases leaks, your address lands in the same breach dumps, next to the same name and password hash, and anyone joining those tables on the email column can build a full picture of you.

With one address everywhere, you can never run the query in reverse. Spam arrives from a sender you never heard of, and there is no column in the data that says which table it came from. The address carries no provenance.

Plus-addressing is the cheap version, and it breaks

Most developers know the trick: sign up as [e-mail], and anything that arrives tagged +store came from that store. It works, right up until it does not.

The problem is structural. The tag is visible in the address itself, so anyone who has it can remove it with one regex. Several signup forms reject addresses containing + outright. And the fallback is guessable: strip the tag and you have the real address anyway. Plus-addressing is a label you write on your own forehead. It is not a separate identity.

A real alias is a genuinely different address, [e-mail], with no visible relationship to your real inbox. There is nothing to strip.

The mechanism: aliases as provenance tags

The whole trick reduces to a routing table. Every alias is a row: inbound address, destination inbox, active flag, and a small history of which senders have legitimately used it.

When mail arrives, the flow is roughly:

# illustrative pattern, not production code
alias = lookup(envelope_to)            # "[e-mail]"
if not alias.active:
    return "550 address disabled"      # killed alias bounces here
if sender not in alias.known_senders and message.looks_unexpected():
    flag_for_review(alias)             # possible leak: unexpected mail
forward(alias.destination, message)

The leak signal is the interesting part. An alias given only to one shop has a known sender set: that shop's domains. When mail arrives on that alias from a sender outside the set, say a marketing list or a stranger, something is off. Either the shop sold the list, shared it with a partner you never agreed to, or its database leaked. The alias names the source because it was only ever given to one place.

This is also why each alias must be unique per site. Reuse one alias across five shops and you are back to one address everywhere, just with extra steps. The provenance only holds if the mapping is one to one.

What one click actually does

When an alias starts receiving unexpected mail, there are four moves, and each maps to something concrete in the routing table:

Block the sender. The sender goes on the alias blocklist. Future mail from them is rejected or silently dropped, while the alias keeps working for everyone else. Use this when one bad actor found the address but the shop itself is fine.

Kill the alias. Set active = false, and everything to that address bounces with a 550. The address is dead. Use this when the alias is burned beyond saving and you never want to hear from that source again.

Rotate the alias. Mint a fresh alias with the same destination, and update the address stored on that one site. The old address stops working; the new one has a clean sender history. This is the move when you still need the account but the old address is compromised.

Mark safe. Add the unexpected sender to the alias's known-sender set. Sometimes the "leak" is just a shop switching email providers. No action needed, and the system stops flagging it.

None of this requires changing your real address, notifying your contacts, or rebuilding filters. The blast radius is exactly one alias.

What this does not fix

Let me be honest about the limits. An alias tells you which site leaked your email and cuts off the email channel. It does not stop the site from leaking your name, phone number, or address alongside it. That damage is done the moment the database goes. And if you hand out your real address anywhere, the whole scheme has a hole in it. Aliases contain the email vector; they do not make the underlying leak go away.

They also do not replace checking whether you were exposed in the first place. If you want to know what is already out there, Have I Been Pwned remains the canonical check.

---

I am Ahsan, founder of AliasFleet. I build managed email aliases: one address per site, so the next leak names its source instead of your identity, and you can kill the alias in one click.