SMTP relay service: how to choose one

An SMTP relay service is a hosted mail server that accepts email from your application over SMTP and delivers it to your recipients' mail servers for you. You point your app, framework or device at the relay's host and port, log in with credentials, and the relay handles delivery, retries, bounces and the reputation of the sending IPs. Choose one on deliverability, how easily it authenticates your domain, logs and webhooks, limits and pricing, in roughly that order.

What an SMTP relay does

Sending email straight from your own server to Gmail or Outlook rarely works well. Cloud providers block outbound port 25, new IPs have no reputation, and you'd have to run a queue, handle retries and process bounces yourself.

A relay sits in between:

1. Your app connects to the relay on port 587 (or 465) and upgrades to TLS.
2. It logs in with SMTP AUTH using a username and password or API key.
3. It submits the message: sender, recipients, headers and body.
4. The relay queues it, signs it with DKIM, delivers it to each recipient's mail server, retries temporary failures, and reports bounces.

Message submission on port 587 is defined in RFC 6409. RFC 8314 recommends implicit TLS on port 465 for submission, but 587 with STARTTLS remains widely supported.

SMTP or an HTTP API?

Most transactional email providers offer both. They deliver the same way; what differs is how your code talks to them.

Use SMTP when:

• The software only speaks SMTP: an auth provider's custom SMTP settings, WordPress, a CMS, a printer or scanner, monitoring tools, a legacy app.
• Your framework already has an SMTP mailer (Django, Rails Action Mailer, Laravel, Nodemailer) and you want a configuration change, not a code change.
• You want to be able to switch providers by changing four settings.

Use an HTTP API when:

• You're writing new code. One authenticated POST per message is simpler than an SMTP session.
• You send from serverless functions or edge runtimes, where outbound SMTP may be blocked and connection setup eats into short time limits.
• You want structured responses: a message ID, a validation error naming the bad field, or which recipient was suppressed. SMTP gives you a reply code and a line of text.
• You want features that don't map to SMTP cleanly, such as templates, scheduling or batch sends.

Many teams use both: the API in their own code, SMTP for the third-party tools that need it.

What to compare

Deliverability and infrastructure

This is the point of using a relay. Ask:

• Does the provider run its own mail infrastructure and IP space, and how does it keep bad senders off the IPs you share?
• Is transactional mail separated from marketing or bulk mail? Sign-in codes shouldn't share IPs with newsletters.
• How are new accounts ramped up? A provider that lets anyone send a million messages on day one shares that risk with you.

You can test this yourself. Sign up, send a real message through the relay to the email spam test, and check the sending IP with the blocklist checker.

Shared or dedicated IPs

• Shared IPs spread volume across many senders, so the pool has steady traffic and an established reputation. Your reputation depends on the provider's vetting of the other senders.
• Dedicated IPs give you a reputation that's yours alone, good or bad. They need enough steady volume to stay warm, and a new dedicated IP has to be warmed up gradually.

For most apps sending under a few hundred thousand messages a month, a well-run shared pool is the better choice. Our guide to shared vs dedicated IPs goes deeper.

Domain authentication

Gmail, Yahoo and Outlook.com require SPF, DKIM and DMARC from bulk senders, aligned with your From domain (Google's sender guidelines). The relay should:

• sign every message with your domain's DKIM key (d=yourdomain.com), not its own
• support a custom return-path on your domain so SPF aligns too
• tell you exactly which records to publish, and check them

If a relay signs with its own domain, your mail fails DMARC alignment. Check after setup with the DMARC checker and a real test message.

Limits

Check per-day and per-month sending limits, connection and rate limits, maximum message size, and attachment limits. Also check how limits are reported: a good relay answers a temporary limit with a 4xx reply, so your mail server queues the message and retries instead of dropping it.

Logs, events and webhooks

When a user says "I never got the email", you need to look up that message and see whether it was delivered, bounced (with the receiving server's reply), or suppressed. Check for:

• searchable logs per message
• webhooks for delivered, bounced, complained and suppressed events
• automatic suppression of hard bounces and complaints

Pricing model

Most relays price by messages per month, with a free tier and overage per thousand. Compare what counts as a message (each recipient, or each send), whether features like logs retention, webhooks, inbound email or dedicated IPs cost extra, and what happens at the limit: hard stop or overage.

Support

When delivery breaks, you need someone who can read a bounce. Check how to reach support and whether it's engineers or a ticket queue.

Setting up an SMTP relay: example

Here's Groundmail's relay as a concrete example. The settings are:

First, add and verify your sending domain so mail is signed with your DKIM key. Then create a credential in the dashboard under SMTP, or with the API:

curl -X POST https://api.groundmail.dev/smtp-credentials \
  -H "Authorization: Bearer $GROUNDMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Production app"}'

The password is shown once, so store it in your secret manager. Then configure your mailer. With Nodemailer:

import nodemailer from "nodemailer";

const transport = nodemailer.createTransport({
  host: "smtp.groundmail.dev",
  port: 587,
  secure: false, // STARTTLS upgrades the connection after connecting
  auth: {
    user: "groundmail",
    pass: process.env.GROUNDMAIL_SMTP_PASSWORD,
  },
});

await transport.sendMail({
  from: "noreply@yourdomain.com",
  to: "user@example.com",
  subject: "Your receipt",
  text: "Thanks for your order.",
  html: "<p>Thanks for your order.</p>",
});

Or with Django's built-in SMTP backend, in settings.py:

import os

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp.groundmail.dev"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "groundmail"
EMAIL_HOST_PASSWORD = os.environ["GROUNDMAIL_SMTP_PASSWORD"]
DEFAULT_FROM_EMAIL = "noreply@yourdomain.com"

Send one message to yourself, then one to the spam test, and confirm SPF, DKIM and DMARC all pass.

How Groundmail helps

Groundmail's SMTP relay runs on our own mail infrastructure and uses the same domain verification, suppressions, limits and webhooks as the API, so a message sent over SMTP shows up in the same logs with the same events. Custom headers let SMTP clients use API features: X-Groundmail-Tag for tags, X-Groundmail-Idempotency-Key to make retries safe, and X-Groundmail-Scheduled-At to schedule. Transactional and product mail go out on separate IPs. The SMTP docs cover setup for Supabase, Nodemailer and others, and pricing starts with a free tier of 3,000 emails a month.