SMTP Ports in 2026: Choosing 587 vs 465 (and Why Port 25 Breaks WordPress Email)

Website email is one of those systems you only notice when it fails. A lead fills out a form and you never see it. A customer checks out and doesn’t get an order confirmation. Someone requests a password reset and assumes your site is broken. In practice, that failure isn’t just annoying-it directly damages trust and revenue.

In 2026, the underlying issue is usually the same: your site is sending mail in a way that inbox providers (Gmail, Outlook/Microsoft) interpret as suspicious. Fixing that requires using SMTP (Simple Mail Transfer Protocol) properly-and yes, picking the right SMTP port still matters.

Key takeaways (2026 defaults that work)

• Use Port 587 with STARTTLS for email submission. This is the modern, recommended standard for websites and email clients.
• Port 465 with SMTPS (implicit SSL/TLS) is also secure and widely used. If 587 fails (or your provider prefers 465), this is your best alternative.
• Avoid Port 25 for email submission. It’s unencrypted, meant for server-to-server relay, and is blocked by most ISPs and hosts specifically to reduce spam.
• The real deliverability issue is often WordPress’ default mail behavior: wp_mail() sends from the web server without proper authentication or sending reputation.
• The real fix is routing your site’s transactional email through a dedicated SMTP/transactional provider (SendGrid, Brevo, Mailgun, Postmark, Amazon SES, or Google Workspace/Gmail for low volume).
• If you want the lowest-friction option in WordPress, a zero-configuration routing plugin like Site Mailer by Elementor can bypass the default system without you configuring ports, DNS records, or API keys.
• Keep transactional and marketing email separate. Use SMTP/transactional delivery for receipts/resets/forms, and a dedicated ESP (Email Service Provider) like Mailchimp or ConvertKit for newsletters and promotions.

What SMTP is (and why your site needs it)

SMTP (Simple Mail Transfer Protocol) is the standard protocol email systems use to move messages around. A helpful mental model is thinking of SMTP as the internet’s post office workflow: your app hands a message to an outgoing server, that server relays it to the recipient’s server, and the recipient’s server stores it until the user checks their inbox.

In that workflow, SMTP covers two critical parts: (1) submission (your website or email client handing mail to an outgoing server) and (2) relay (server-to-server delivery). An SMTP port is simply the numbered network “door” used for that SMTP communication.

The WordPress wp_mail() deliverability trap

Out of the box, WordPress typically doesn’t submit email through a professional SMTP system. It uses the PHP mail mechanism via wp_mail(), which tries to send email from the web server itself. That works just often enough to be misleading-and fails often enough to be expensive.

The deliverability problems usually stack up fast:

• Your web server isn’t an email server. It’s designed to serve HTTP requests, not to manage mail delivery, queues, and reputation.
• Unauthenticated sending. The message effectively “claims” to be from your domain without the kind of authentication inbox providers expect.
• No sending reputation. Gmail/Microsoft maintain reputation signals for known mail infrastructure. A random web server has little to no positive reputation.
• Shared hosting IP risk. On shared hosting, your site may share an IP with hundreds of others. One spammy neighbor can get the IP reputation crushed or blacklisted-taking your legitimate email down with it.

The result is predictable: messages land in spam-or disappear entirely-without any visible error in your WordPress admin.

SMTP ports: the short history (and why some are basically obsolete)

SMTP port choices look like trivia until you understand why they exist. The evolution of SMTP ports is largely the story of the internet reacting to abuse and gradually standardizing secure submission.

Port 25: the original relay port (and the “spam highway” legacy)

Port 25 dates back to 1982 and was built for Mail Transfer Agent (MTA) to MTA relay. It was open by design-no authentication-and that openness became a gift to spammers.

Once spam became a large-scale problem, outbound connections on Port 25 were widely blocked by residential ISPs, many hosts, and many cloud providers. This is a practical anti-abuse measure: it stops infected machines and compromised servers from pushing spam directly to the wider internet.

Port 465: SMTPS (implicit TLS) that refused to die-in a good way

As encryption became non-negotiable, Port 465 emerged as a secure option using SMTPS (SMTP over SSL/TLS). With implicit TLS, the TLS handshake happens immediately upon connection, before any SMTP commands are exchanged.

Port 465 was widely adopted, briefly considered “deprecated” in favor of STARTTLS-based approaches, and then effectively returned as a mainstream standard. Many major providers (including Gmail) still recommend it, and it remains a secure, common choice for submission.

Port 587: the modern submission standard via STARTTLS (explicit TLS)

Port 587 is the IETF-designated port for email submission-exactly what your site is doing when it sends password resets or order confirmations. It typically uses STARTTLS, also called explicit TLS.

The sequence looks like this:

