Data breaches are now part of everyday life online. A lot of people only realise their address was in a breach when spam jumps or password reset emails start arriving from services they do not recognise. The good news: checking your email against public breach indexes is free and takes about a minute.
This guide shows you how to check your address with Have I Been Pwned, why it is worth using a second tool, how to interpret a result without panicking, and how email masking helps stop the next leak from spreading across your accounts.
Step 1: Start with Have I Been Pwned
Have I Been Pwned (HIBP), maintained by Troy Hunt, is the breach-checking site most people know by name. Enter an email address and it tells you whether that address appears in any breach HIBP has indexed.
The dataset is large and changes constantly. For current incident counts and details on how the service handles data, read HIBP's own About and FAQs pages rather than relying on a dated blog snapshot.
Practical flow:
- Visit haveibeenpwned.com.
- Paste the address you care about.
- Submit the search (the home page labels the button plainly).
If there is a match, you get a list of incidents: who lost the data, roughly when, and which data classes were involved (email only, passwords, phone numbers, and so on). If nothing lines up, you get an explicit “all clear” style message.
Turn on notifications
HIBP's Notify me option emails you when your address appears in a future breach. That is easier than setting reminders to rerun the same search manually.
Run Pwned Passwords on anything you still type from muscle memory
HIBP's Pwned Passwords is a separate check. It tells you whether a password has appeared in breach material without storing that password next to your identity in a naive way. The site explains the k-anonymity style hashing it uses. Read it once so you understand what "safe enough to check here" actually means.
If a password you still use lights up, change it everywhere you lazily reused it.
Step 2: Add a second data source
No breach aggregator sees the whole internet. Different projects ingest different public dumps.
Maskmail's free Email Breach Check calls the public XposedOrNot API. Run your address through HIBP, then through that page. If the tools disagree, treat that as useful signal. It usually means "dig here next," not "ignore the warning."
Step 3: Read hits with a cool head, not like a headline
Each row in a result list answers three questions:
Who lost the data? If the account still exists, start there. Use a genuinely new password, not one recycled from another login.
How old is the incident? Age matters. If you changed the password after the breach became public, the old leak is mostly historical noise for that one site. If you never changed it, assume the password from that period is public knowledge.
What data leaked? Email alone is enough to attract spam and phishing. Passwords, phone numbers, or street addresses raise the stakes. If passwords leaked and you reused one elsewhere, treat every site that shared that password as exposed until you change them all.
Step 4: Contain the blast radius
When your address shows up:
- Rotate the password on the breached property first, using a unique strong secret.
- Enable two-factor authentication anywhere the vendor offers it, so a stolen password is not enough on its own.
- Chase reuse. One password reused across five services means one leak opens five doors. That is the cascade people warn about and almost nobody audits until it hurts.
The uncomfortable truth: one mailbox, hundreds of relationships
Most "change your password" articles stop there. The harder problem is structural: you still type the same personal address into every vendor, newsletter, and parking app. The next breach still targets the same identifier.
That address was never meant to be a public key for the whole web. It anchors password resets, bank notices, and private conversations. Once brokers and aggregators have copied it, there is no honest "delete from the internet" button.
That is why email masking belongs in the conversation about future signups, not only about yesterday’s headline breach.
How masking caps cascade damage
With masking, each vendor gets a dedicated relay that forwards into the inbox you already use. They never need your real address to deliver mail. For the mechanics, read how email masking works.
When a masked vendor leaks:
Blast radius shrinks. Attackers might recover one relay address. They do not automatically get the address you use for your bank or cloud account if those relationships use different relays.
You can sever one relationship cleanly. Disable the leaked relay; that path stops. Other relays and your underlying mailbox keep working.
Attribution is obvious. One relay maps to one vendor. No guessing which sloppy signup caused the noise.
With Maskmail, you create a fresh relay whenever a form asks for email. Delivery stays near real time into Gmail, Proton, iCloud, or whatever inbox you already use. The Chrome, Edge, and Brave extension can insert a new relay without sending you to another tab.
If you use a custom domain, you can connect it to Maskmail and create addresses on demand. Catch-all routing can accept every address at that domain without pre-provisioning each one.
A boring habit that pays rent
Today: run your real address through HIBP and Maskmail's checker. Fix weak passwords, kill reuse, and turn on 2FA wherever it is not already enabled.
Going forward: treat your primary address like a secret, not a username. Every new vendor gets a relay. If that vendor leaks next year, you delete one forwarding address and keep moving. Your core inbox, reset paths, and sensitive mail stay on infrastructure you control.
The old breach already happened. What you still control is whether the next headline dumps your real string again.