Identifying a Hornetsecurity mail gateway starts with the domain’s published MX, but the conclusion must stay narrower than “we know the customer’s security stack.”
Look at the inbound mail route first
An MX record tells other servers which host should receive mail for a domain. Hornetsecurity operates recognizable gateway hostnames, including patterns under hornetsecurity.com; specific routing endpoints must be validated against current vendor documentation or tested detector rules before building a commercial segment. Custom routing and acquired services may produce different hostnames.
dig +noall +answer MX example.com
Read the complete answer, not only the first hostname. Multiple MX records can implement redundancy. The numeric priority is mail delivery order, not a product version or customer tier.
Classify source evidence explicitly
Record the exact MX host, the domain queried and the observation timestamp. A directly recognized Hornetsecurity MX can be labeled as an observed inbound gateway. An SPF include mentioning Hornetsecurity belongs in a separate outbound-authorization category; it cannot alone prove the inbound delivery path.
Keep three states: observed, inferred, and unknown. Unknown is a valid output when a business routes through a custom gateway or an unrecognized hostname.
Understand what the record does not say
A detected gateway cannot reveal a client's Hornetsecurity license, configuration, tenant size, contract owner or renewal timing. MX also hides whether Microsoft 365, Google Workspace or another platform handles mail after filtering. Secondary Autodiscover, DKIM and identity signals can support a backend hypothesis but must not override contradicting evidence.
Reproduce the finding before outreach
Check the hostname yourself when preparing a high-value account. If you are working with a bulk dataset, review a sample of the detection rules and look for stale or partial migrations. A hostname changed yesterday might not match the one stored in your CRM last quarter.
| Finding | Safe classification | Inappropriate claim |
|---|---|---|
| Recognized Hornetsecurity MX | Hornetsecurity in visible inbound mail route | All security is provided by Hornetsecurity |
| Hornetsecurity-related SPF include | Outbound authorization reference | Inbound filtering confirmed |
| Gateway plus Microsoft secondary signals | Possible M365 backend | Every user has an M365 mailbox |
Translate this into an MSP workflow
Provider targeting helps teams offering gateway administration, email-security consolidation and migration. Use Find Leads to explore which provider filters are available in the SecuTest dataset or Scan Prospects to inspect known domains. Phrase outreach around your service, not an alleged weakness in the detected product.
Common classification mistakes
A domain may publish a vendor-related SPF include because it uses a sending service while routing inbound mail through another gateway. The correct output is two observations, not a forced Hornetsecurity inbound label. A gateway may also use regional or custom hostnames that your classifier has not yet recognized. In that case, do not manufacture a match from a similar-looking string.
When a hostname appears to identify Hornetsecurity, compare it against the latest verified detector signatures before turning it into a sales-list filter. Review domains with multiple MX destinations and note when the DNS answer was collected. In a high-value account, one manual check is cheaper than opening a sales conversation with the wrong vendor assumption.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.