Four ports, one right answer for most people. Here is what each one is for, why port 25 almost certainly will not work for you, and how to configure the rest correctly.
Use port 587.
For almost any application, script, or email client sending mail through an SMTP server, 587 with STARTTLS is the right choice. It's the official submission port. It's encrypted. It isn't blocked by ISPs.
The rest of this guide covers why the other ports exist, when they apply, and how to configure each one without tripping the usual wires.
| Port | Official name | Purpose | Encryption | Use it? |
|---|---|---|---|---|
| 25 | SMTP | Server-to-server relay | Opportunistic STARTTLS | Only between mail servers |
| 587 | Submission | Client to server | STARTTLS required | Yes — default choice |
| 465 | SMTPS | Client to server | Implicit TLS | Yes, if your library prefers it |
| 2525 | — | Unofficial fallback | STARTTLS | Only if 587 is blocked |
Port 25 is the original SMTP port, assigned in 1982. It's still the port mail servers use to talk to each other. When your provider's server delivers a message to Gmail's server, that conversation happens on port 25.
You almost certainly can't use it yourself.
Nearly every ISP, cloud provider, and hosting company blocks outbound port 25 by default. AWS, Google Cloud, Azure, DigitalOcean, and most Indian broadband providers all block it. This is a deliberate anti-spam measure. A compromised machine on a home network sending straight out on port 25 was historically one of the biggest sources of spam on the internet, so networks stopped letting it happen.
If your application times out on port 25, that's the reason. The answer is to use 587, not to file a ticket asking for 25 to be unblocked. Providers rarely unblock it. When they do, it comes with conditions.
Port 25 also has no authentication requirement in its original form. That's what made open relays such a mess in the 90s. A modern server on port 25 accepts mail for its own domains but refuses to relay mail from arbitrary senders.
Port 587 was defined in RFC 2476 in 1998. It's called the submission port. It exists specifically to separate two jobs that used to be muddled together on port 25: servers relaying mail to each other, and users submitting new mail.
That separation is the whole point. Because 587 is for submission, a server can require authentication on it without breaking server-to-server relay. Networks can leave it open without creating a spam vector.
How a port 587 connection works:
EHLOSTARTTLS among its capabilitiesSTARTTLS and the connection upgrades to encryptionThe connection starts unencrypted and upgrades. This is explicit TLS, sometimes called opportunistic TLS. A properly configured client must refuse to continue if the upgrade fails. Otherwise credentials could travel over the wire in plain text.
Port 465 has an odd history. It was assigned for SMTP over SSL in the late 90s. Formally deprecated in 1998 in favour of 587. Then reinstated in 2018 by RFC 8314 as a legitimate submission port.
The difference from 587 is implicit TLS. The connection is encrypted from the first byte. No plain-text phase. No STARTTLS upgrade step.
There's a reasonable case that implicit TLS is safer, since there's no unencrypted window at all and no possibility of a downgrade attack stripping the STARTTLS advertisement. Most modern libraries support both. If yours defaults to 465 with SSL, that's fine. It isn't a legacy mistake.
In practice, 587 and 465 are both correct. Use whichever your library handles more cleanly. We default to 587 in our own docs because most stacks are built around it, but if you're on a library that leans towards implicit TLS, there's no reason to fight it.
Port 2525 isn't registered with IANA for SMTP. It appears in no RFC. It exists purely by convention, because most email providers support it and most networks don't block it.
Its only real use case is when a restrictive network blocks 587 and 465. Some corporate firewalls do this. A handful of Indian ISPs on certain plans do too. If your application can't reach either standard port, 2525 is worth trying before you assume the service is down.
It carries no security disadvantage. It supports STARTTLS exactly as 587 does. It's just non-standard.
A working SMTP configuration needs six values:
Host: smtp.yourprovider.com
Port: 587
Encryption: STARTTLS
Username: your-smtp-username
Password: your-smtp-password
From: you@yourverifieddomain.com
Three things go wrong often.
Mixing the port and the encryption mode. Port 587 needs STARTTLS. Port 465 needs implicit SSL/TLS. Set 465 with STARTTLS, or 587 with implicit SSL, and you'll get a connection that either hangs or fails with a confusing error. Match them.
Sending from an unverified domain. Most providers reject mail from a domain you haven't proven you control. Add SPF and DKIM records to your DNS before you try to send anything.
Hardcoding credentials. SMTP passwords in source control are a standing embarrassment waiting to happen. Use environment variables. Use a secrets manager. Anything but the repo.
Python (smtplib), port 587:
import smtplib, ssl
from email.message import EmailMessage
msg = EmailMessage()
msg["From"] = "you@yourdomain.com"
msg["To"] = "customer@example.com"
msg["Subject"] = "Order confirmed"
msg.set_content("Thanks for your order.")
with smtplib.SMTP("smtp.yourprovider.com", 587) as server:
server.starttls(context=ssl.create_default_context())
server.login(USERNAME, PASSWORD)
server.send_message(msg)
Node.js (Nodemailer), port 587:
const transporter = nodemailer.createTransport({
host: "smtp.yourprovider.com",
port: 587,
secure: false, // false for 587 — STARTTLS is applied automatically
auth: { user: USERNAME, pass: PASSWORD }
});
Note the secure: false on port 587. It looks wrong. It isn't. Nodemailer's secure flag means implicit TLS, which is for 465. On 587 the connection still upgrades through STARTTLS. This one setting trips up almost everyone the first time they read the docs.
PHP (PHPMailer), port 587:
$mail->isSMTP();
$mail->Host = 'smtp.yourprovider.com';
$mail->SMTPAuth = true;
$mail->Username = USERNAME;
$mail->Password = PASSWORD;
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
$mail->Port = 587;
Before debugging your code, check that the network is letting the connection through in the first place.
Using telnet:
telnet smtp.yourprovider.com 587
Using OpenSSL (also verifies the certificate):
openssl s_client -starttls smtp -connect smtp.yourprovider.com:587
Using PowerShell on Windows:
Test-NetConnection smtp.yourprovider.com -Port 587
If port 587 connects and port 25 times out, your network is blocking 25. That's normal and expected.
| Symptom | Likely cause | Fix |
|---|---|---|
| Timeout on port 25 | ISP or cloud provider blocks it | Use 587 |
| Timeout on 587 and 465 | Restrictive firewall | Try 2525, or check egress rules |
535 Authentication failed | Wrong credentials | Verify username and password |
| Connection hangs on 465 | STARTTLS set instead of implicit TLS | Set encryption to SSL/TLS |
454 TLS not available | Server TLS misconfigured | Check certificate validity |
550 Relay access denied | Not authenticated | Enable SMTP auth |
| Mail sends but lands in spam | Port is fine — this is reputation | Set up SPF, DKIM, DMARC |
That last row matters most. Port problems stop mail from sending at all. If mail is sending successfully but landing in spam, the port isn't the issue. Reputation and authentication are.
Choosing the right port gets your message out of the door. It has no effect on whether the message reaches the inbox.
Inbox placement depends on the reputation of the sending IP, whether your domain passes SPF, DKIM and DMARC, how recipients engage with your mail, and how carefully you handle bounces and complaints.
This is where a hosted SMTP relay differs from running your own server. The port configuration looks identical. You point your application at a host on 587 with credentials, exactly as above. What changes is everything behind it: dedicated IPs with established reputation, automated warm-up, correct reverse DNS, feedback loop processing, and per-message logs so a failed send is diagnosable instead of a mystery.
neuMails runs that infrastructure in AWS Mumbai, so mail to Indian recipients stays inside the country. Billing is in INR with a GST invoice. The free tier includes 5,000 emails every month, no credit card.
If you want the background on the protocol itself, see our guide to the SMTP full form and how it works.
Historically port 25. For sending mail from an application or client today, the correct default is 587.
Either works. 587 uses STARTTLS. 465 uses implicit TLS. Use whichever your library supports more cleanly. 587 is the more common default.
Because unauthenticated direct sending on port 25 was a major spam vector for years. ISPs and cloud providers block it to stop compromised machines sending mail directly.
Yes. It supports STARTTLS exactly as 587 does. It's just not an official standard.
Technically yes. Practically no. Credentials and message content would travel in plain text, and most servers now refuse unencrypted authentication.
No. The port decides whether the connection succeeds. Inbox placement depends on authentication and IP reputation.
587 with STARTTLS, or 465 with SSL. Both are supported.
Dedicated IPs, India-hosted infrastructure, per-message logs. 5,000 emails free every month.
Start Free — No Card Needed