What it's for
Port 25 is the original and still-canonical port for SMTP (Simple Mail Transfer Protocol) — the protocol mail servers use to relay email between each other across the internet. When your mail provider sends an email to a recipient at a different domain, the actual server-to-server handoff almost always happens over port 25.
Where this trips people up: port 25 is specifically for server-to-server mail relay, not for a mail client (Outlook, Apple Mail, Thunderbird) sending mail on behalf of a user — that's what ports 587 and 465 exist for. Confusing these three ports is one of the most common email configuration mistakes developers make.
Protocol basics
- Protocol: TCP, for reliable delivery of what can be a large, multi-part message.
- Store-and-forward relay model. SMTP doesn't require a direct connection between sender and final recipient — a message can hop through multiple relaying servers (MTAs) before reaching its destination mailbox.
- Plaintext by default, STARTTLS as an upgrade. Classic port 25 SMTP starts unencrypted, with an optional
STARTTLScommand that upgrades the connection to TLS mid-session if both sides support it. - No built-in sender verification. SMTP as originally designed doesn't verify that the claimed sender address is legitimate — this is the root cause of email spoofing, and why SPF, DKIM, and DMARC exist as bolt-on verification layers.
Security considerations
- Most cloud providers block outbound port 25 by default (AWS, GCP, Azure, DigitalOcean, etc.) specifically to curb spam from compromised or careless instances — if your app needs to send transactional email, you typically need to either request an unblock or, far more commonly, use an authenticated relay like AWS SES over port 587 instead.
- Open relays are a serious misconfiguration. An SMTP server that accepts and forwards mail from any sender to any recipient without authentication will be discovered and abused by spammers within hours, and will get the server's IP blacklisted.
- SPF, DKIM, and DMARC records are DNS-level configurations (not port-level) that let receiving servers verify a message claiming to be from your domain actually originated from an authorized sender — essential for deliverability, separate from the port itself.
- Port 25 traffic should be authenticated or restricted to known relay partners; it should never accept arbitrary unauthenticated mail submission from the open internet on a server you control.
Troubleshooting
Emails aren't sending from a cloud server (AWS EC2, etc.):
- Almost always outbound port 25 being blocked by the cloud provider by default — this is a provider-level policy, not something you fix in your app. Use an authenticated relay on port 587 instead, or request an unblock through your provider's support process
"Relay access denied":
- The receiving/relaying server doesn't recognize you as an authorized sender — you likely need to authenticate (which port 25 alone doesn't require, unlike 587) or use your actual outbound mail provider's relay
Mail sent successfully but landing in spam:
- This is a deliverability issue (missing/misconfigured SPF, DKIM, or DMARC records), not a port 25 connectivity problem
Connection times out on port 25:
- Either the destination server's port 25 isn't reachable (rare for real mail servers), or more likely, your own outbound port 25 is blocked by your hosting provider
Comparison / FAQ
| Port | Protocol | Key difference from 25 (SMTP relay) |
|---|---|---|
| 587 (SMTP submission) | TCP | For authenticated mail submission from a client/app to its outbound mail server — the correct port for sending transactional email |
| 465 (SMTPS) | TCP | Same submission use case as 587, but with implicit TLS from the start of the connection rather than STARTTLS |
| 143 (IMAP) | TCP | Retrieving mail from a mailbox, the opposite direction of SMTP's sending role |
Why can't I send email directly from my app over port 25?
Nearly every cloud provider blocks outbound port 25 by default to prevent spam from compromised instances. The standard fix is to send through an authenticated relay service (like AWS SES, SendGrid, or Postmark) over port 587, not to fight the port 25 block directly.
What's the actual difference between ports 25, 587, and 465?
25 is for server-to-server mail relay across the internet. 587 is for a client or application submitting mail to its own outbound server, with authentication required and STARTTLS for encryption. 465 does the same job as 587 but wraps the connection in TLS immediately rather than upgrading mid-session.
Do I need to open port 25 to receive email on my own domain?
Yes — if you're running your own mail server (an MX destination), it needs to accept inbound connections on port 25 from other servers relaying mail to you. This is separate from outbound sending, which is where the cloud-provider blocking typically applies.
Why does SMTP allow sender addresses to be spoofed?
Because the original protocol didn't include sender verification — anyone can claim any "From" address in the SMTP conversation itself. SPF, DKIM, and DMARC were added later as DNS-based mechanisms to let receiving servers verify legitimacy, precisely because the port-level protocol doesn't handle it.