mailcat: checking which email providers have a username registered

A nickname in, candidate addresses out

mailcat is described as a tool to find existing email addresses by nickname, using API and SMTP checking methods, and its own description adds the phrase without user notification.

That last clause is the honest part of the pitch and it defines the tool's character. There is no account to create, no message to send and no password to obtain. The tool asks providers whether a given username appears to be taken, and reports the addresses it can confirm. What it produces is a mapping from a public handle to the addresses that handle may own.

The mechanics are provider-specific, which is why the tool is a list of checks rather than one algorithm. Some providers expose an availability endpoint that answers with JSON, some accept a registration form and report that the name is already taken, some can be probed over SMTP by asking the MX server for the mailbox, some only reveal their availability API to JavaScript running in a page, and one is checked through a credential lookup against the Microsoft account service.

For the right reader this is reconnaissance tooling, in the same family as username enumeration services. The legal position of probing a provider with a username is not something a README settles, and the honest framing is that the person running the tool is responsible for having a reason to run it.

Three families of check, and what each one reveals

The provider table makes the mechanics visible, and the Method column is the most informative part of it.

SMTP is used for Gmail, Yandex and mailDe. The README's troubleshooting section explains that these checks reach the destination provider's MX servers on TCP port 25, which is why they fail from most networks. The SMTP method is the most direct of the three because the answer comes from the mail server itself rather than from a web interface.

API is used for Protonmail, which covers protonmail.com and three aliases.

Registration is the most common method, used for MailRu, Rambler, Yahoo, AOL, Zoho, Eclipso, Posteo, Firemail, StartMail, Ukrnet, Runbox, DuckGo, emailn, aikq, Vivaldi, t.pl, Mailum, and others. This works by submitting the candidate address to the provider's signup form and reading the response that says the name is already taken.

Headless Chromium is used for Fastmail, int.pl and onet.pl, because those providers only expose their availability API to page JavaScript. The README gives the reason plainly: they drive a real browser because the API is not reachable any other way.

Two more labels complete the set: MSA credential lookup for Outlook across outlook.com, hotmail.com, live.com, outlook.de and msn.com, and password recovery for Interia. Whether a given method returns a yes or a no depends on the provider's own behaviour, which is why the tool reports what it can confirm rather than a definitive answer.

26 active providers and eight that the README asks you to ignore

The README states 26 active providers covering more than 158 domains, plus roughly 50 Posteo alias domains.

The provider table lists 34 rows, of which 26 are marked Active and 8 are marked Deprecated: iCloud, HushMail, Xmail, Tutanota, Mailbox.org, WP, O2 and Gazeta.pl. Deprecated checks remain in the source for revival but are skipped on a default run.

That detail is the most useful piece of documentation in the repository. The README points to the comment block above each function in src/mailcat/__init__.py for the upstream change that broke the check and notes on how to revive it. So a provider that stopped answering does not silently disappear; it stays in the tree with a note explaining what the provider changed.

That design also tells you something about the maintenance reality. These checks are coupled to web interfaces and API behaviour that no provider promises to keep, so half the table is already retired. For a reader, the practical consequence is that coverage is a snapshot with a half-life, and the eight deprecated rows are the visible proof of it.

Installing and running it, including batch mode

The install path from PyPI is the recommended one, and the distribution name differs from the project name:

pip install mailcat-osint

Building from source goes through a clone and a local install:

git clone https://github.com/sharsil/mailcat
cd mailcat
pip install .

The command line takes a username, either as a script or as a module:

mailcat username
python -m mailcat username

Several usernames can be checked in one run as positional arguments, or read from a file with one username or address per line, and the two can be combined with positional names merged with those from the file:

mailcat alice bob charlie
mailcat --file usernames.txt
mailcat alice --file more_users.txt

When more than one username is resolved, a header is printed before each result block so the output stays readable, with lines such as [*] Checking username: alice.

The Python packaging metadata is worth noting for anyone integrating this. The package requires Python 3.10 or newer, is classified as Development Status 4 - Beta, is OS Independent, and declares a console script entry point of mailcat = "mailcat:main". The runtime dependencies are aiohttp, aiohttp-socks, aiosmtplib, dnspython, lxml-html-clean, requests-html and tqdm.

