Check Now
Check yourself

How to Set Up Breach Alerts for Your Whole Org, Free

September 3, 2026
Breach alerts for your whole org, free: a receipt listing subscribe, verify the domain, name the owner, total zero

A breach notification nobody reads is just a log line.

That sentence has been true at every company I’ve worked with in 20+ years of security work. The tooling was never really the problem; ownership was.

So this walkthrough covers both: the free two-layer alert setup, and the one decision that makes it actually function.

The short version, if you keep nothing else: every person subscribes their own address (two minutes each), one person verifies the company domain (ten minutes, once), and one named person owns acknowledging what comes in. All of it free, for your own organisation, for as long as XposedOrNot exists.

Why bother this week rather than someday?

Our catalog added 123 breaches in 2026 so far, 781 in total as of 3 September 2026, and 780 of them list email addresses. Odds are somebody on your domain is in the next one.

The only question is whether you hear about it from your own alert or from a customer.

The two layers, and why you want both

Layer 1 is personal. Each person subscribes with their own email address.

When that address turns up in a newly indexed breach, they hear about it directly, in their own inbox. People act on their own exposure faster than on a forwarded spreadsheet, every time I have watched it happen.

Layer 2 is organisational. You verify the company domain once. From then on, any new breach touching any address on that domain raises an alert to the monitoring address you gave when you verified, with the details of which addresses and what data types. This catches what Layer 1 misses: former employees’ addresses, service accounts, shared inboxes, and the people who never got around to subscribing.

Two layers of breach alerting: personal subscriptions cover the people who signed up, domain verification covers every address under the domain including the ones nobody enrolled, and one named owner acknowledges what comes in.

Neither layer costs anything. Here is the setup.

Layer 1: everyone subscribes (two minutes per person)

Go to xposedornot.com, run your work email through the check, and choose Get Breach Alerts on the results. One verification email arrives now; after that, only real breach alerts arrive from notifications@xposedornot.com.

Unsubscribe any time. No account, no password, nothing to install.

Make it a starter-checklist item for new joiners. The best time for someone to learn their email is in eight old breaches is their first week, not mid-incident.

Layer 2: verify the domain (ten minutes, once)

Open xposedornot.com/domain, enter the domain, and pick one of three verification methods. The site lists its own timings, and they match what I see in practice:

Method When to use it Site’s estimate
Email You have an admin-style inbox on the domain about 2 minutes
DNS TXT record You control the DNS zone (cleanest, survives site redesigns) about 10 minutes
HTML page or meta tag DNS and the admin inbox both belong to another team about 15 minutes

Two details that trip people up.

The monitoring email you enter has to be on the same domain you are verifying. And with the email method, the link you get expires after 30 minutes, so don’t start it right before a meeting.

(DNS has its own delay: propagation can take 10 to 30 minutes, and the page says so.)

Once verified, the domain dashboard opens with every address on the domain that appears in our catalog, and alerts switch on for anything new. The domain monitoring post has the screenshots for each method if you want them side by side, and the dashboard walkthrough explains what you are looking at once it loads.

What an alert actually contains

Not a vague “you may have been affected”.

Each alert in the dashboard carries the alert time, the breach name with its record count, a severity rating, how many of your addresses were hit, a description of what happened, and a status that starts red and stays red until someone deals with it. That last column is the one I care most about.

The Real-Time Breach Alerts card on the domain dashboard: one alert for the Paidwork breach, one email affected, severity high, status acknowledged.

Why does acknowledgment matter more than the alert?

This is where most alerting quietly fails.

An email goes out at 2am. It sits unread, or five people each assume another read it.

Six weeks later, someone asks, “Did we know about this?” and the honest answer is “technically”.

Our domain alerts stay open until someone acknowledges them.

Click the action, read the full exposure detail, confirm that the internal steps have started. Seen, owned, closed, with a record of who and when.

We built it in November 2025 because teams told us the emails were arriving fine, and the follow-through was the problem. It ships in the free tier; we’ve checked our own free account against this paragraph before publishing.

Which brings me to the one decision that matters more than any tool:

Decide now who acknowledges breach alerts. One name, or a small rotation.

Write it down where your team writes such things. An alert with an owner is a process.

Without one, it’s decoration on a dashboard nobody opens.

Who should it be?

Not necessarily the most senior person. The best owner is whoever can actually trigger a password reset and get a reply from a colleague within the hour.

At ten people, that’s usually the founder, or whoever set up the laptops. At two hundred, it’s a helpdesk lead with a named backup (the backup matters more than the lead; holidays happen).

What to do when an alert fires

Keep it boring and repeatable:

  1. Open the alert and read what leaked, and only then who. A password exposure and a marketing-list exposure are different days.
  2. Check the tag before you touch anything. Stealer log or combolist? The three leak types explain why a stealer-log hit means a device scan before any password change.
  3. Passwords involved and the device is clean? Reset the affected current-employee accounts, and ask whether that password was reused anywhere internally.
  4. Former-employee addresses: confirm those accounts are actually dead everywhere that matters, beyond the mail system.
  5. Acknowledge the alert. Done is a state, not a feeling.
Five steps after an alert: read what leaked, check the leak type, reset current accounts, close former-employee accounts, acknowledge.

Say an alert lands for examplecorp.com (fictional): a newly indexed retail breach includes three of your addresses.

You open it. Two are current employees with passwords exposed; one is a marketing inbox that only leaked an email address.

The two employees reset today and confirm those passwords are not reused on anything internal. The marketing inbox gets a note and nothing else. Whoever is on rotation acknowledges with one line (“2 resets done, 1 no-action”).

Elapsed time: about twenty minutes, most of it waiting for two people to reply on chat.

What does free actually cover?

Everything in this post.

Both layers, the domain dashboard, the per-address detail, the alerts, and the acknowledgment workflow, for your own organisation, with no expiry. That’s not a trial tier; it’s the point of the project.

The alerts do not have to live in a mailbox either. They can land in a Slack or Teams channel, or in your SIEM, so the acknowledgment happens where the team already works.

If your operations centre runs Microsoft Sentinel, the open-source Sentinel connector pulls the same exposure data into your workspace, also free.

Paid xonPlus plans exist for a different job: watching other people’s domains at scale, which is what managed security providers (MSSPs) and security platforms do for their clients. If you are protecting your own company, you don’t need them, and nobody here will tell you otherwise.

The whole setup, summarised

  1. Everyone subscribes to their own email. (2 minutes each)
  2. One person verifies the domain. (10 minutes, once)
  3. One name owns acknowledgments. (1 decision)

One coffee’s worth of setup, and the whole domain is watched, with a name on the alerts. Start here: xposedornot.com/domain.

Questions people ask before they set this up

Does the domain alert cover people who left the company? Yes. That’s the main reason Layer 2 exists. Any address on the verified domain that appears in a new breach raises the alert, whether or not the mailbox still has an owner.

We have several domains and subdomains. Do I verify each one? The dashboard breaks exposure down by domain and subdomain. Verify each domain you own; they all land in the one view.

Will this flood the inbox? No. Alerts fire when a newly indexed breach touches your domain, not on a schedule. In my experience, a small or mid-size domain sees a handful a month, sometimes none, and many of them describe breaches that happened years ago and only surfaced now.

And if acknowledgment-built-in is how you think alerting should work, drop us a star on GitHub. It helps others find the project, and honestly, it makes our day.

Appendix: sources and references

—

Check out some of our posts for you.

Facebook Twitter Linkedin Mastodon
| © 2026 XposedOrNot.com.