Port 587 – SMTP Submission (Simple Mail Transfer Protocol)

Port 587 is the default port for SMTP mail submission — the port a mail client (Thunderbird, Apple Mail, Outlook) or an application uses to hand outgoing mail to its own server, authenticated with SMTP AUTH and encrypted with STARTTLS. Defined by RFC 6409 (Message Submission for Mail, originally RFC 2476), it exists specifically to separate submission — a user sending mail through their provider — from relay between servers on port 25. The defining detail that shapes every finding on an open 587 is explicit TLS: the connection opens in cleartext, the client reads the server’s EHLO capabilities, and only then issues STARTTLS to upgrade the socket. That plaintext-first handshake is what makes 587 both the modern submission standard and the member of the mail-sending family most exposed to downgrade.

That one design choice is the whole distinction between the three SMTP ports, and it is by far the most-searched question about 587:

So port 25 is server-to-server relay, port 465 is submission that is encrypted from the first byte, and 587 is submission that starts in the clear and negotiates TLS. Because that STARTTLS step is a runtime negotiation rather than a property of the socket, it can be tampered with — which is the security story of this port.

Why It’s Open

Port 587 is open on essentially every mail platform that accepts outbound mail from users. Google (Gmail), Microsoft 365, Yahoo, and virtually all ISP and hosting mail systems offer it, and after most ISPs and cloud providers (AWS, Google Cloud, Azure) blocked outbound port 25 from ordinary hosts to slow spam, 587 became the port clients, cron jobs, and PHPMailer/smtplib scripts are told to use for sending. On self-managed servers the daemon answering on 587 is usually Postfix (the submission service in master.cf), Exim, or Sendmail, or whatever a cPanel/Plesk/Zimbra/iRedMail stack installed. Where 587 answers, its relatives usually do too: check the relay and implicit-TLS submission siblings on 25 and 465, and the mailbox-retrieval pair on IMAPS 993 and POP3S 995.

Common Risks

• STARTTLS stripping (downgrade to cleartext). This is the signature weakness of port 587. Because the session begins in plaintext and TLS is only negotiated after the greeting, an active man-in-the-middle can simply delete the STARTTLS capability from the server’s EHLO reply. A client that doesn’t strictly require encryption then continues in cleartext and sends its AUTH LOGIN/AUTH PLAIN username and password in the open. Implicit TLS on 465 has no such step to strip, which is exactly why RFC 8314 prefers it — so on 587 the first thing to test is whether the server requires TLS before it will accept AUTH.
• STARTTLS plaintext command injection. A subtler cousin of stripping: if the server doesn’t discard data buffered before the TLS handshake, a MITM can pre-inject commands in the cleartext phase that the server then executes inside the encrypted session, as if the authenticated client had typed them (see CVE-2011-0411 below).
• Credential brute-force and password spraying. Once TLS is up, AUTH LOGIN/AUTH PLAIN is still a login prompt. Most submission servers don’t lock out or throttle failed logins, so hydra, medusa, and Metasploit grind username/password lists at will — and legacy SMTP AUTH frequently bypasses MFA, the same weakness that dogs legacy IMAP.
• User enumeration. VRFY, EXPN, and per-recipient RCPT TO responses can confirm which mailboxes exist before any login, building a target list for spraying here and against other services.
• Open relay and authentication bypass. A submission service that relays mail without valid authentication, or accepts spoofed senders, becomes a spam cannon and a sender-reputation disaster — classically a port 25 problem, but a misconfigured 587 listener can be abused the same way.
• A full MTA behind the port, and version disclosure. The daemon on 587 is a complete mail server — Postfix, Exim, or Sendmail — whose parser and delivery bugs (some remote, some pre-auth) are reachable wherever it accepts a message. And the greeting plus EHLO response usually name the software and version outright (220 mail.example.com ESMTP Postfix), handing you the exact CVE list to check.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service, grab the banner, and read the capabilities

nmap -sV -p 587 --script=smtp-commands,smtp-open-relay,smtp-enum-users,smtp-ntlm-info <target>

Open the cleartext session by hand and read EHLO

Port 587 starts in plaintext, so connect straight in and inspect what the server advertises before any TLS:

nc -nv <target> 587
EHLO attacker.test

In the 250- lines, check whether STARTTLS is offered, whether AUTH is advertised before STARTTLS (it shouldn’t be), and which mechanisms (LOGIN, PLAIN) are on offer. AUTH accepted on the cleartext side is a downgrade/credential-theft finding on its own.

Negotiate STARTTLS and inspect the certificate

Unlike 465 (implicit TLS), 587 uses the STARTTLS upgrade, so tell OpenSSL to speak it:

openssl s_client -starttls smtp -crlf -connect <target>:587
# once inside TLS:
EHLO tester
AUTH LOGIN

Test whether TLS is actually required before AUTH

Try to authenticate on the raw cleartext channel without issuing STARTTLS. If the server accepts AUTH LOGIN/AUTH PLAIN in the clear, it’s vulnerable to STARTTLS stripping — credentials are sniffable:

nc -nv <target> 587
EHLO attacker.test
AUTH LOGIN

Audit the negotiated protocols and ciphers (nmap does the STARTTLS itself)

nmap -p 587 --script=ssl-cert,ssl-enum-ciphers <target>

Enumerate users with VRFY / RCPT

smtp-user-enum -M RCPT -U users.txt -t <target> -p 587

Distinct replies for valid vs. invalid recipients (250 vs. 550) confirm a working user oracle.

Drive an authenticated submission with swaks (STARTTLS)

swaks --server <target>:587 --tls \
  --auth LOGIN --auth-user user@target --auth-password 'password' \
  --from user@target --to test@target

--tls forces the STARTTLS upgrade (the 587 way); --tls-on-connect is the implicit-TLS flag you’d use on 465 instead.

Brute-force AUTH with Hydra

hydra -L users.txt -P passwords.txt -s 587 <target> smtp

Metasploit modules

msfconsole -q
use auxiliary/scanner/smtp/smtp_version
set RHOSTS <target>
set RPORT 587
run

use auxiliary/scanner/smtp/smtp_enum
set RHOSTS <target>
set RPORT 587
run

Record every open port 587, the daemon banner, whether AUTH is allowed pre-STARTTLS, the negotiated TLS version and cipher, the certificate, any valid recipients, and any credential that works — so the evidence lands in the pentest report instead of a terminal you’ll close by mistake.

What to Look For

Known CVEs and Exploits

• CVE-2011-0411 — SMTP STARTTLS plaintext command injection, the classic port-587/submission flaw. The STARTTLS implementation (originally reported in Postfix 2.4.x–2.7.x, but the same class was found across many mail servers) doesn’t discard input buffered before the TLS handshake, so a man-in-the-middle can inject a cleartext command that the server executes inside the encrypted session — for example, capturing or replaying an authenticated client’s credentials. CVSS 6.8. It’s the reason STARTTLS must flush the pre-TLS buffer; the 2021 USENIX “NO STARTTLS” research showed the bug was still present in roughly 2% of internet mail servers (~320,000 hosts) a decade later. Detect it with the Nessus smtp_starttls_plaintext_injection check or by manually pipelining a command with STARTTLS.
• CVE-2019-15846 — Exim before 4.92.2 allows a remote attacker to execute arbitrary code as root via a crafted TLS SNI ending in a backslash-null sequence sent during the TLS handshake. Because it’s triggered by the handshake itself — which on 587 is the STARTTLS-negotiated TLS — any Exim that accepts TLS is exposed, regardless of whether it links OpenSSL or GnuTLS. Unauthenticated, CVSS 9.8. Note the corrected framing: this is a heap-overflow RCE, not a certificate-validation bypass. See the Exim advisory.
• CVE-2019-10149 (“The Return of the WIZard”) — Exim 4.87 through 4.91. Improper validation of the recipient address in deliver_message() allows command execution as root from a crafted RCPT TO. CVSS 9.8 and on CISA’s Known Exploited Vulnerabilities list. Port-scope honesty: this is an Exim MTA bug reachable wherever Exim accepts a message, and most exploitation targets inbound port 25 — but a submission listener on 587/465 is the very same vulnerable binary, so a 587 daemon fingerprinted as vulnerable Exim is in scope. Metasploit ships exploit/linux/smtp/exim4_string_format; archived on Exploit-DB.
• CVE-2020-28017 — Exim before 4.94.2 (one of Qualys’s “21Nails” set). An integer overflow leading to a heap buffer overflow in receive_add_recipient. CVSS 9.8. Same framing: an Exim-binary bug reachable on any listener the MTA runs, including submission on 587. Details in the 21Nails advisory.
• CVE-2020-28018 — Exim before 4.94.2 (also 21Nails). A use-after-free in smtp_reset that NVD notes is “common for builds with OpenSSL,” leading to remote code execution. CVSS 9.8. The OpenSSL/TLS connection makes it especially relevant to a TLS-terminating submission port. Corrected framing: this is a use-after-free, not a plain heap buffer overflow. Patch Exim to 4.94.2+ regardless of which port fingerprinted it.

Fingerprint the daemon first: a Postfix or Sendmail banner means the four Exim RCEs above don’t apply, and you should pivot to that server’s own advisory list instead of assuming a generic “SMTP” bug hits every mail port. The STARTTLS injection class (CVE-2011-0411), by contrast, is a protocol-handling flaw that has appeared across many implementations — test it on 587 regardless of the daemon.

Mitigation