1. Your site connects to the SMTP server on Port 587 (initially plain text).
2. It sends EHLO to identify itself and request server capabilities.
3. The server responds with supported features, including STARTTLS.
4. Your client sends the STARTTLS command to upgrade the connection.
5. A TLS tunnel is negotiated, then authentication and email submission happen inside that encrypted channel.

In 2026, any submission endpoint on 587 that doesn’t enforce encryption is treated as insecure.

Port 2525: a non-standard but practical fallback

Port 2525 isn’t an “official” SMTP port, but many providers support it as an alternative when hosting environments block 587 and 465. It’s essentially a pragmatic escape hatch, typically using STARTTLS like 587.

The 2026 verdict: which SMTP port should you use?

Primary choice: Port 587 (STARTTLS)

Use Port 587 with STARTTLS for submission. It’s the modern default, broadly supported, and designed for client-to-server submission-the exact use case for websites.

Secondary choice: Port 465 (SMTPS / implicit TLS)

If 587 doesn’t work due to a local network rule or hosting restriction-or if your provider explicitly prefers it-Port 465 with SMTPS is an excellent secure alternative.

Almost never: Port 25

Port 25 is for server-to-server relay and is commonly blocked outbound. It’s not the port to configure in a WordPress SMTP plugin for submission.

SMTP port comparison (quick reference)

• 25 – Protocol: SMTP – Security: none – Common use: server-to-server relay – Recommended for your website: No (often blocked)
• 465 – Protocol: SMTPS – Security: implicit SSL/TLS – Common use: client-to-server submission – Recommended for your website: Yes
• 587 – Protocol: SMTP – Security: explicit TLS (STARTTLS) – Common use: client-to-server submission – Recommended for your website: Yes (preferred)
• 2525 – Protocol: SMTP – Security: explicit TLS (STARTTLS) – Common use: submission fallback – Recommended for your website: Only if 587/465 are blocked

Fixing WordPress email deliverability: step-by-step

Once you understand the port landscape, the implementation is straightforward: stop sending from the web server and submit mail through a trusted, authenticated transactional system.

Step 1: pick a dedicated transactional email provider

You need a provider that exists to deliver transactional email reliably. These services offer high-reputation sending infrastructure and support SMTP and/or API-based sending.

Common options include:

• SendGrid (popular, strong free tier)
• Brevo (formerly Sendinblue)
• Mailgun
• Postmark (known for high deliverability)
• Amazon SES (powerful, more complex)
• Google Workspace / Gmail (possible for low volume, but not recommended for business-critical sending due to limits)

Free tiers are often enough for small-to-medium sites, as long as you keep this channel transactional.

Step 2: configure DNS authentication (SPF and DKIM)

This is the most important technical piece. You must explicitly authorize your provider to send mail for your domain. Your provider will give you the exact DNS records to add.

• SPF (Sender Policy Framework): a TXT record that lists which servers are allowed to send mail for your domain. It helps prevent spoofing by telling receivers which sources are legitimate.
• DKIM (DomainKeys Identified Mail): a TXT record that publishes a public key. Your provider signs outgoing mail with a private key, and receivers verify the signature to ensure the message wasn’t altered.

Step 3: install and configure an SMTP plugin

In WordPress, the most practical approach is an SMTP plugin that intercepts wp_mail() and reroutes messages through your provider.

Common plugin choices:

• WP Mail SMTP
• FluentSMTP
• Post SMTP

Most plugins follow the same configuration pattern:

1. Install and activate the SMTP plugin.
2. Open its settings page in the WordPress dashboard.
3. Choose your mailer/provider (for example, SendGrid).
4. Add credentials.
5. If you’re using SMTP credentials (instead of an API), configure host/encryption/port/auth.
6. Set a From Email and From Name (the From Email should match your authenticated domain).

API vs SMTP credentials (what to prefer)

• Preferred: API keys. Many plugins recommend API-based sending because it’s typically more secure and reliable than storing mailbox credentials.
• Alternative: SMTP credentials. If you choose “Other SMTP,” you’ll manually set host, port, encryption, username, and password.

SMTP settings that matter (when configuring manually)

• SMTP Host: provided by your vendor (example: smtp.sendgrid.net or smtp.gmail.com).
• Encryption: select TLS (meaning STARTTLS) when using Port 587. If you use Port 465, you’ll typically choose SSL/SMTPS.
• SMTP Port: 587 for TLS/STARTTLS, 465 for SSL/SMTPS.
• Authentication: enabled (ON).
• SMTP Username / Password: issued by your provider.

Step 4: test delivery and check logs

Send a test email from your plugin’s built-in test tool to a personal Gmail or Outlook address.

• Arrives in inbox: you’re done-your site is submitting authenticated mail via a trusted channel.
• Arrives in spam: re-check SPF and DKIM and allow time for DNS propagation (often hours).
• Fails to send: treat it like a port/credential mismatch. Verify host/username/password, then try switching between 587/TLS and 465/SSL depending on what your provider supports and what your host allows.

