Definition
An SMTP relay is a server that accepts outbound email from your application and forwards it to the recipient mail servers on the open internet. SMTP itself is the protocol (Simple Mail Transfer Protocol, RFC 5321) that defines how mail servers talk to each other. A relay is the box in the middle that does the talking on your application's behalf. Every email API on the market sits on top of an SMTP relay layer somewhere, even if the API itself looks like REST.
Where SMTP relay fits in the stack
Picture the flow from "user clicked save" to "Gmail shows the message." Your application code calls a send function. That call hits either an SMTP relay (port 25, 587, or 465 with TLS) or a REST API endpoint that internally calls a relay. The relay queues the message, looks up the recipient domain's MX record, opens a TCP connection to that MX, negotiates TLS, runs the SMTP conversation (EHLO, MAIL FROM, RCPT TO, DATA), receives a 2xx, 4xx, or 5xx response, and either accepts the handoff, retries later, or returns the bounce to you.
This whole sequence used to happen inside your own infrastructure if you ran Postfix or Exim on your application server. Few teams do that anymore for a good reason: the operational tax is heavy. Maintaining IP reputation, handling bounces, dealing with rate limits from receiving servers, debugging why Outlook started rejecting your mail — all of it falls on whoever owns the relay. Most modern teams outsource the relay layer to a managed provider precisely so they do not have to think about MX lookups or TLS negotiation at 2 AM.
Managed SMTP relay vs your own
Running your own SMTP relay is technically simple. Postfix or Exim, a public IP, DNS records, and you can be sending in an afternoon. The hard part is what comes after. Your fresh IP has no reputation, so your first campaign mostly lands in spam. Your bounce-handling code does not exist yet, so soft bounces queue up indefinitely. You get a single ISP block and have no playbook for recovery. The operational work that managed providers do invisibly turns out to be most of the value.
Managed relays (SendGrid, Mailgun, Postmark, Amazon SES, us) give you the relay plus the operational layer: warm IP pools, bounce categorisation, suppression management, reputation monitoring, retry logic, webhook events on every state transition. The trade is convenience for control. You pay per send or per month. You do not have to think about reputation. The provider takes the operational tax.
The honest cutoff: if you send less than a few hundred emails per month and they are all internal, running your own relay (or even using Gmail SMTP) is fine. If you send anything customer-facing at any meaningful volume, the managed-relay decision pays for itself the first time something goes wrong. Calculating "we could save $50/month by running our own" looks attractive until your password resets start landing in spam.
REST API vs SMTP at the wire
Most modern email providers expose both an SMTP endpoint and a REST API. The REST API is easier to use, gives better error responses, supports modern features like idempotency keys and structured attachments more cleanly. The SMTP endpoint is universal and works with anything that knows how to speak SMTP — your CMS plugin, your mail forwarding, legacy applications that never learned REST.
Internally both routes converge. The REST call queues a message that the relay then sends via SMTP to the recipient's MX. The SMTP submission goes into the same queue. The provider's deliverability logic operates on the queue, not on which submission protocol fed it. From a deliverability standpoint, REST and SMTP are equivalent. From an integration standpoint, REST is easier for new code and SMTP is easier for plugging in existing systems that already speak it.
Common SMTP relay mistakes
Hard-coding port 25 in a managed-relay integration. Port 25 is for server-to-server traffic, blocked by most cloud providers' outbound firewalls. Use 587 (submission with STARTTLS) or 465 (implicit TLS) for application-to-relay traffic. The relay accepts both; your hosting provider often does not.
Treating the SMTP connection as long-lived. Each send is its own SMTP conversation, with EHLO and authentication. Some integrations try to "keep the connection open" and reuse it across sends; this works in the moment but causes weird state issues when the connection times out mid-batch. Per-message connection is the safer pattern.
Ignoring the 4xx vs 5xx response distinction. A 4xx response from the relay means "try again later" — soft failure, the relay will retry on a schedule. A 5xx response means "permanent failure" — do not retry, mark as bounced, the address is not deliverable for this reason. Treating them identically (retrying forever, or bouncing immediately) costs you either reputation or legitimate delivery.
Misconfigured SPF that does not include the relay's IPs. If you use a managed relay but your SPF record does not list the provider, your mail fails SPF, fails DMARC alignment, and gets quarantined. Always update your SPF record before pointing traffic at a new relay. Our deliverability check catches this misconfiguration immediately.
Related reading
- SPF — must include your relay's IPs.
- DKIM — the relay signs your messages with the keys you authorise.
- Transactional Email API — the REST-shaped wrapper around our SMTP relay.
- Email Deliverability — broader context. The relay is the mechanical layer; deliverability is the operational outcome.