mailcow: 2 fingerprint matches against 67,430 title matches

A gap of this size is worth examining rather than reporting. Two queries about the same mail server suite returned 2 and 67,430, and the explanation says more about how fingerprint data works than about how many mail servers exist.

What the queries measured

Two queries were run against the ZoomEye index on 5 October 2026, scoped to all asset types.
Search query: app="mailcow". Result: 2 matching assets.
Comparison query: title="mailcow". Result: 67,430 matching assets.

Reading a gap of this size

The two queries are not measuring the same thing, and the smaller number is not an error.
An application fingerprint requires a response signature that matches a known pattern. When a product customises its front end, moves its login page, or serves only a redirect from the address that was crawled, the signature may not be present even though the software is running. mailcow's administrative interface is typically reachable on a hostname that the operator chooses, and a deployment can present a page that carries the product name in its title while presenting nothing that matches the fingerprint.
The title count has the opposite problem. A page title can contain the string because the deployment runs the product, and it can contain the string because a documentation page, a comparison article or a link directory mentions it. The figure is an upper bound on the population, not a count of running servers.
Taken together, the two figures bound the population rather than describe it. The true count of internet-reachable mailcow deployments sits somewhere between a signature that identifies almost nothing and a string match that identifies too much.

Why the mail layer needs its own count

Mail server suites hold credentials for the accounts they serve and the configuration for the domains they relay. A reachable administrative interface is therefore a higher-value exposure than its asset count suggests.
The count also has an operational use that is independent of its precision. An organisation that runs mailcow and finds it in neither figure should ask why, because a mail server that is not indexed by a crawler is either well protected or not exposed at all, and the two conditions require different follow-up.

What to do with a bound rather than a count

Use the fingerprint query to identify confirmed instances, because a positive match is stronger evidence than a title string. Treat the title query as a scoping query rather than a measurement.
For an inventory, the useful comparison is against the organisation's own mail domains and the hosts that answer for them. That list is short, and it is answerable without an internet-wide count.

The honest limitation

Neither figure states whether an instance is misconfigured, which version it runs, or whether the operator intended it to be reachable. A count that spans two orders of magnitude should be reported as a bound, and the reason for the spread should be stated alongside it.

References

[1] mailcow. https://mailcow.email/
[2] mailcow source repository. https://github.com/mailcow/mailcow-dockerized
[3] ZoomEye. https://www.zoomeye.ai/