Your email address rarely leaks because a hacker picked you. It leaks through vendors you never heard of, plus four other ordinary routes with nothing to do with being targeted. I run AliasFleet, an email-alias service giving each site its own forwarding address, so the next leak stays tied to one address you can switch off.
Breaches feel personal: the notice names a company you use, and the leaked fields are yours. Four of the five routes below run on systems you never chose and cannot control, and each one needs a different response. The one response that covers all five is the same: hand out addresses you can switch off.
The five routes at a glance
| Route | How your address escapes | What you notice first |
|---|---|---|
| Scraping | Bots copy addresses from public pages | Spam that creeps up, slowly |
| Credential stuffing | Reused passwords tried everywhere | Login alerts on sites you barely use |
| Vendor breaches | A supplier loses the file | A breach notice from a name you do not recognise |
| Misconfiguration | A setting leaves data open | Often nothing, until a dump surfaces |
| Phishing | You hand over the details yourself | Account changes you did not make |
Read them as one pipeline with five entry points.
Scraping: bots collect addresses you published
Harvester bots crawl web pages, forum posts, mailing list archives and comment sections, keeping anything shaped like an email address. Email-address harvesting covers the patterns: bots look for mailto links, staff directories, membership lists and comment sections where people write "email me at". Directory harvest attacks guess common usernames at a domain instead, keeping the ones the mail server accepts.
The sign is a slow rise in spam, not a single event. The address was public, so no breach notice arrives and there is nobody to blame. The fix is plain: never put your real address in plain text on a public page. A contact form does the job, and so does an alias you can switch off in place of a mailto link. Scraping may be fading as a source: How-To Geek's explainer reckons it is probably less common now than it used to be, because leaked account databases hand spammers bigger lists with less work. That is their assessment, not a measured figure. Scraping still feeds the lists.
One more habit matters: clicking a link or loading images in a spam message confirms the address is active, and spammers track that, so do not click, load images, or reply to unsubscribe from a message you never signed up for. An unsubscribe link in genuine company mail is fine. The same link in obvious spam is a live-address detector.
Credential stuffing: one reused password opens every door
Credential stuffing comes after a breach, and it is the route most people misunderstand. The raw material is a username and password pair from one leak, fed to automation that tries it against dozens or hundreds of other sites. OWASP defines the attack as the automated injection of stolen username and password pairs into website login forms to gain access to accounts. It works because the same password and email address get reused across sites. One leak turns into many logins.
Look for odd activity on accounts you barely use: a login alert from a shopping site, a password-reset mail you did not request, a streaming account with a new profile. The breach that supplied the pair can be years old. OWASP adds a wrinkle: leaked data can reset passwords, so a unique password does not fully protect an account whose recovery questions can be answered from breached data.
Give every site a password you have never used anywhere else, kept in a password manager. Switch on multi-factor authentication on your email account first, since every password reset flows through it, then your bank. NIST's guidance tells services to check new passwords against lists of known-compromised values, including passwords from previous breach corpuses, and to force a change once there is evidence of compromise. Believe a breach warning, and change it.
Vendor breaches: a supplier you never met loses your file
This is the route behind the thesis, and the one that angers people once they see it. You register with Company A, which passes your data to Vendor B for processing, analytics, payroll or file transfer. Vendor B is breached. Your data leaks out of a company you never dealt with, under a name you have never seen, and the breach notice turns up from Company A months later.
Verizon's 2025 Data Breach Investigations Report found third-party involvement in breaches had doubled to 30%, credential abuse stayed the leading initial vector at 22% of breaches, and the report covered more than 22,000 incidents and 12,195 confirmed breaches. A third of breaches touching a third party is structural.
MOVEit is the clearest example: from 27 May 2023, the CL0P group exploited a SQL injection flaw in Progress Software's MOVEit Transfer file-transfer tool, installed a web shell called LEMURLOOT, and stole data from MOVEit databases, as CISA's advisory records. Shared infrastructure meant one flaw cascaded. Cybersecurity Dive's timeline puts the impact above 2,650 organisations, including third-party vendor PBI Research Services, whose breach exposed millions of customer files, and CalPERS, where about 769,000 members' data was exposed via PBI. Nobody whose pension data was exposed through PBI had ever heard of PBI.
What arrives is a breach notice naming a vendor you have never heard of. The practical response starts with a search: check your address on Have I Been Pwned for the incidents that include it, change the password on the affected account and anywhere you reused it, and turn on multi-factor authentication. Expect phishing mail built from the leaked details, since the breach notice itself becomes the template for forgeries.
Misconfiguration: a setting, not an attack
Misconfiguration is the route with no villain in it: nobody forces their way in, a door just gets left open. A bucket left set to public, a shared drive with permissions left broad, an access list nobody ever tightened, an admin panel still on default credentials. The data sits there until someone finds it. Often nobody knows how long it sat there.
The NSA and CISA joint advisory on the most common misconfigurations puts default configurations of software and applications first, with weak or misconfigured multi-factor authentication, insufficient access control lists on shares and services, and poor credential hygiene alongside it. These weaknesses turn up in large organisations, including ones with mature security teams. The pattern is the problem.
AWS documents that new S3 buckets and objects block public access by default, but users can still modify bucket policies or object permissions to allow it, and Block Public Access settings exist to override those policies. One setting change usually separates a public bucket from a private one. CISA's cloud guidance adds the sharing angle: on a shared drive or document, one compromised account gives a threat actor the data, which is why it recommends least-privilege permissions, strong passwords and multi-factor authentication.
Usually you see nothing until a dump surfaces on a forum, with no notice and no timeline. No reliable public count exists, because many exposures are never disclosed. Do not invent a number for it. Do not trust anyone who does. The response is the same containment as everywhere else: assume exposure is possible, keep permissions tight on anything you control, and make the address you hand out expendable, so an exposure costs one dead alias, not a live key.
Phishing: you hand over the address yourself
Phishing is the only route where the victim does the leaking. It works because the message shows up wearing trust. The FTC's guide describes the pattern: scammers use email or text messages to steal passwords, account numbers or Social Security numbers, with stories about suspicious activity, account or payment problems, requests to confirm personal information, bogus invoices, payment links, government refunds, or free coupons. The message looks like it comes from a company you know, and the link goes somewhere else.
A successful phish shows up as account changes you did not make: a password changed, a new device signed in, money moved, mail rules quietly forwarding your inbox to someone else. After a breach, phishing gets sharper: the attacker holds your real details. A message quoting your name, your order and the company's real breach notice is far harder to spot than a blind one. Post-breach phishing works this way. The breach is the setup, and the phishing mail is the punch. The spoofing problem makes it worse: the From line in your inbox is a claim, not a fact.
Do not click the link, reply, or call any number printed in a suspicious message. Open a fresh tab and type the organisation's address yourself, or open its app. If it is not there, it was not from them. This one habit beats most phishing.
The response comes in three parts: verify through a separate channel; switch on multi-factor authentication everywhere it matters, since the FTC notes it makes it harder for scammers to log in even if they get your username and password; report the message. The FTC asks people to forward phishing email to reportphishing@apwg.org, phishing texts to SPAM (7726), and attempts to ReportFraud.ftc.gov. Reporting sharpens the filters for everyone behind you.
Containment: one alias per site
This is the part you control: vendors will still get breached, scrapers will still crawl, and companies will still misconfigure their storage. You cannot stop any of that. What you hand them is your call. Give every site its own forwarding alias, and the next leak stays isolated to one address. The alias tells you which site leaked: only that site ever had it. Pause or delete the alias, and that channel dies while your real inbox stays clean.
One mechanism covers all five routes. A scraped alias collects spam: switch it off. A stuffed alias collects login attempts: switch it off. A vendor breach exposes an alias that names its source: switch it off. A misconfigured bucket exposes an alias: switch it off. A phishing mail about Company X landing on the alias you gave to Company Y has identified itself as forged: Company X never had that address.
The limits matter too. An alias cannot recall an address you already handed out. Your real address has spent a decade across hundreds of sites, already sits in breach dumps, and no alias setup repairs that. An alias will not stop phishing from being sent. It stops it being believed. It replaces neither unique passwords nor multi-factor authentication, and it does not strip your name, phone number or postal address from the files that get traded. Data brokers sell profiles built from those fields. An alias only kills the address part of the profile. Saying otherwise would be a sales pitch. Not a fact.
What to do after your address leaks
Start by typing your address into Have I Been Pwned, which lists 1,045 breached sites and over 17.8 billion pwned addresses as of this writing. The results show which breaches include your address and what each one took, which decides the kind of problem you have.
Then, in this order: change the password on the affected account and every other account where you reused it. Switch on multi-factor authentication on your email account and bank. Leaked passwords or ID numbers mean account-takeover risk, not just spam. A leaked email address alone means a phishing problem: expect mail that knows your name and the company, and verify every breach notice separately. Pause any alias drawing abuse, and report phishing mail rather than deleting it silently.
The next leak is on its way. That is arithmetic. The question is which address leaks next: your real one, connected to everything, or a single-purpose alias you can switch off. Build the second version now. Before the notice arrives.
Top comments (0)