An SMTP relay is a service (or server) that sits between your application and the recipient’s mail server. You hand it your outbound message over an authenticated connection, and it takes care of routing that message to the right destination through MTA-to-MTA delivery. The relay manages IP reputation, bounce handling, retries, and suppression lists on your behalf.
One-sentence definition worth bookmarking: An SMTP relay is an intermediate mail transfer agent that accepts authenticated outbound messages from your application and delivers them to recipient mail servers, handling reputation, queuing, and bounce processing so you don’t have to.
The most common reason teams reach for a relay is that cloud providers (AWS, Google Cloud, Azure) block outbound port 25 by default, which makes direct-to-recipient delivery impossible from a VM or container. Beyond the port issue, a relay gives you managed sending infrastructure without running your own mail stack.
For the protocol fundamentals (how SMTP handshakes work, what MX records do, the full port reference), see What Is SMTP? How Email Sending Actually Works. This post goes deeper on relay-specific mechanics.
What an SMTP Relay Actually Does
RFC 5321, the core SMTP specification, defines a relay as: “A ‘relay’ SMTP system… receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery.” (RFC 5321, §2.3.10)
In practice, when your application sends a message through a relay, here is what happens:
- Your code opens a TCP connection to the relay’s submission host (typically port 587 with STARTTLS, or port 465 with implicit TLS).
- You authenticate with a username and API key or password via SMTP AUTH.
- The relay accepts the message and queues it internally.
- The relay’s MTA looks up the recipient domain’s MX record and opens a direct SMTP connection to that receiving server.
- If delivery fails (temporary), the relay retries with exponential back-off. If it fails permanently, it generates a bounce notification and adds the address to a suppression list.
- Delivery events (sent, bounced, deferred) are logged and surfaced via a dashboard or webhook.
Your application never touches recipient mail servers directly. The relay handles all of that.
Open Relay vs. Authenticated Relay
This distinction matters for security, and it shows up in interviews, security audits, and deliverability troubleshooting.
Open relay: An SMTP server that forwards mail for anyone without requiring authentication. Open relays were common in the early internet and are now universally treated as a security liability. Because they forward unauthenticated traffic from any source, spammers exploit them to route bulk spam or phishing campaigns through a third party’s IP address. Most open relays end up on every major blocklist within hours of being discovered.
Authenticated (smarthost) relay: The relay requires SMTP AUTH before accepting any message. Only senders with valid credentials can submit mail. The relay enforces policies around rate limits, sender identity, and domain alignment. This is what every modern relay service (SendGrid, Postmark, Amazon SES, Mailgun) operates.
The term “smarthost” comes from Postfix and Exim configuration: setting relayhost or smarthost routes all outbound mail from a local MTA through a designated authenticated relay rather than delivering directly.
Why Cloud VMs Can’t Send Mail Directly on Port 25
Port 25 is the traditional MTA-to-MTA relay port. All three major cloud platforms restrict outbound port 25 by default, which means any code running on a VM or container that tries to open a raw SMTP connection to a recipient mail server will be silently dropped or refused.
| Cloud Provider | Port 25 Status | Official Recommendation |
|---|---|---|
| AWS EC2 | Blocked by default on all new accounts | Submit a request to lift the restriction, or use an SMTP relay on port 587 |
| Google Cloud Compute Engine | Blocked for external destinations | Use port 587 or 465; no restriction on those ports |
| Azure VMs | Blocked for most subscription types | Use an authenticated SMTP relay on port 587 |
AWS: “By default, Amazon EC2 throttles traffic on port 25 of all instances.” (AWS re:Post, EC2 Port 25 Throttle) You can request removal of the restriction for established senders, but the simpler path is routing through a relay on 587.
Google Cloud: “Connections to destination TCP Port 25 are blocked when the destination is external to your VPC network.” (Google Cloud Docs, Sending email from an instance) Port 587 and 465 are unrestricted.
Azure: “The Azure platform blocks outbound SMTP connections on TCP port 25 for deployed VMs” on most subscription types. Microsoft explicitly recommends using “authenticated SMTP relay services… typically on TCP port 587.” (Microsoft Learn, Troubleshoot Outbound SMTP Connectivity)
The practical upshot: if you are running on any cloud VM, you need a relay. Configure your mail client or application to use the relay’s hostname and port 587.
How to Configure an SMTP Relay
RFC 6409, which governs message submission, designates port 587 for authenticated submission and separates this role from the relay port 25: “Port 587 is reserved for email message submission as specified in this document.” (RFC 6409)
Here is what a relay configuration looks like in practice. Using SendGrid as an example (their relay host is smtp.sendgrid.net):
SMTP host: smtp.sendgrid.net
Port: 587 (STARTTLS)
Username: apikey
Password: <your SendGrid API key>
Encryption: STARTTLS(Twilio/SendGrid SMTP Integration Docs)
The pattern is the same across providers: a hostname, port 587 (or 465 for implicit TLS), and credential-based auth. The relay handles everything after that.
Configuring the relay in code
For Python, see How to Send Email in Python for a full smtplib example with STARTTLS. For Node.js, see How to Send Email in Node.js for a Nodemailer setup pointing to an SMTP relay host.
The relay host, port, and credentials typically come from environment variables, not hardcoded values.
SMTP Relay vs. Sending API
Modern email providers offer two integration paths. A relay uses the SMTP protocol; a sending API uses HTTP. Here is how they compare:
| SMTP Relay | HTTP Sending API | |
|---|---|---|
| Protocol | SMTP (port 587/465) | HTTPS (port 443) |
| Integration effort | Configure host, port, credentials | HTTP client + JSON payload |
| Works with existing apps | Yes (any app with SMTP support) | Requires code changes |
| Feedback | Async bounce/event webhooks | Synchronous HTTP response |
| Attachments | MIME in the message body | Base64-encoded in JSON |
| Latency | Slightly higher (SMTP handshake) | Lower (single HTTP call) |
| Best for | Legacy apps, CMS, existing software | Greenfield apps, microservices |
Twilio/SendGrid notes that the Web API has “fewer failure points” because SMTP’s conversational nature creates “multiple points of potential failure,” whereas an HTTP call is more direct. (Twilio, Web API or SMTP Relay)
That said, SMTP relay has a distinct advantage: almost every piece of software that can send email already has SMTP settings. If you are integrating with a CMS, an ERP, or a third-party plugin, the relay path requires zero code changes. You point the existing software at the relay hostname and it works.
For a full comparison of email sending options including sending APIs, see Email API: How to Send Email Programmatically.
When You Need a Relay (and When You Don’t)
You need a relay when:
- Your application runs on a cloud VM (AWS, GCP, Azure) and port 25 is blocked
- You want managed IP reputation without running a dedicated mail server
- You need suppression lists and bounce handling without building them yourself
- Your sending volume is significant enough that blocklist risk matters
- You use a CMS, ERP, or third-party app with SMTP settings but no HTTP API
You can skip a relay when:
- You are sending small volumes from a dedicated server with a clean IP and solid PTR record, SPF, DKIM, and DMARC alignment already configured
- You are already using an HTTP sending API (the relay is built into the provider’s infrastructure)
- You are sending only internal mail within a VPC
For most SaaS teams sending lifecycle, transactional, or outbound emails at any meaningful volume, a managed relay from a provider is the right default. Building and maintaining a self-hosted MTA with proper IP warming, blocklist monitoring, and feedback loop handling is a full-time problem.
Choosing a Relay Provider
The major options each have a different primary focus:
- SendGrid (Twilio): High-volume transactional and marketing, broad SDK support
- Postmark: Transactional-only, strong deliverability focus, fast delivery times
- Amazon SES: Very low cost at volume, tighter setup requirements (good for AWS-native stacks)
- Mailgun: Developer-focused, good inbound parsing support
- Brevo (formerly Sendinblue): Broader marketing + transactional in one platform
For a detailed comparison with pricing tiers and feature breakdowns, see Best Transactional Email Services Compared (2026).
Platforms like Coldletter offer both an SMTP relay path and an HTTP API with template and automation support, so teams can choose the integration style that fits their stack.
Troubleshooting Common SMTP Relay Errors
Most relay errors fall into three categories: authentication failures, connection failures, and policy rejections.
| Error | Meaning | What to Check |
|---|---|---|
535 Authentication failed | Credentials rejected | Username/password mismatch; API key expired or revoked; wrong auth method |
421 Service unavailable | Relay temporarily unreachable | Network/firewall blocking port 587; relay provider outage; rate limit hit |
550 5.7.1 Relaying denied | Relay won’t forward this message | Not authenticated; sending from an unverified domain; recipient domain blocked |
Connection timed out | Can’t reach relay host | ISP or cloud security group blocking port 587/465; wrong hostname |
530 Authentication required | Auth not sent before DATA | Client skipping EHLO/AUTH step; library misconfiguration |
Authentication failures (535): Verify the exact credentials your provider expects. SendGrid requires username apikey (the literal string) and the API key as the password. Other providers use email address as username. Check that the API key has the correct send permission and has not been rotated without updating the configuration.
Port blocked errors (421 / timeout): If you cannot reach port 587, try port 465 (implicit TLS). Confirm your cloud security group or firewall allows outbound connections on that port. Some corporate networks also block 587; in that case 465 is usually open, or you may need to route traffic through a proxy.
Relaying denied (550): This typically means the relay received an unauthenticated connection and refused to relay for a third party. Confirm your SMTP AUTH credentials are being sent before the DATA command. It can also mean the sending domain is not verified with the provider.
For deliverability issues beyond relay errors (reputation, authentication records, inbox placement), see Email Deliverability Best Practices.
Frequently Asked Questions
What is the difference between an SMTP server and an SMTP relay?
An SMTP server is any server that speaks the SMTP protocol; the term covers both mail transfer agents (MTAs) that relay messages between servers and mail delivery agents (MDAs) that put mail into a mailbox. An SMTP relay is a specific role: it accepts outbound mail from your application and forwards it toward the recipient, without being the final destination. All relays are SMTP servers, but not all SMTP servers are relays.
Why do cloud providers block port 25?
Cloud providers block outbound port 25 to prevent their IP ranges from being used for spam. Because port 25 is the traditional MTA-to-MTA relay port, an unblocked VM can send mail directly to any mail server in the world, making it an attractive target for spammers. AWS, Google Cloud, and Azure all restrict port 25 by default and recommend routing outbound mail through an authenticated relay on port 587 or 465.
What port should I use for an SMTP relay?
Port 587 with STARTTLS is the standard choice for authenticated message submission, as designated in RFC 6409. Port 465 (implicit TLS / SMTPS) is a widely supported alternative and is commonly used when port 587 is blocked. Avoid port 25 for relay submission from application code as it is blocked by most cloud providers and ISPs.
What is an open relay and why is it dangerous?
An open relay is an SMTP server that forwards mail for any sender without requiring authentication. Open relays are exploited by spammers to route bulk spam through a third-party IP address, which results in the relay’s IP being added to blocklists, damaging the domain’s sender reputation and affecting all legitimate mail from that server. Modern SMTP relay services require authenticated connections and enforce strict policies to prevent unauthorized use.
Can I use an SMTP relay with any programming language or framework?
Yes. Any language or framework that supports SMTP (Python’s smtplib, Node.js Nodemailer, PHP’s PHPMailer, Ruby’s Net::SMTP, Java’s JavaMail, Go’s net/smtp) can connect to an authenticated relay by setting the host, port, and credentials. CMS platforms like WordPress and Drupal also support SMTP relay via plugins without any custom code. The relay’s SMTP interface is protocol-standard, so the integration is language-agnostic.
When should I use an SMTP relay instead of an HTTP email API?
Use an SMTP relay when you are integrating with existing software that already has SMTP configuration settings (a CMS, ERP, or third-party application) and you cannot change the integration method. Use an HTTP email API when you are building from scratch, need lower latency, or want synchronous delivery feedback with HTTP status codes. Both paths end up at the same relay infrastructure on the provider side; the choice is about how your application talks to it.
I’ve spent my career building software at scale with a soft spot for email: deliverability, lifecycle campaigns, and getting messages to actually land. I started Coldletter to fix what bugged me about transactional and marketing email tools. I’m based in Vancouver.