SMTP Is Not Working On The Server

"SMTP is not working on the server" is a generic, application-level message — not a standard SMTP reply. Real SMTP replies are three-digit codes (421, 530, 535, 250) enumerated in RFC 5321 §4.2.2–4.2.3, optionally with an enhanced X.Y.Z status code from RFC 3463. Because this string carries no code, the only way forward is to reproduce the send and read the actual server response or socket error underneath it. The cause is nearly always one of three things below.

What causes "SMTP is not working on the server"?

Since the phrase is language- and code-agnostic, treat it as "my outbound send failed somewhere in connect → TLS → auth → send." The underlying culprit is usually:

• A blocked port (firewall/ISP/cloud egress). Outbound 25, 465, and 587 are commonly blocked. Notably, Amazon EC2 restricts (blocks) port 25 by default and many ISPs block it entirely to fight spam — you'll see a connection timeout, not an SMTP code.
• A TLS mode that doesn't match the port. Port 465 expects implicit TLS (TLS starts immediately); port 587 expects STARTTLS (plaintext connect, then upgrade). Pointing an implicit-TLS client at 587 (or vice-versa) hangs or throws a TLS handshake error. Both ports are valid and current per RFC 8314 — 465 is not deprecated.
• Rejected or missing credentials. The server actually answered, with 530 Authentication required (client never authenticated) or 535 Authentication Credentials Invalid (wrong user/pass). See the Amazon SES SMTP response code table for the canonical wording.

How do I fix "SMTP is not working on the server"?

Work from the network up — don't change credentials until you've proven the port is open.

1. Prove the port is reachable. Test the exact host/port before involving any mail library:

# Implicit TLS (port 465):
openssl s_client -connect smtp.example.com:465 -crlf

# STARTTLS (port 587):
openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf

If this hangs or refuses, the problem is a firewall, security group, or ISP block — not your code. On EC2, request removal of the port 25 restriction or switch to 465/587, which AWS does not restrict.

2. Match TLS mode to the port. In Nodemailer, secure: true means implicit TLS (use with 465) and secure: false means STARTTLS will be negotiated (use with 587):

// Port 465 — implicit TLS
nodemailer.createTransport({ host, port: 465, secure: true, auth });

// Port 587 — STARTTLS
nodemailer.createTransport({ host, port: 587, secure: false, auth });

Then call transporter.verify() to confirm the connection and login independently of any message.

3. Fix authentication the modern way. If you now get 530 or 535, the transport reached the server and the credentials were rejected. For personal Gmail accounts, username/password sign-in and "Less Secure Apps" were removed — you must use a 16-character App Password (requires 2-Step Verification) or OAuth 2.0. For Google Workspace accounts, App Passwords are not available at all — as of May 1, 2025, Workspace accounts must use OAuth 2.0. For providers like SES, SendGrid, or Mailgun, the SMTP username/password are provider-generated SMTP credentials, distinct from your console/API login.

4. If the send connects but mail still fails, read the actual reply code: 421 = service not available / channel closing per RFC 5321 (often a shutdown or timeout signal — retry with backoff), 454 = a common but non-RFC provider convention for throttling/quota (used by providers like AWS SES, not defined in the base spec), 550/554 = relay or unverified-sender rejection. These point to deliverability or quota issues rather than a broken SMTP setup.

If you route email through Courier, configure your SMTP provider's host, port, TLS mode, and credentials in the provider settings and use Courier's send logs to see the underlying SMTP response.