SMTP relay failures are caused by authentication errors (wrong credentials or missing AUTH), blocked ports (ISP or VPS blocking port 25/587), misconfigured relay hostnames, TLS handshake failures, or rate limiting by the relay provider. Diagnose by testing the connection with telnet or openssl, checking credentials, verifying DNS, and reviewing relay provider logs.
SMTP Relay Issues: Troubleshooting Guide
Start With the Connection
SMTP relay problems fall into five categories. Work through them in order — the first failure you find is almost always the root cause.
1. Port Connectivity
Before checking anything else, verify you can reach the relay server.
# Test port 587 (standard submission)
telnet relay.example.com 587
# Test port 465 (implicit TLS)
openssl s_client -connect relay.example.com:465
# Test with STARTTLS on 587
openssl s_client -connect relay.example.com:587 -starttls smtp
If the connection times out: Your network or VPS provider is blocking the port. AWS blocks port 25 by default and sometimes 587. GCP blocks all outbound SMTP on port 25. Check your provider's firewall rules and security groups.
If you get "connection refused": The relay hostname or port is wrong. Double-check your relay provider's documentation for the correct server address.
2. Authentication Failures
The most common relay error. Symptoms include 535 Authentication failed, 530 Authentication required, or 550 Relay denied.
Wrong credentials: API keys change. Passwords expire. Verify your current credentials in the relay provider's dashboard.
AUTH before TLS: Most relays require STARTTLS before authentication. If your application sends AUTH on a plaintext connection, the relay rejects it.
Wrong AUTH mechanism: Relays support different mechanisms (LOGIN, PLAIN, CRAM-MD5). If your client uses one the server doesn't support, authentication silently fails. Check with EHLO — the server lists supported AUTH mechanisms in its response.
250-AUTH LOGIN PLAIN CRAM-MD5
3. DNS and Hostname Issues
Relay hostname doesn't resolve: Run dig relay.example.com or nslookup relay.example.com. If it returns NXDOMAIN, the hostname is wrong.
Reverse DNS missing: Some relay providers check that your sending server has a valid PTR record. Without it, the relay may reject your connection. Set up PTR records correctly.
MX records misconfigured: If you're relaying through your own infrastructure, ensure MX records point correctly and the relay server is authorized.
4. TLS Handshake Failures
Modern relays require TLS. Failures happen when:
- Certificate expired on the relay server (rare with major providers)
- TLS version mismatch — your client offers TLS 1.0 but the relay requires 1.2+
- SNI not sent — some relays need Server Name Indication to present the right certificate
Test explicitly:
openssl s_client -connect relay.example.com:587 -starttls smtp -tls1_2
If this works but your application fails, your application's TLS configuration needs updating. Learn more about TLS in email.
5. Rate Limiting and Sending Limits
Relay providers impose limits. When you hit them, you'll see 451 Too many connections or 452 Too many messages.
| Provider | Default Limit |
|---|---|
| SendGrid | 600 msgs/min on free tier |
| Mailgun | Varies by plan |
| Amazon SES | 1 msg/sec initially |
| Postmark | 500 msgs/batch |
Fix: Check your relay provider's current sending quota. If you're hitting limits, either upgrade your plan or implement queuing with backoff in your application.
Practitioner note: The #1 relay issue I see in consulting is agencies using the wrong SMTP port. They configure port 25 on a cloud VPS that blocks it, get zero error messages because the connection just times out, and assume the relay service is broken.
Practitioner note: When relay credentials stop working overnight with no changes on your end, check if the relay provider rotated API keys or if your account hit a billing issue. Suspended accounts return authentication errors, not billing messages.
Practitioner note: If you're relaying through Mailgun or SendGrid and emails work from your local machine but not your production server, the difference is almost always a firewall rule or security group on the production server blocking the outbound port.
Diagnosis Checklist
- Can you connect to the relay on the correct port? (telnet test)
- Does STARTTLS succeed? (openssl test)
- Does AUTH succeed with current credentials?
- Is your sending volume within plan limits?
- Does your server have valid reverse DNS?
If you've checked everything and relay issues persist, it may be an infrastructure architecture problem. Schedule a deliverability audit — I'll trace the full relay chain and identify the failure point.
Sources
- RFC 6409: Message Submission for Mail (Port 587)
- RFC 8314: Cleartext Considered Obsolete (TLS requirements)
- SendGrid: SMTP API Documentation
- Mailgun: SMTP Credentials and Ports
- AWS: Amazon SES SMTP Interface
v1.0 · April 2026
Frequently Asked Questions
Why is my SMTP relay not sending emails?
Check these in order: credentials are correct and the account is active, port 587 (or 465) is open on your network, the relay hostname resolves correctly, TLS is working, and you haven't hit the relay provider's sending limits. Test with: openssl s_client -connect relay.example.com:587 -starttls smtp.
What ports does SMTP relay use?
Port 587 (submission with STARTTLS) is standard for authenticated relay. Port 465 (implicit TLS) is the alternative. Port 25 is for server-to-server delivery, not relay submission. Many ISPs and cloud providers block port 25 outbound but leave 587 open.
How do I test if my SMTP relay is working?
Use openssl s_client -connect relay.example.com:587 -starttls smtp. After connecting, issue EHLO, AUTH LOGIN with base64-encoded credentials, then MAIL FROM, RCPT TO, DATA, and a test message. A 250 OK response confirms delivery to the relay.
Why does my relay return '550 Authentication required'?
Your application is connecting without sending AUTH credentials, or the credentials are wrong. Verify the username (often your full email or API key), password, and that AUTH is issued after STARTTLS. Some relays require the API key as the password with 'apikey' as the username.
Can my VPS provider block SMTP relay?
Yes. AWS, GCP, and Azure block port 25 by default. Some block 587 too. Check your provider's documentation and request port unblocking if needed. Alternatively, use a relay service on port 587 or 465 which is usually allowed.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.