• Require TLS before AUTH, and reject plaintext authentication. This is the core 587 defence: refuse AUTH on the cleartext channel so a stripped STARTTLS can’t harvest credentials. In Postfix set smtpd_tls_security_level = encrypt and smtpd_tls_auth_only = yes on the submission service; equivalents exist for Exim (auth_advertise_hosts gated on TLS) and Sendmail.
• Patch STARTTLS command injection. Keep the MTA current so the pre-TLS buffer is flushed on the STARTTLS transition (the CVE-2011-0411 class), and re-test with the smtp_starttls_plaintext_injection check after upgrading.
• Enforce modern TLS and a valid certificate. Disable SSLv3/TLS 1.0/1.1 and export/anonymous/RC4 ciphers on the listener, and deploy a CA-issued cert whose hostname matches so clients aren’t trained to click through warnings.
• Kill legacy basic auth and enforce MFA. Move clients to OAuth2/modern auth so a single stolen password can’t submit mail — the same fix that closed the legacy-IMAP MFA-bypass path.
• Rate-limit and monitor authentication. Put fail2ban or the daemon’s own limits on repeated AUTH failures and alert on spikes, so brute-force and spraying stall and surface.
• Disable open relay, VRFY, and EXPN. Accept mail only from authenticated submitters, reject relay for unauthenticated senders (smtpd_relay_restrictions), and set disable_vrfy_command = yes to close the user oracle.
• Standardise on 587 or 465, and firewall the port. Push clients to enforced-STARTTLS submission (587) or implicit TLS (465) instead of cleartext, and restrict 587 to the networks that genuinely need it.

Real-World Example

STARTTLS stripping is not a lab curiosity — it’s the reason RFC 8314 (2018) told the whole email industry to prefer implicit TLS. Because 587 opens in cleartext and only upgrades on request, an attacker positioned in the network path (a rogue Wi-Fi access point, a compromised router, an ISP-level meddler) can delete the single 250-STARTTLS line from the server’s greeting. A mail client that treats encryption as “opportunistic” rather than mandatory then never attempts TLS at all, and quietly sends its AUTH LOGIN username and base64-encoded password across the wire in the clear. The 2021 USENIX study “Why TLS is better without STARTTLS” turned this from theory into numbers: scanning the internet, the researchers found STARTTLS command-injection and stripping flaws in dozens of clients and servers, with the injection bug alone still live on roughly 320,000 mail servers — the very same class Postfix’s Wietse Venema had first disclosed as CVE-2011-0411 back in 2011. The lesson for port 587 is precise: the port is only as secure as the client’s insistence on TLS. If nothing forces the upgrade — on both ends — the “encrypted submission port” hands over credentials as readily as plain old cleartext SMTP.

FAQ

What is port 587 used for?

Port 587 is the default port for authenticated SMTP mail submission — the port a mail client or application uses to send outgoing mail through its own server, defined by RFC 6409. The session starts in cleartext, upgrades to TLS with the STARTTLS command, and requires SMTP AUTH. It’s the send-side counterpart to the mailbox-retrieval ports IMAP 993 and POP3 995.

What is the difference between port 587 and port 465?

Both are client-to-server submission ports and both end up encrypted — the difference is when. Port 465 uses implicit TLS: the connection is encrypted from the very first byte (SMTPS). Port 587 starts in cleartext and upgrades with STARTTLS. Because that upgrade is a negotiation, an active attacker can strip it and force plaintext, which is why RFC 8314 recommends implicit TLS on 465 as the preferred option. Functionally they do the same job; 587 with strictly enforced STARTTLS is secure, but 465 removes the downgrade risk by design.

What is the difference between port 587 and port 25?

Port 25 is server-to-server relay (one mail server delivering to another); port 587 is client submission (a user or app sending outgoing mail through their own server, authenticated). Most providers block outbound 25 to fight spam and require clients to send via 587 instead. See port 25 for the relay side.

Is port 587 secure?

It can be — if TLS is enforced. Port 587 with mandatory STARTTLS (the server refusing AUTH until the connection is encrypted) protects credentials in transit. The risk is that STARTTLS is optional at the protocol level: a server that advertises AUTH before TLS, or a client that treats encryption as opportunistic, is exposed to STARTTLS stripping and credential theft. Add brute-force with no lockout, legacy auth that bypasses MFA, and unpatched MTA bugs, and an open 587 still deserves a full review.

How do I secure or close port 587?

Require TLS before AUTH and reject cleartext authentication (smtpd_tls_security_level = encrypt, smtpd_tls_auth_only = yes in Postfix), patch the MTA against STARTTLS injection and the Exim RCEs, enforce TLS 1.2+ with a valid certificate, kill legacy basic auth in favour of OAuth2/MFA, rate-limit failed logins, and disable open relay and VRFY/EXPN. If nothing legitimately submits mail through the host, stop the submission service and firewall TCP/587, then rescan with nmap -p 587 <target> to confirm it’s closed.

TL;DR

• Service: SMTP message submission over STARTTLS with AUTH (RFC 6409)
• Default port: 587/TCP (vs implicit-TLS submission on 465, and server-to-server relay on 25)
• Biggest risk: STARTTLS stripping/downgrade to cleartext → credential theft, plus AUTH brute-force, user enumeration, and MTA CVEs
• Mitigation: require TLS before AUTH and reject plaintext auth, patch STARTTLS injection + the MTA, enforce TLS 1.2+ with a valid cert, kill legacy auth/enforce MFA, rate-limit logins, disable open relay and VRFY/EXPN