Port 587 (SMTP Submission) is the mail port clients use to submit outgoing email to a server, usually with authentication and encryption. If submission is misconfigured, attackers can relay spam or phish through compromised accounts, or steal credentials in transit. Enforce authentication, TLS, and rate limiting, and watch for abnormal sending volumes.
What Port 587 Represents in Mail Delivery
Port 587 is the standard submission port for clients sending outbound mail to a server. It is distinct from the legacy relay model because the server expects authenticated submission, usually before it will forward the message onward.
That distinction matters operationally: Port 587 is the handoff point where a user, app, or mail client proves it is allowed to submit mail, while the server performs policy checks such as authentication, encryption, and anti-abuse controls. For a quick reference to adjacent transport choices and common secure replacements for unsafe ports, see the Network Ports and Protocols Security Guide.
Why SMTP Submission Is Security-Sensitive
Submission is security-sensitive because it often carries the credentials, sessions, or tokens used to authenticate a sender. If the connection is not protected properly, an attacker can intercept secrets in transit, reuse them to send mail, or abuse a trusted mailbox or application account to distribute spam and phishing.
Port 587 also sits at a trust boundary between an endpoint and a mail service. A misconfigured submission service can become a relay path for abuse, especially when rate limits, authentication requirements, or sender validation are too weak. In mail infrastructure, the insecure handoff is often the real failure point, not the eventual delivery of the message.
How Organisations Validate Safe Use of Port 587
Validation starts with inventory: identify every mail client, application, scanner, workflow, or relay that submits through Port 587, then confirm whether each one uses authenticated submission over TLS. This is especially important where mail is generated by business applications rather than human users, because those systems often rely on embedded credentials and long-lived configuration.
Administrators should also confirm that the submission service is exposed only where needed and that server policy distinguishes authenticated submission from unauthenticated relay. For a protocol-level registry reference when checking port assignments or service definitions, use IANA.
Vendor documentation and mail gateway advisories remain the authoritative source for exact transport requirements, cipher policy, and submission behavior. Where submission is part of a broader infrastructure control set, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary for authentication, access control, logging, and secure configuration.
Detection, Abuse Signals, and Post-Incident Review
Monitoring Port 587 is as much about behavior as connectivity. Abnormal sending volume, repeated authentication failures, new geographies, unusual client fingerprints, or sudden spikes in denied submissions can indicate stolen credentials or scripted abuse.
After an incident, review which accounts, API credentials, or application secrets were able to submit mail, and whether those credentials were reused elsewhere. If an attacker obtained submission access, the investigation should extend beyond the mail server to mailbox access, inbox rules, and any downstream systems that trust mail-based workflows.
For attack-path thinking and credential abuse patterns, the MITRE ATT&CK Enterprise Matrix is useful for mapping how initial credential compromise can lead to persistence, lateral movement, and delivery abuse.
Risk and Threat Considerations
Port 587 becomes dangerous when submission is allowed without strong authentication, encryption, or abuse controls. The main risks are credential theft in transit, unauthorized mail relay, and compromise of trusted sender accounts that can be used for phishing, spam, or business-email abuse.
Failure mechanism: Weak submission policy, exposed credentials, or overpermissive relay behavior lets an attacker submit mail as a trusted sender and scale abuse quickly.
Impact: Organisations can face brand damage, account takeover, phishing distribution, deliverability loss, mailbox compromise, and incident response work across both mail and identity systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Port 587 submission depends on authenticating senders before mail relay. |
| IA-5 — Authenticator Management | Submission security depends on protecting and rotating mail credentials or secrets. | |
| AU-2 — Audit Events | Mail submission needs logging for abnormal volume and failed-authentication detection. | |
| Recommendation — Enforce authenticated submission before allowing mail relay. Manage and rotate submission credentials to reduce relay abuse risk. Log submission events and review anomalies for abuse indicators. | ||
| CIS Controls v8 | CIS-5 — Account Management | Submission accounts must be governed to limit misuse and overbroad access. |
| CIS-13 — Network Monitoring and Defense | Port 587 abuse is often visible through traffic and volume anomalies. | |
| Recommendation — Restrict and review mail-sending accounts to limit misuse. Monitor submission traffic for spikes, failures, and suspicious sender behavior. | ||
Practitioner Guidance
Why practitioners should care: Port 587 should be treated as a controlled access point, not just a network port. Its security depends on proving the sender, protecting the session, and constraining how much mail a trusted credential can send.
What to watch for: Prioritise misconfigurations where submission works without TLS, where basic authentication is reused broadly, or where automation accounts can send far beyond normal human-volume patterns. Those are the conditions most likely to turn a normal mail submission path into an abuse channel.
Practitioner takeaway: Harden submission as a privileged workflow, then monitor it like one, because a compromised mail submission path is often indistinguishable from legitimate sending until the volume or content pattern changes.