The low-effort route: integrated solutions that remove port/DNS juggling

The manual approach above is routine for developers, but it’s still a multi-system setup: domain DNS, email provider, and WordPress configuration. That complexity is exactly why integrated “web platform” solutions have become popular.

Option 1: zero-configuration transactional routing

A zero-config approach focuses on the real pain: WordPress mail is unauthenticated and unreliable by default. Instead of making you configure a provider, keys, DNS records, and ports, the plugin abstracts it away.

Site Mailer by Elementor is designed around that idea:

• Install and activate-no additional setup flow.
• Automatically reroutes transactional email (forms, WooCommerce notifications, password resets) through an authenticated, high-deliverability service.
• No separate SendGrid signup, no API keys, no SPF/DKIM setup, and no port decisions.

Option 2: managed hosting that doesn’t fight SMTP best practices

Even with a great provider, you can still lose hours to host-level restrictions. Good managed hosting typically anticipates the wp_mail() problem and makes it easy to implement proper SMTP submission.

For example, Elementor Hosting is positioned as a managed cloud foundation focused on performance and operational reliability-including an environment where standard submission ports like 587 are available when you need them.

One rule that protects your reputation: transactional vs marketing email

Once your site’s delivery is fixed, the next common mistake is using the same channel for everything. Don’t.

Your SMTP/transactional provider account should be used for transactional email-messages users expect and that are triggered by an action.

• Transactional email (send via SMTP/transactional provider): password resets, order confirmations, form notifications, welcome emails, registration emails.
• Marketing email (send via an ESP): newsletters, promotions, announcements, seasonal campaigns.

If you blast a 10,000-recipient newsletter through the same channel that sends password resets, you invite unsubscribes and spam complaints. That can degrade your domain’s reputation, and then even critical transactional mail starts landing in spam. Keep marketing in platforms built for bulk sending and list management (like Mailchimp or ConvertKit).

A practical 2026 email strategy (what I’d implement on real projects)

A reliable setup typically has three layers:

1. A stable hosting foundation that doesn’t block common submission ports and supports modern security expectations.
2. A transactional email path that is authenticated and reputation-backed-either a zero-config solution like Site Mailer by Elementor or a configured SMTP plugin with a provider (starting with Port 587/STARTTLS).
3. A separate marketing channel (an ESP) for newsletters and promotions to protect the reputation of your transactional mail.

FAQ

1. What’s the simple answer-what SMTP port should I use?

Use Port 587 with STARTTLS. If that doesn’t work, use Port 465 with SMTPS (SSL/TLS).

2. Why shouldn’t I use Port 25?

Port 25 is the original unencrypted SMTP port (1982). It was heavily abused for spam, so outbound Port 25 is now blocked by most ISPs and many cloud/hosting providers. It’s not a reliable submission option for websites.

3. What’s the difference between Port 587 (STARTTLS) and Port 465 (SMTPS)?

Both are secure. Port 465 uses implicit TLS (encryption starts immediately). Port 587 uses explicit TLS via STARTTLS (connects first, then upgrades to an encrypted tunnel). Port 587 is the recommended modern submission standard, but both are widely used.

4. What is a transactional email?

It’s a one-to-one email triggered by a user action-contact form submissions, password resets, registrations, and eCommerce order confirmations. These should be sent through a dedicated transactional SMTP/email service.

5. How is transactional email different from marketing email?

Marketing email is one-to-many broadcasting (newsletters, promotions, announcements). Use a separate Email Service Provider (ESP) for marketing to avoid harming your domain’s sending reputation.

6. What are SPF and DKIM, and do I really need them?

Yes. They’re DNS records that help prove your mail is legitimate. SPF lists which servers are allowed to send mail for your domain. DKIM provides a cryptographic signature that receivers can verify to detect tampering. Without them, your mail is far more likely to be flagged as spam.

7. My SMTP plugin asks for a “Host.” What is that?

The host is your provider’s SMTP server address-for example smtp.sendgrid.net (SendGrid) or smtp.gmail.com (Google). Your provider documentation will specify the correct value.

8. Can I use my regular Gmail account for website email?

You can, but it’s generally a poor fit for business-critical mail. It can push you toward storing personal credentials in WordPress (a security concern), and Gmail enforces strict sending limits-traffic spikes can cause temporary blocks. A dedicated provider is a safer baseline.

9. What’s the easiest way to fix WordPress email deliverability?

A zero-configuration routing plugin such as Site Mailer by Elementor is the simplest approach: install, activate, and it routes transactional email through an authenticated, high-deliverability service without you configuring ports, API keys, or third-party accounts.

10. How do I test whether my SMTP setup works?

Use your SMTP plugin’s built-in “Test Email” tool and send to a Gmail/Outlook mailbox you control. Inbox placement usually indicates SPF/DKIM + routing are correct; failures point to host/port/encryption/credential mismatches.