/ Capability — SMTP relay
An SMTP relay service that explains itself — ports, TLS, authentication, and the honest relay-versus-API call.
Most relay providers show you a hostname and a signup button and hide everything underneath. We do the opposite: here is exactly how it works, which port to use, and when relay is the right choice versus an API. Available self-serve today or fully managed with dedicated IPs we operate.
/ Quick answer
An SMTP relay service accepts mail from your application over SMTP and takes responsibility for delivering it to the inbox. Connect to the relay host on port 587 (STARTTLS) or 465 (implicit TLS), authenticate with credentials, and send. The relay signs the message with DKIM, manages connections to the receivers, retries on temporary failures, and suppresses bounces. Email Delivery Platform offers relay in two tiers: self-serve for teams that want to integrate today on a shared or dedicated pool, and managed with dedicated IPs we warm and operate. Choose relay over an API when you want universal compatibility and minimal integration; choose an API when you need templates, per-message tracking, or batch substitutions.
-
Port 587
The recommended submission port with STARTTLS. Port 465 for implicit TLS is the supported alternative.
-
2 tiers
Self-serve relay on a shared or dedicated pool, or fully managed relay with dedicated IPs we operate.
-
DKIM signed
Every message is DKIM-signed with SPF and DMARC aligned — the authentication receivers check to trust your mail.
-
Relay or API
Relay for universal compatibility and minimal integration; API for templates, tracking, and batch substitutions.
/ 01 — How it works
What actually happens when your app sends through an SMTP relay?
The mechanics are simpler than the marketing makes them sound. Your application opens a TCP connection to the relay's hostname on a submission port. The two sides negotiate TLS so the session is encrypted. Your application authenticates with a username and password scoped to your account. Then it issues the standard SMTP commands — who the message is from, who it goes to, and the message body itself — and the relay accepts responsibility for the rest.
From that point, the work that decides whether your email reaches the inbox happens inside the relay, out of your application's sight. The relay signs the message with your DKIM key so receivers can verify it came from you. It looks up the recipient's mail servers, opens connections to them at a pace each receiver tolerates, and hands the message over. If a receiver asks it to slow down or try later, the relay queues the message and retries on a schedule. If a mailbox does not exist, the relay records a bounce and stops sending to that address.
Your application never sees any of this complexity. It made one connection, spoke one well-understood protocol, and got an acknowledgment that the message was accepted. That separation is the entire point of a relay: it moves the operational burden of delivery off your infrastructure and onto a system built to carry it. The protocol has barely changed in decades, which is exactly why it works everywhere.
/ 02 — Ports & TLS
The ports and TLS modes, with the current state spelled out.
The port question trips up more integrations than anything else, partly because the answer changed over the years and a lot of documentation is stale. Here is the current state, the way we would explain it to an engineer setting up their first send.
| Port | Use | TLS | Recommendation | Note |
|---|---|---|---|---|
| 587 | Authenticated submission | STARTTLS | Recommended default | The modern standard for application submission. Start plaintext, upgrade to TLS via STARTTLS, then authenticate. |
| 465 | Authenticated submission | Implicit TLS | Recommended alternative | Encrypted from the first byte. Reinstated as a standard after years of deprecation. Use when you prefer implicit TLS. |
| 2525 | Authenticated submission | STARTTLS | Fallback | Unofficial. Offered because some networks block 587. Use only when 587 is unavailable. |
| 25 | Server-to-server relay | STARTTLS | Rarely from apps | Blocked outbound by most clouds and ISPs to limit abuse. Appropriate for MX-to-MX, not application submission. |
A working configuration looks the same in almost every language and framework, because SMTP is universal. Here is the shape of it: a host, a port, TLS, and credentials.
# Typical relay configuration (any SMTP library)
host = "smtp.emaildeliveryplatform.com"
port = 587
encryption = "starttls" # or "tls" on 465
username = "your-account-credential"
password = "************"
require_tls = true # we reject plaintext auth
# That is the entire integration. Your framework's
# mailer config takes these five values and sends./ 03 — Relay vs API
When is SMTP relay the right choice, and when is an API better?
Both reach the same inbox. The choice is about integration effort against feature ceiling, and most providers will not tell you plainly because they would rather sell you the path with more lock-in. Here is the honest version.
| Factor | SMTP relay | HTTP API |
|---|---|---|
| Integration effort | Minimal — configure host, port, credentials | Higher — write provider-specific client code |
| Compatibility | Universal — every language and framework speaks SMTP | Provider-specific SDK or HTTP calls |
| Feature ceiling | Standard send, attachments, headers | Templates, per-message tracking, batch substitutions |
| Migration from self-hosted | Drop-in — point your existing config at us | Requires re-architecting the send path |
| Best for | Fast integration, legacy apps, universal sending | Rich features, high-control transactional flows |
Our practical advice: if you are integrating today and want mail flowing in an hour, start with relay. Every language has a mature SMTP library, your framework probably has a mailer that takes five config values, and a migration from a self-hosted server is close to a drop-in. Add the API later for the specific flows — a templated onboarding sequence, a high-volume batch with per-recipient data — where its extra features earn their integration cost. You do not have to choose one forever; both run against the same account.
/ 04 — Two tiers
Self-serve relay, or relay we operate for you.
The same SMTP endpoint, two operating models. The difference is who carries the deliverability work: you, on the self-serve tier, or our team, on the managed tier. Both send through the same infrastructure and reach the same inboxes; what changes is how much of the operational discipline lands on your plate versus ours. Most teams begin on self-serve and move to managed at the point where deliverability stops being a thing they can afford to watch themselves, which is usually a function of volume and how directly the mail ties to revenue.
Tier 1
Self-serve relay
Credentials in minutes. Send over a shared pool that benefits from aggregate reputation, or upgrade to dedicated IPs when your volume justifies it. Monthly billing tied to volume. You watch your own placement and we provide the dashboards and events to do it.
- → Shared or dedicated pool
- → DKIM, SPF, DMARC handled
- → Bounce and complaint webhooks
- → Self-serve dashboard and logs
Tier 2
Managed relay
Dedicated IPs we provision, warm on a schedule matched to your send curve, and operate. A named team watches reputation daily, holds postmaster contacts at the major receivers, and responds to deliverability incidents — often before you notice them. For senders whose mail cannot sit on a shared pool.
- → Dedicated IPs, engineered warming
- → Daily reputation monitoring
- → Same-day incident response
- → Direct postmaster escalation
/ 05 — Authentication
How does a relay keep your mail authenticated and trusted?
Two kinds of authentication run in parallel and people often confuse them. The first is the authentication between your application and the relay: your credentials over a TLS-encrypted submission port, which proves to us that the mail is yours to send. The second is the authentication between the relay and the receiving mailbox providers: DKIM, SPF, and DMARC, which prove to Gmail and the others that the mail genuinely originates from your domain and has not been tampered with.
The second kind is the one that decides deliverability, and it is the part a good relay handles so you do not have to think about it. Every message we send is signed with a DKIM key tied to your domain. We align SPF so the sending IP is authorized in your domain's published records, and we align DMARC so the receiver's policy check passes. These three together are what a modern mailbox provider inspects in the first milliseconds of receiving your mail, before it even looks at the content.
Beyond authentication, the relay protects your reputation through the operational work underneath: pacing connections so you never look like a flood, backing off when a receiver signals stress, suppressing addresses that bounce so you stop sending into dead mailboxes, and surfacing complaints so you can remove unhappy recipients. That operational discipline is invisible when it works, and it is the difference between a sender the receivers trust and one they start to filter. On the managed tier it is run by people; on the self-serve tier it is automated and exposed to you through the dashboard. Either way, it is the part of the service that justifies paying for a relay rather than pointing your application straight at the internet and hoping the receivers are forgiving.
/ 06 — Integration
Integration patterns across the stacks teams actually use.
Because SMTP is universal, the integration is the same shape everywhere: point your framework's mailer at our host, port, and credentials. The specifics differ only in where the configuration lives. Here is how that plays out across the platforms we see most often.
WordPress and PHP applications
WordPress sends mail through the PHP mail function by default, which is the single most common cause of deliverability problems on the platform. An SMTP plugin redirects that mail through the relay instead. You enter the host, port 587, your credentials, and STARTTLS, and every email WordPress generates — password resets, order confirmations, form notifications — now flows through authenticated infrastructure. Custom PHP applications use the same five values in their mailer library of choice.
Node.js with Nodemailer
Nodemailer is the standard mail library in the Node ecosystem and takes a transport object with host, port, secure flag, and auth credentials. Set secure to false with port 587 for STARTTLS, or true with port 465 for implicit TLS. The same transport works whether you send one message or thousands, and connection pooling is a single configuration flag when your volume grows.
Python with Django or standard library
Django reads SMTP settings from your configuration: host, port, TLS flag, user, and password. Once set, every call through the framework's mail functions routes through the relay. Applications outside Django use the standard library's smtplib, which speaks the protocol directly and needs only the same connection details and a starttls call before authenticating.
Ruby on Rails and Action Mailer
Action Mailer's delivery configuration takes an SMTP settings hash with address, port, authentication mode, and STARTTLS enabled. Rails applications usually have this in the environment config, so pointing a staging and a production environment at different credentials or pools is a one-line change per environment. The mail your application already sends needs no code changes, only the configuration.
/ 07 — Selection
What separates a relay worth paying for from a cheap one.
The market is full of relay services that look identical on a pricing page and behave very differently in production. The differences that matter are not the ones the marketing emphasizes. These are the criteria we would tell a friend to check.
TLS enforcement, not just TLS support
Many providers support TLS but still accept plaintext authentication if your client offers it, which means a misconfigured app can leak credentials. A relay worth paying for rejects plaintext auth on submission, so a configuration mistake fails loudly instead of quietly sending your password across the network in the clear.
A real path to dedicated IPs
Shared pools are fine until they are not. The question is whether your provider can move you to dedicated IPs with proper warming when your volume justifies it, or whether you will have to migrate to a different service entirely. A provider that offers both, on the same account, saves you a painful migration at exactly the moment your sending is growing fastest.
Bounce and complaint handling you can see
Suppression of bounced addresses and processing of complaints is table stakes, but the ability to receive those events in real time — via webhook into your own systems — is what lets you keep your list clean at the source. A relay that swallows bounce data and shows you only an aggregate number is hiding the information you need to protect your reputation.
A support model that matches your stakes
When a receiver starts deferring your mail, the gap between a ticket queue and an engineer who already holds postmaster contacts is measured in revenue. For low-stakes sending, self-serve support is fine. For mail your business depends on, the managed model — where someone is watching your reputation daily and can escalate directly — is the difference between a same-day fix and a multi-day outage.
Throughput that scales without throttling surprises
A relay that works fine for a thousand messages a day can quietly throttle you at a hundred thousand, and you will only discover the ceiling when a campaign stalls. The thing to check is whether the provider publishes its rate limits and offers a clear path to higher throughput, or whether you will hit an undocumented wall at the worst possible moment. Predictable throughput, with limits you can read before you commit, matters more than a headline send-rate number that applies only under ideal conditions. Ask what happens to your send rate during a traffic spike, not what it is on a quiet afternoon.
/ Common questions
What engineers ask about SMTP relay.
What is an SMTP relay service and how does it work?
An SMTP relay service is a third-party server that accepts mail from your application over the SMTP protocol and takes responsibility for delivering it to the recipient's mailbox provider. Your application connects to the relay's hostname on a submission port, authenticates with a username and password or an API key, and hands over the message. The relay then signs the message, manages connections to the receiving servers, handles retries and backoff, processes bounces, and works to land the message in the inbox. The value is that your application speaks one simple protocol to one endpoint and never has to know about the operational complexity of delivering to Gmail, Yahoo, Microsoft, and Apple.
Which SMTP port should I use, 25, 587, 465, or 2525?
Use 587 for authenticated submission with STARTTLS, which is the modern standard and what most providers recommend. Port 465 is for implicit TLS, where the connection is encrypted from the first byte, and it is fully supported again after years of being deprecated. Port 25 is for server-to-server relay and is blocked outbound by most cloud providers and residential ISPs, so it is rarely the right choice from an application. Port 2525 is an unofficial alternative to 587 that some providers offer because a few networks block 587; use it only if 587 is unavailable on your network.
Should I use SMTP relay or an HTTP API?
Use SMTP relay when you want universal compatibility, when your framework or platform already speaks SMTP, or when you are migrating from a self-hosted mail server and want to change as little as possible. Use an HTTP API when you want richer features like template management, detailed per-message tracking, or batch sending with per-recipient substitutions, and when you can afford to write provider-specific integration code. SMTP relay is the lowest-friction path to sending; an API is the higher-ceiling path. Many teams start with relay and add API calls for the specific flows that need the extra features.
Do I need dedicated IPs for SMTP relay, or is a shared pool fine?
A shared pool is fine when your volume is modest and your content is clean, because you benefit from the aggregate reputation of the pool without having to build your own. Dedicated IPs become worth it when your volume is high enough to warm and sustain them, when your deliverability cannot be exposed to the behavior of other senders in a shared pool, or when a receiver's reputation system rewards the consistency that a dedicated IP provides. Our self-serve tier defaults to a shared pool with dedicated IPs available as an upgrade; our managed tier is built around dedicated IPs we warm and operate for you.
How is authentication handled and is my connection encrypted?
Authentication is per-credential: you receive a username and password scoped to your account, and you can issue multiple credentials with different permissions for different applications. The connection is encrypted with TLS, either via STARTTLS on port 587 or implicit TLS on port 465. We require TLS on submission, so credentials never cross the network in the clear. On the delivery side, we sign every message with DKIM and align SPF and DMARC, which is the authentication that mailbox providers check to decide whether to trust the mail.
What happens when a message cannot be delivered immediately?
The relay queues it and retries on a schedule that respects the receiving server's signals. A temporary failure, like a receiver asking you to slow down, triggers a backoff and a later retry. A permanent failure, like an invalid mailbox, is recorded as a bounce and the address is suppressed so you do not keep sending to it. You receive bounce and complaint events via webhook or in the dashboard so your application can keep its own list clean. This retry and suppression logic is a large part of what you are paying a relay to handle, because doing it correctly is the difference between protecting your reputation and damaging it.
Relay is the easy part. Reaching the inbox is the work.
Get self-serve relay credentials and send within the hour, or book a review for the managed tier where we warm and operate dedicated IPs for you. We'll tell you honestly which one fits your sending.
Book infrastructure reviewRelated capabilities