Email protocols series. This is the tactical SMTP setup guide. For the conceptual overview of how SMTP, IMAP and POP3 fit together, read the email protocols hub →
Quick SMTP setup reference
SMTP (Simple Mail Transfer Protocol) is what your client uses to send mail. A working setup needs four things right: server hostname, port, authentication, and TLS mode. Get any one wrong and the connection fails or, worse, succeeds but leaves mail in plaintext on the wire.
| Modern default | Port 587 + STARTTLS + AUTH (LOGIN or OAuth2) |
| Legacy alternative | Port 465 + Implicit TLS + AUTH (still widely supported) |
| Never for clients | Port 25 is server-to-server only; ISPs and cloud providers block it from end-user IPs |
| 2FA accounts | App password or OAuth2, never your main account password |
| RFC reference | RFC 5321 (SMTP), RFC 6409 (Submission), RFC 8314 (TLS mandatory for submission) |
This guide focuses on the actual configuration: what to type into the server, port, username, and password fields of any client, plus the commands to test the connection from a terminal when something refuses to work. For context on what SMTP is conceptually and how it differs from IMAP and POP3, see our email protocols overview; this page picks up where that one ends.
Before you start: 4 things to confirm
Most failed SMTP setups fail at one of these four checkpoints rather than at the actual configuration. Verify before troubleshooting:
- Your sending domain is authenticated. SPF, DKIM, and DMARC published in DNS. Without them, even a perfect SMTP setup will land in spam. See our guides on SPF, DKIM, and DMARC.
- You have the right credentials. For 2FA-enabled accounts (Gmail, Microsoft 365, Yahoo, iCloud), the regular password will not work. You need either an app password or OAuth2 token. Generate those first; don’t paste your account password and hope.
- The port is not blocked. Home ISPs block outbound port 25; many cloud providers (AWS, GCP, Azure) block 25 by default and require a request to unblock. Ports 587 and 465 are almost always open. Test with
telnet smtp.example.com 587before fighting client configuration. - Your client supports TLS 1.2 or higher. All major mailbox providers dropped TLS 1.0 and 1.1 by 2023. Very old clients (legacy desktop apps, embedded scanners, ancient WordPress installs) silently fail with cryptic errors when negotiating TLS.
The 4 things every SMTP setup needs
| Setting | What it is | Common values |
|---|---|---|
| Server hostname | The SMTP submission endpoint of your mail provider | smtp.gmail.com, smtp-mail.outlook.com, smtp.office365.com, your-own-domain |
| Port | The TCP port to connect to | 587 (modern default), 465 (legacy with implicit TLS), 25 (server-to-server only) |
| Authentication | How you prove identity to the server | Username + password (LOGIN/PLAIN), app password, OAuth2 token |
| Encryption | How the connection is secured | STARTTLS (on 587), Implicit TLS / SSL (on 465), None (only on internal 25) |
Port selection: 587 vs 465 vs 25
The history matters. Port 25 was the original SMTP port for all email traffic. Over time, abuse and architectural changes split client-to-server submission from server-to-server relay. RFC 6409 standardized port 587 as the dedicated submission port; RFC 8314 (2018) made TLS mandatory for submission.
Port 587 (modern default)
Used for client-to-server submission. Connection starts in plaintext, then upgrades to TLS via STARTTLS. Authentication required. This is the right answer for almost any modern setup. Default for Gmail, Microsoft 365, Yahoo, iCloud, all major ESPs.
Port 465 (legacy with implicit TLS)
Originally deprecated, reinstated by RFC 8314 as a valid alternative. Connection is encrypted from the first byte (implicit TLS, no STARTTLS step). Authentication required. Useful for older clients that don’t implement STARTTLS correctly; many providers still expose it alongside 587.
Port 25 (server-to-server only)
For MTA-to-MTA relay between mail servers. Never use it from a client. Home ISPs block outbound 25 to prevent compromised machines from spamming. Cloud providers block it by default. If a setup guide tells you to use port 25 for sending from a client, the guide is wrong or 20 years old.
Decision rule: use 587 unless your client only supports 465. Avoid 25 from anything that isn’t a real mail server.
Authentication mechanisms
Four mechanisms in active use, listed from simplest to most secure:
- LOGIN / PLAIN. Username and password sent over the TLS-encrypted connection. Simple, universally supported, the default for most desktop and mobile clients. Works only if TLS is active; without TLS, credentials would travel in plain text or trivially-encoded base64.
- CRAM-MD5. Challenge-response that hashes the password rather than sending it. Largely obsolete now that TLS is mandatory: hashing over an encrypted channel adds little. Some older clients still default to it.
- App passwords. A 16-character credential generated in your account settings, used in place of your real password by clients that can’t do OAuth2. Generated when 2FA is enabled. Each app password is scoped to a single client and can be revoked individually. Required for Gmail, Microsoft 365, Yahoo, iCloud, and most providers when 2FA is on.
- OAuth2. The modern standard. You sign in via a browser window, the provider issues an access token, the client uses the token instead of a password. The token can be refreshed automatically and revoked centrally. Gmail, Microsoft 365, and Yahoo all support OAuth2 for SMTP. Apple has limited OAuth2 support.
Prefer OAuth2 where the client supports it. Fall back to app passwords for older clients. LOGIN with your real account password works only for legacy accounts without 2FA; treat that as a sign to enable 2FA, not a viable target setup.
TLS configuration
Three TLS modes are typically exposed by clients:
| Client label | What it means | Port |
|---|---|---|
| STARTTLS or “TLS” | Plaintext start, upgrade to TLS via STARTTLS command | 587 (or 25 internal) |
| SSL/TLS or “Implicit TLS” | TLS from the first byte, no upgrade | 465 |
| None | Plaintext throughout (do not use) | n/a for submission |
Client UIs are inconsistent. Outlook’s “SSL/TLS” usually means STARTTLS; Thunderbird’s “SSL/TLS” means Implicit TLS; Apple Mail asks for “Use SSL” without distinguishing. When in doubt, match the port: 587 always uses STARTTLS, 465 always uses Implicit TLS. If the client lets you set both port and encryption mode independently, those two values must align.
Setup walkthrough by client type
Desktop clients (Thunderbird, Apple Mail, Outlook desktop)
Add account → manual configuration → outgoing server. Set SMTP server hostname, port 587, STARTTLS, username (your full email address), and authentication password (app password if 2FA is enabled). Save and test by sending to yourself.
WordPress (WP Mail SMTP, FluentSMTP, Post SMTP)
Install the plugin, choose the provider (Gmail, SendGrid, Mailgun, generic SMTP). For generic: host = SMTP hostname, port 587, encryption STARTTLS, authentication on, username and password. For Gmail/Microsoft 365, prefer the dedicated mailer that handles OAuth2. After saving, the plugin sends a test email; check the result before going live.
Mobile (iOS Mail, Gmail Android)
iOS Mail: Settings → Mail → Accounts → Add → Other → Add Mail Account. Enter incoming and outgoing servers separately; outgoing = SMTP server, port 587, SSL on, username + password. Gmail Android: usually auto-configures for known providers; for custom domains, choose “Personal (IMAP)” and enter SMTP details manually.
Programmatic (PHPMailer, Nodemailer, Python smtplib)
PHPMailer example:
$mail->isSMTP();
$mail->Host = 'smtp.example.com';
$mail->SMTPAuth = true;
$mail->Username = 'user@example.com';
$mail->Password = 'app-password';
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
$mail->Port = 587;Nodemailer:
const transporter = nodemailer.createTransport({
host: 'smtp.example.com',
port: 587,
secure: false, // true for 465, false for 587
auth: { user: 'user@example.com', pass: 'app-password' }
});Provider-specific quick links
The hostname, port and auth requirements vary slightly per provider. Direct guides:
- Gmail SMTP settings (smtp.gmail.com, 587, app password or OAuth2)
- Outlook / Microsoft 365 SMTP settings (smtp-mail.outlook.com or smtp.office365.com, 587)
- Yahoo Mail SMTP settings (smtp.mail.yahoo.com, 587 or 465)
- iCloud SMTP settings (smtp.mail.me.com, 587, app password)
- Mailgun, SendGrid, Postmark, Amazon SES, Resend: each provides API + SMTP modes; SMTP credentials in the dashboard, port 587 standard
Testing your SMTP setup
Before debugging a client, test the SMTP connection from a terminal. Three useful commands:
OpenSSL (the gold standard)
openssl s_client -starttls smtp -connect smtp.example.com:587 -crlfShows the full TLS handshake, certificate chain, and lets you issue SMTP commands manually. If this works, the server is fine; the problem is in the client.
swaks (Swiss Army Knife for SMTP)
swaks --to test@example.com --from you@example.com \
--server smtp.example.com:587 --auth LOGIN \
--auth-user you@example.com --auth-password 'app-password' \
--tlsSends an actual test message and shows the full SMTP transcript. Best tool for diagnosing auth failures.
telnet (basic connectivity)
telnet smtp.example.com 587Just confirms the port is reachable and the server is responding. Useful when port blocking is suspected. Cannot test TLS or auth.
Diagnosing common SMTP errors
| Error | Likely cause | Fix |
|---|---|---|
535 5.7.8 Authentication failed | Wrong password, or 2FA enabled and main password used instead of app password | Generate app password, or switch to OAuth2 |
530 5.7.0 Must issue STARTTLS first | Server requires TLS, client tried plain auth | Enable STARTTLS in client settings |
550 Relay denied | Not authenticated, or authenticated user not authorized to send from this address | Check auth, check From-address matches authenticated identity |
| Connection refused on port 25 | Outbound port 25 blocked by ISP or cloud provider | Switch to 587 or 465; request 25 unblock from provider if mandatory |
| Connection timeout on 587 or 465 | Firewall blocking outbound, or wrong hostname | Test with telnet; verify hostname; check firewall rules |
certificate verify failed | Server cert expired, self-signed, or hostname mismatch | Update CA bundle on client; verify hostname; check certificate validity |
454 4.7.0 TLS not available | Server temporarily refusing TLS upgrade | Usually transient; retry after a few minutes |
421 Service not available | Server overloaded or rate-limiting your IP | Slow down send rate; check IP reputation |
10 common SMTP setup mistakes
- Pairing the wrong port with the wrong encryption mode. Port 465 + STARTTLS fails (465 expects implicit TLS); port 587 + Implicit TLS fails (587 expects STARTTLS).
- Using account password with 2FA enabled. Returns 535 Authentication failed. Generate an app password or switch to OAuth2.
- Sending from a server-side process on port 25. Home and cloud ISPs block 25 outbound. Use 587 or 465 with auth.
- Missing the full email address in the username. Some providers require
user@example.comas the username, not justuser. - Forgetting to enable IMAP/POP/SMTP access in the provider’s UI. Outlook.com, Microsoft 365, and Yahoo require explicit enablement before SMTP submission works.
- Hardcoded server hostnames that don’t match provider region. Some providers route by region (Gmail does not, but corporate Exchange often does); confirm the right hostname for your account’s region.
- Old TLS versions (1.0, 1.1) in the client. Major providers refuse TLS 1.0 and 1.1; update the client or the OS to support TLS 1.2 or higher.
- OAuth2 refresh token expired. Tokens expire (often after 6 months of inactivity); re-authenticate the client when sends suddenly stop working without a config change.
- Mismatched From and authenticated identity. Many providers reject mail where the From header doesn’t match the authenticated account. Use the authenticated address, or configure send-as identities in advance.
- No DKIM signing for outbound. SMTP works but mail lands in spam. Authentication is per-domain, not per-SMTP connection. See our DKIM guide.
SMTP setup FAQ
Should I use port 587 or 465 for SMTP today?
Port 587 is the modern default. It uses STARTTLS, is universally supported, and aligns with RFC 6409 and RFC 8314. Port 465 (implicit TLS) is still valid and supported by most providers; use it only if your client cannot do STARTTLS correctly. Never use port 25 from a client; it is reserved for server-to-server relay and blocked by most networks.
Why does port 25 fail from my home or cloud server?
Almost all residential ISPs and cloud providers (AWS, GCP, Azure, DigitalOcean) block outbound port 25 by default. The block exists to prevent compromised machines from spamming. Cloud providers will sometimes unblock 25 on request for legitimate mail server operations; home ISPs almost never will. For all client-side sending, use port 587 with authentication.
Do I need an app password or OAuth2 for SMTP?
If your account has two-factor authentication enabled, yes. Your regular account password will be rejected because the 2FA layer blocks basic authentication. Prefer OAuth2 where the client supports it (tokens refresh automatically, can be revoked centrally). Fall back to app passwords for older clients that only know username and password. Generate app passwords in the provider’s security settings.
Can multiple applications share the same SMTP credentials?
Technically yes, but it is bad practice. Each app should have its own credential (separate app password, separate OAuth2 client) so you can revoke one without breaking the others. Most providers also rate-limit per credential, so sharing one credential across many apps can throttle all of them when one misbehaves.
How do I test SMTP without actually sending a message?
Use openssl s_client -starttls smtp -connect host:587 to confirm the TLS handshake works, then issue EHLO, AUTH LOGIN, and MAIL FROM commands manually. The server responds at each step, so you can verify authentication and policy without sending an actual DATA message. Disconnect with QUIT before DATA and no message is sent.
What is the difference between traditional SMTP and a cloud SMTP API?
Traditional SMTP opens a TCP connection on port 587 and exchanges SMTP commands. Cloud SMTP APIs (Postmark, Mailgun, SendGrid, Resend) provide an HTTP/JSON endpoint as an alternative: you POST a JSON payload and get a response. Functionally equivalent (the provider’s MTA still sends via SMTP downstream), but HTTPS APIs are easier to integrate, more reliable behind restrictive firewalls, and provide richer telemetry. Both delivery models authenticate the same way to your domain via SPF/DKIM/DMARC.
Final words
SMTP setup is mostly memorization: port 587, STARTTLS, app password or OAuth2, full email as username. The points where it actually goes wrong are: 2FA-disabled accounts with stale credentials, port 25 used where it shouldn’t be, and TLS version mismatches on old clients. Knock those out and the rest is paste-the-config.
For broader context, see the email protocols overview, the companion IMAP configuration guide, our SSL/TLS for email guide, and the SMTP error codes reference when you hit a code you don’t recognize.
Clean your list before SMTP sends a single message.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
