SMTP relay service: what it is and how cloud email delivery works

An SMTP relay service is cloud infrastructure that accepts outbound email from your application and delivers it to recipients on your behalf. You connect via SMTP credentials or an HTTP API, hand off the message, and the relay takes it from there: DNS lookups, TLS negotiation with the destination server, retry logic on temporary failures, bounce processing, and reputation management.

How it works technically

Your application connects to the relay on port 587 (SMTP with STARTTLS) or port 465 (implicit TLS) and authenticates with a username and API key. After the SMTP handshake, the message is queued on the relay's infrastructure. From there the relay:

1. Resolves the MX records for the recipient's domain.
2. Opens a connection to the destination MTA and negotiates TLS when available.
3. Transmits the message. If the destination server returns a 4xx temporary error, the relay retries according to its queue policy — typically exponential backoff over hours or days.
4. On a permanent 5xx rejection, generates a bounce event and updates suppression lists.
5. Tracks delivery events (delivered, opened, clicked, bounced, complained) and exposes them via webhooks or a dashboard.

The alternative is running your own MTA: Postfix, Exim, or Haraka. That gives full control, but also means ongoing work: IP warm-up, blocklist monitoring, feedback loop registration, DKIM key rotation, and queue tuning. For most teams, paying for a relay service is the better trade-off.

Main services on the market

The right relay depends on your workload. A quick breakdown of the main options:

• Amazon SES — the cheapest option at $0.10 per 1,000 emails, with deep AWS integration. Good fit if your stack already lives in AWS. The downside: the interface is bare-bones, and you have to build analytics yourself through CloudWatch and SNS. The sandbox restrictions on new accounts also add friction during setup.
• SendGrid — one of the largest relay services. Covers both transactional and marketing email in one platform. Webhook events are detailed: delivery, open, click, bounce, unsubscribe. Dedicated IP is available on paid plans.
• Postmark — focused entirely on transactional email. Cold outreach and bulk marketing are not allowed on shared IPs. That restriction is the point: it keeps the IP pools clean, which is why Postmark consistently delivers faster than most competitors.
• Mailgun — API-first, popular with developers. Flexible inbound routing, solid documentation, and a built-in email validation API that checks addresses before you send.

SMTP relay service vs. running your own MTA

Your own mail server gives you full control. It also means your team owns every problem: warming IPs, watching blocklists, registering with FBL programs, rotating DKIM keys, tuning queues. None of that is optional once you start sending at volume.

A relay service offloads all of that. You pay per volume and get ready-made infrastructure with an SLA. The trade-off: you depend on the service. If its IPs get blacklisted or the service goes down, your mail stops until the problem is resolved on their end.

Setting up authentication

Connecting to an SMTP relay requires adding DNS records to your domain:

• SPF — add the relay's include mechanism to your SPF record. For SendGrid: include:sendgrid.net.
• DKIM — publish a CNAME record pointing to the relay's DKIM key, or upload your own key.
• Custom Return-Path — configure a subdomain as the Envelope From so SPF alignment matches your Header From domain.

Without these records, messages may pass SPF and DKIM at the relay's domain level, but DMARC alignment on your own domain will fail. The practical result is spam folder placement even when the relay accepts and delivers the message.

Running your own relay server

Before cloud services took over, a relay was simply a mail server in the middle. It takes a message from one MTA, hands it to the next hop and keeps nothing in mailboxes. Companies still run their own for a few practical reasons. Many hosting providers block outbound port 25, so a server there can only send through an authenticated relay. A company with dozens of internal servers would rather push all outgoing mail through one gateway that holds the queue, signs with DKIM, scans for malware and keeps a single log. And if one internal box gets compromised, you cut it off at the relay instead of watching it burn the whole domain.

In Postfix and Sendmail this setup is called a smart host. Postfix needs one line, relayhost = [smtp-relay.example.com]:587, and from then on it stops doing its own MX lookups and passes everything to the relay.

The danger is the open relay. That is a server that forwards mail for anyone, and spammers scan for them so constantly that a fresh one gets found within hours. A relay should demand SMTP AUTH before it accepts a message and should talk TLS, either STARTTLS on port 587 or implicit TLS on 465, otherwise the login travels in clear text. Corporate relays usually add an allowlist of internal IP ranges on top. Whether your own server relays for strangers is one of the things the SMTP test checks.

Every relay on the path adds its own Received header. Read them bottom to top and you get the route of the message with timestamps, which is the quickest way to see where a delayed letter sat in a queue or which hop refused it.

Why you should validate your list before using a relay

Relay services handle bounces, but only after the fact. By then the message has already been sent, the IP has already received a rejection, and the sending quota has been used. A high bounce rate on a relay lowers the reputation of its IP pool, and on shared IPs that affects every other customer on the same pool. Some services suspend accounts when bounce rate exceeds 5%: Postmark does this, and Amazon SES does too once you leave the sandbox.