Port 25 is the reason Tor appears in the README

The troubleshooting section is the most operationally useful part of the document, and it explains why the tool recommends Tor without being able to work around the issue any other way.

The SMTP-based checks reach the destination provider's MX servers on TCP port 25. Most residential ISPs and every major cloud provider, AWS, GCP, Azure and Heroku named in the README, block outbound port 25 as an anti-spam measure, so those checks time out with a message about failing to connect to the provider's SMTP host on port 25.

Mailcat has built-in Tor support through the --tor flag, and it expects a SOCKS5 proxy at 127.0.0.1:9050, the default when you run tor locally. The README's own recipe starts Tor and then runs the tool through it:

brew install tor && tor &

You can also restrict the run to just the providers that need it with repeated -p flags, for example -p gmail -p yandex -p mailDe, and the HTTP-based checks work fine from any network without Tor.

The costs are stated as well. Tor adds roughly 5 to 15 seconds of latency per request and the README calls it the only reliable way to make the port 25 checks work from a typical home or cloud environment. The alternative it suggests is a clean VPS with unblocked egress on port 25, reached with --proxy or by running mailcat on that machine directly.

There is also a connection limit. Mailcat does 10 parallel connections by default, and the -m or --max-connections option exists for when you hit connection errors.

Headless Chromium checks drag in a browser and its system libraries

Three checks, fastmail, int.pl and onet, drive a real browser, and the README explains the cost of that choice.

Pyppeteer downloads its own Chromium, roughly 150 MB, on the first run. On a slim Linux machine that binary still needs system libraries that are usually missing, and the failure surfaces as a warning that the check failed with a browser issue and the browser closed unexpectedly. The README lists the Debian and Ubuntu packages to install, including libnss3, libnspr4, the ATK and AT-SPI libraries, libxdamage1, libasound2t64 and libxres1, and it notes that before Ubuntu 24.04 the t64 suffix is not used.

Two things follow from this design. A first run downloads a browser, which is not something you want happening inside a CI job without pinning it, and the browser-based checks are the slowest and most failure-prone part of the tool, since they depend on both a browser build and a set of desktop libraries that differ between distributions.

There is a positive side, which is that the headless approach is the only way to reach these three providers at all, because their availability API is exposed only to page JavaScript. That is a good example of why a tool like this needs maintenance: when a provider changes how it answers, the check has to change with it.

Licence, packaging and what the repository does not cover

The licence is Apache-2.0, declared in the project metadata with the licence file listed in license-files and present as the LICENSE file at the repository root.

The package is published on PyPI as mailcat-osint at version 0.1.1, with sharsil as an author and Soxoj as the second author and the maintainer. The repository has no GitHub releases, so the PyPI version is the only versioned artefact, and the version number is still low, which matches the Beta development status classification in the metadata.

On activity, the repository is not archived and the last push was on 2026-09-05, with a commit history that is mostly upstream web changes rather than release churn.

What the repository does not contain is worth naming. There is no list of what the tool considers acceptable use, no rate-limit guidance for the providers beyond the parallel connection cap, and no documentation of how the results should be recorded or handled once you have them. The tests directory and the src layout are the whole of the engineering surface.

That combination, permissive licence and small surface, means the tool is easy to install and easy to extend, and it also means the person running it carries the entire compliance judgement. If your use is legitimate research on accounts you have the right to examine, the provider list is the thing to read first, because a probe against a registration form is a request to a third party that you cannot undo.

Editorial conclusion

Adopt mailcat if your work involves correlating a username with the addresses behind it, for example in fraud investigation, account recovery research or verifying a contact identity that you already have grounds to check. Do not adopt it to build a mailing list from third-party names, because that is harvesting rather than investigation, and do not expect complete coverage, since the provider list is a set of snapshots of upstream registration flows and the README documents eight of them as deprecated. Verify first that the checks you need are in the active table rather than the deprecated one, that your network can reach port 25 if you rely on the SMTP checks, or prepare the Tor or proxy path the README describes, and that you read the comment block above each function in src/mailcat/__init__.py, since those comments record which upstream change broke a check and how to revive it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. sharsil/mailcat on GitHub