Email Relays Explained: Open Relay vs Smart Host vs SMTP Relay

The word "relay" gets used loosely in email. Sometimes it means an open relay (bad). Sometimes it means an authenticated SMTP service like SendGrid (good). Sometimes it means a smart host inside a corporate network. Different concepts, related mechanics. This page defines each, explains when you'd use them, and covers the security implications.

If you're building an app and someone says "use a relay," they almost always mean an authenticated SMTP relay service.

The three relay patterns

Pattern	Authentication	Used by	Risk
Open relay	None	Spammers	Universally blocklisted
Authenticated SMTP relay	Username + password or API key	Apps, businesses sending email	Low
Smart host	IP or credential-based	Internal mail servers	Low

Open relay (don't run one)

An open relay accepts mail from anyone, signed in or not, and forwards it to any destination. In the early internet this was the default — Sendmail shipped configured to relay anything. Spammers discovered this in the late 1990s and started routing massive volumes through unsecured servers, which led to blocklists like Spamhaus SBL and the original SPEWS targeting open relays specifically.

In 2026, an open relay will be on multiple blocklists within hours of going live. Don't run one — even accidentally. When configuring Postfix or any MTA, the default is correctly closed.

# Postfix - relay only authenticated mail from this network
mynetworks = 127.0.0.1
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

If you're testing a Postfix install, verify it's not an open relay with swaks --to [email protected] --from [email protected] --server yourserver:25. A locked-down server returns "Relay access denied."

Authenticated SMTP relay services

This is what most people mean by "SMTP relay" in 2026. You authenticate to an external service (SendGrid, Mailgun, AWS SES, Postmark, Mailjet, Brevo, etc.) and they handle delivery on your behalf.

Why apps use them:

1. Port 25 blocked outbound. AWS, GCP, DigitalOcean, and most consumer ISPs block outbound port 25 by default to prevent abuse. You can't run your own MTA on these hosts without filing a request and providing justification (and AWS won't unblock at all in most cases).
2. IP reputation included. The relay's IPs are pre-warmed and managed.
3. Authentication handled. They manage SPF, DKIM, and DMARC alignment for you with their domains.
4. Bounce and complaint handling. They process bounces and feedback loops centrally.
5. Analytics and logging. Built-in.

Typical pricing: $15-50/month for 50k messages, scaling up from there.

For reviews of the major options: SendGrid, Mailgun, Postmark, Resend, AWS SES.

Smart host (internal relay pattern)

A smart host is an upstream server that handles outbound mail for one or more servers behind it. Common patterns:

Corporate setup:

Workstations → Internal Postfix smart host → SendGrid/Mailgun → Internet

Small office:

Office mail server → ISP smart host (e.g., smtp.comcast.net) → Internet

Multi-app:

App 1, App 2, App 3 → Internal relay → SES → Internet

Smart hosts centralize authentication, give you one place to enforce TLS, simplify firewall rules, and make outbound IP management consistent. For a 10-server environment, the cost of running one Postfix smart host is dramatically lower than configuring 10 individual SMTP integrations.

# Postfix as a smart host relaying through SendGrid
relayhost = [smtp.sendgrid.net]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes

Practitioner note: Smart hosts are the right pattern when you have multiple internal services sending mail. I've cleaned up environments where 8 different apps each had their own SendGrid API key, each with different from-domains and inconsistent DKIM. Consolidating through one Postfix smart host with SendGrid as the upstream gave the ops team one place to manage everything.

Authenticated relay vs ESP API

Most major email providers expose two interfaces:

1. SMTP relay — submit via standard SMTP on port 587
2. HTTP API — submit via JSON payload

Interface	Best for	Pros	Cons
SMTP relay	Legacy apps, smart hosts	Universal, works with any tool that speaks SMTP	Slower per-message, harder to debug
HTTP API	New code, high volume	Faster, structured errors, better metadata support	Provider-specific

For greenfield code, HTTP APIs are usually better. For migrating an existing app that already speaks SMTP or for a smart-host pattern, SMTP relay is simpler.

Setting up an authenticated SMTP relay (SendGrid example)

SMTP server:    smtp.sendgrid.net
Port:           587 (or 465 for implicit TLS)
Username:       apikey (literal string)
Password:       <your API key>
TLS:            Required
Authentication: SASL PLAIN or LOGIN

Most ESPs follow this same pattern with their own hostnames.

For setting up authentication on the sending side, see the SPF setup guide and the DKIM setup guide. You need to publish DNS records that align with the relay service's signing domain to get DMARC alignment.

Common relay mistakes

1. Hardcoded relay credentials in app config. Use environment variables and rotate.
2. No fallback relay. If your primary ESP goes down, mail backs up. Configure a backup relay.
3. No bounce processing. The relay tells you which messages bounced; you need to actually process those events and update your list.
4. Misaligned DKIM. Your relay signs with mailer-domain.com, your From is yourdomain.com. DMARC fails. Set up a custom signing domain.
5. Sending cold email through a transactional relay. SendGrid and Postmark will suspend you. Use a relay configured for the use case.

Practitioner note: AWS SES is the cheapest relay by per-message cost ($0.10 per 1k) but the most operationally demanding. You're responsible for bounce/complaint handling, reputation management, and IP warmup. For most teams, paying SendGrid or Postmark 3-5x more is worth it for the abstraction.

If you're setting up an SMTP relay for an app or consolidating multiple senders through a smart host, book a consultation. I do email infrastructure architecture for SaaS teams and agencies running multi-app sending environments.

Sources

• RFC 5321 — SMTP — IETF
• RFC 6409 — Message Submission — IETF
• Postfix smart host configuration — Postfix
• SendGrid SMTP integration — Twilio SendGrid
• Spamhaus on open relays — Spamhaus

---

v1.0 · May 2026