Nearly 11 Million Submission Endpoints on Port 587: The Mail Path That Is Rarely Reviewed

A combined query for port 587 and the SMTP service fingerprint returned 10,990,138 records on 2026-09-26. Port 587 exists so that authenticated users can submit outbound mail, and that purpose is what makes it worth examining separately from inbound mail delivery.

Context and method

The count came from one autonomous query against the ZoomEye index.

• Query: port=587 && service="smtp"
• Sub type: all
• Result: 10,990,138 records
• Queried at: 2026-09-26T02:43:38Z
• Collection detail: page size 1, total field read only The interpretation carries the standard constraints. The service fingerprint is inferred from the response rather than confirmed from configuration. Reachability does not indicate whether authentication is required, and no attempt was made to test it. Honeypots and short lived hosts are included in the index, so the number is a snapshot.

What the data shows

RFC 6409 describes message submission as a distinct function with its own requirements, including an expectation that clients authenticate before mail is accepted for onward delivery. That requirement is why the port exists at all.
An exposure count of this size does not mean ten million open relays. It does mean that a very large number of endpoints accept submission connections from the public internet, and that the authentication control on each one is the only thing standing between a sender and the ability to originate mail from that domain.
Two matters follow. The first is credential exposure. Submission credentials are used by mail clients on laptops and phones, which places them on endpoints that may be less protected than a server. A credential captured from one client can be used to send mail that appears to come from the organisation, which is a reputation problem before it becomes a security incident.
The second concerns policy enforcement. Submission endpoints frequently apply authentication without applying the additional checks that a modern mail platform expects, such as per account sending limits or a record of what was sent. Where the submission service predates the current platform, the two controls can diverge.

Implications for defenders and next steps

• Query the port and service against your own ranges and reconcile the results with the submission endpoints your mail platform documentation describes.
• Confirm that authentication is required before any message is accepted, and that the service refuses cleartext authentication where a protected mechanism is available.
• Apply per account sending limits and log successfully submitted messages, so an unusual volume is visible.
• Review credentials that clients store, and require rotation where a client configuration file could be read by something other than the mail application. ZoomEye is a practical instrument for the reconciliation step, because organisations that have migrated mail platforms often leave submission endpoints answering for domains they no longer consider active.

References

• ZoomEye query for port=587 && service="smtp". https://www.zoomeye.ai/searchResult?q=cG9ydD01ODcgJiYgc2VydmljZT0ic210cCI%3D
• RFC 6409, Message Submission for Mail. https://www.rfc-editor.org/rfc/rfc6409
• RFC 3207, SMTP Service Extension for Secure SMTP over Transport Layer Security. https://www.rfc-editor.org/rfc/rfc3207
• RFC 8314, Cleartext Considered Obsolete: Use of TLS for Email. https://www.rfc-editor.org/rfc/rfc8314
• MITRE ATT&CK T1078, Valid Accounts. https://attack.mitre.org/techniques/T1078/