Gmail SMTP Port: 465 or 587, and Why 25 Never Works
Every gmail smtp port question is really three questions wearing one coat: which number to type into a settings box, why the connection hangs instead of failing politely, and whether the choice affects deliverability. The short answers are 587, "because the wrong port fails by timeout rather than by message", and no. The longer answers below will save you the specific half hour that everyone loses to this at least once.
The three ports and what each really is
| Port | Protocol behavior | Verdict for smtp.gmail.com |
|---|---|---|
| 587 | Starts plaintext, upgrades via STARTTLS, then authenticates | The default choice |
| 465 | TLS from the first byte (implicit TLS), then authenticates | Equally valid, slightly simpler handshake |
| 25 | Server-to-server relay port, unauthenticated by tradition | Wrong for submission, blocked by most networks anyway |
587 and 465 reach the same Gmail service, accept the same app-password or OAuth credentials, enforce the same limits, and produce byte-identical delivery. There is no deliverability difference, no speed difference worth measuring, and no preference on Google's side between them. The genuine differences are historical and mechanical: 465 encrypts before any protocol talk, 587 negotiates encryption after an initial hello. Old libraries occasionally implement only one style properly, which is the only honest reason to switch.
You may also meet 2525 in other providers' documentation - an informal fallback submission port some services offer for networks that block the standard pair. Gmail does not listen on it at all: type 2525 next to smtp.gmail.com and you get the same dead-air timeout as a blocked port, because nothing is there to answer. It belongs to other platforms' playbooks, not Google's.
The mistake matrix: what each wrong pairing looks like
Port problems announce themselves through connection symptoms, and mismatched TLS settings each have a signature:
- 465 with "STARTTLS" configured: the client waits for a plaintext greeting that never comes, because Gmail is waiting for a TLS handshake. Symptom: hang, then timeout.
- 587 with "SSL/TLS" (implicit) configured: the client speaks TLS at a socket expecting plaintext hello. Symptom: immediate handshake failure or garbage-protocol errors.
- Correct port, encryption disabled: Gmail refuses to proceed to authentication. Symptom: an explicit server message about STARTTLS being required - the most helpful failure in the family.
- Port 25 from home or cloud: the packets die at the ISP or provider boundary before Google ever sees them. Symptom: pure timeout with no server banner at all.
The diagnostic rule: authentication errors (535-class) mean your port and TLS are fine and your credential is not. Timeouts and handshake noise mean the transport layer, which is where port choice lives.
Why port 25 deserves its bad reputation
25 is where mail servers talk to each other, and modern networks treat client machines dialing out on 25 as malware behavior until proven otherwise. Residential ISPs have blocked it for two decades; AWS, GCP and Azure all restrict or throttle outbound 25 by default; and Gmail's submission service was never meant to live there. Even when a path exists, nothing good waits at the end - submission with authentication is exactly what 587 and 465 are for. If a legacy appliance only speaks port 25, the sane pattern is pointing it at an internal relay that resubmits properly, not fighting three firewalls to reach Google directly.
Testing a gmail smtp port in ten seconds
Before touching application config, prove the transport from the machine that will send:
For 465: openssl s_client -connect smtp.gmail.com:465 - a certificate dump and a 220 smtp.gmail.com banner mean the path works.
For 587: openssl s_client -starttls smtp -connect smtp.gmail.com:587 - same success signals after the STARTTLS negotiation.
A hang on one port with success on the other convicts a firewall rule, not your code. Success on both moves the investigation up a layer to credentials, where the 535 family lives and where port choice is already exonerated. This two-command habit turns "email is broken" tickets into five-line diagnoses, and it works identically for any provider's submission host.
Setting it correctly in the places people actually set it
The label next to the port field varies by app, and the labels mislead more than the numbers:
- Fields offering "TLS" vs "SSL": TLS usually means STARTTLS (pair with 587); SSL usually means implicit (pair with 465). Usually - some apps invert the vocabulary, because the industry never agreed.
- Fields offering "STARTTLS" explicitly: pair with 587, always.
- Fields with a single "use encryption" checkbox: check it, use 587, and let the library negotiate.
- Nothing configurable but the number: try 587 first, 465 second; whichever connects cleanly is correct for that library's hardcoded style.
One settings block for the road - host smtp.gmail.com, port 587, STARTTLS on, full address as username, app password as password - covers the overwhelming majority of software written this decade.
When the port question is hiding a bigger one
If you are picking a Gmail port for an application that sends real volume - notifications, receipts, campaigns - the port is the least of the decisions being made implicitly. smtp.gmail.com binds the app to one mailbox's daily recipient allowance, one human's credential lifecycle, and one account's reputation. The port answer is 587; the architecture answer, once sending is a product feature rather than a convenience, is a relay or a dedicated sending platform where ports, credentials and limits are designed for machines in the first place.
For everything else - a client, a scanner, a small tool acting as you - 587 with STARTTLS, an app password, and the ten-second openssl test will outlive every settings-screen redesign Google ships.
Frequently asked questions
Which port should I use for Gmail SMTP?
Use 587 with STARTTLS as the default; 465 with implicit TLS is equally valid if your software prefers it. Both reach the same service with the same limits and identical deliverability - the choice is purely about which TLS style your library implements cleanly.
Is Gmail SMTP port 465 or 587 better?
Neither is better for delivery or speed. 465 encrypts from the first byte, 587 upgrades via STARTTLS; pick 587 by convention and switch to 465 only when a library handles implicit TLS more reliably.
Why does Gmail SMTP time out on port 25?
Because most ISPs and every major cloud block or throttle outbound port 25, and Gmail's submission service is designed for 587 and 465 anyway. A pure timeout with no banner means the network dropped the connection before Google saw it.
How do I test if a Gmail SMTP port is open?
From the sending machine, run openssl s_client -connect smtp.gmail.com:465, or add -starttls smtp with port 587. A 220 banner means the transport works; a hang means a firewall, and an authentication error later means the port was never the problem.