SMTP Relay vs Direct Delivery

The two architectures

Why direct delivery is hard

• IP reputation. A new IP has no sending history. Major receivers (Gmail, Outlook) start out suspicious. Without careful warm-up — gradually increasing volume over weeks — most mail goes to spam initially.
• PTR records. Required for FCrDNS; controlled by your ISP, not you. See reverse DNS and email.
• Bounce handling. Direct senders receive bounce messages from every receiver. Parsing and acting on them is its own subsystem.
• Throttling. Many large receivers rate-limit unknown senders. Your code needs to back off and retry intelligently.
• Block lists. Every IP gets listed somewhere eventually. Direct senders monitor and dispute listings.
• TLS configuration. Maintaining valid certs, supporting MTA-STS / DANE, keeping cipher suites current.
• Maintenance and uptime. Outbound mail server reliability is yours to provide.

Why smarthost relay is easy

• The provider has good IP reputation from sending billions of messages.
• PTR, SPF (you authorize the provider in your SPF record), DKIM (provider signs with their domain or yours), TLS — all configured.
• Bounce handling, retry logic, throttle compliance — provider's problem.
• Deliverability dashboards show what's happening.
• Per-message cost scales with volume; small senders use free tiers.

When direct delivery is right

• Mail volume justifies operational investment. Tens of millions of messages per month; the per-message fees would dominate the cost of running your own.
• Specialized requirements. Compliance scenarios that prohibit third-party relay, custom DSN formats, integrated bounce processing tied tightly to internal systems.
• Authoritative MTA for your own domain. If you receive mail for your domain, you already run an inbound MTA; outbound from the same server is a small addition.
• Internal-only mail. Server-to-server within an enterprise where reputation and external delivery don't apply.

When smarthost relay is right

• Cloud-hosted application sending transactional mail. Cloud IPs have terrible default reputation; use a provider with warm IPs.
• Marketing or bulk mail. Specialized providers (with separate marketing IP pools) outperform general direct sending.
• Small-to-medium volume. Free tiers cover most needs; per-message rates are low.
• Operations team has no email expertise. Email deliverability is its own discipline; outsourcing the operational complexity is sensible.

The hybrid pattern: inbound direct, outbound relay

A common compromise: receive mail directly (you control the inbox) but relay outbound through a provider (provider controls deliverability). Your MX records point at your own server for incoming; your outbound configuration relays through SendGrid or similar.

The split takes advantage of both models: full control of incoming mail and content storage, while delegating the harder deliverability operational problem to specialists.

Hybrid: multiple smarthosts

Large senders often use different providers for different traffic types:

• Transactional mail (receipts, password resets) — a provider optimized for high-deliverability, low-volume, low-latency transactional flows.
• Marketing / bulk mail — a provider with marketing-grade reputation and segregated IP pools.
• Internal/corporate mail — yet another path, often via Microsoft 365 or Google Workspace.

Each path has its own SPF and DKIM configuration; DMARC reports aggregate the results.

SPF and the smarthost

When relaying through a smarthost, the smarthost's IP appears as the sending IP. Your SPF record must authorize that IP (or the provider's SPF include). A typical SPF for a domain using SendGrid:

example.com. IN TXT "v=spf1 include:sendgrid.net ~all"

Multiple providers means multiple includes; mind the 10-lookup limit.

DKIM and the smarthost

The provider can sign mail with either:

• Their own domain. The DKIM signature claims to be from sendgrid.net; aligns with the smarthost, not your domain.
• Your domain (with delegated key). Provider gives you a CNAME or TXT record to publish; outgoing mail is signed by your domain via their selector.

The second is correct for proper DMARC alignment. Always publish the provider's DKIM CNAME/TXT records so mail signs as your domain.

Bounce handling

When mail can't be delivered, the recipient mail server sends a bounce message back. Where this lands depends on architecture:

• Direct delivery: bounce comes to your domain. Your bounce handler processes it.
• Smarthost: bounce comes to the smarthost's envelope sender. Smarthost typically exposes bounce events via webhook or API.

For unsubscribes and complaints, the smarthost API is the cleanest source of truth. Direct senders parse bounces themselves — more flexibility, more code.

Frequently Asked Questions

What is a smarthost?

An outbound SMTP server that accepts mail from your mail server (or application) and relays it onward to recipients. Instead of your server connecting directly to each recipient's MX, it hands mail off to the smarthost and the smarthost handles delivery. Used to leverage the smarthost's IP reputation, simplify queue management, and avoid running outbound MX yourself.

When should I send mail directly?

When you have a dedicated mail server with proper PTR, SPF, DKIM, DMARC, and a clean IP reputation; when you need fine-grained control over delivery (retry policies, bounce handling, priority); when relay through a third party violates compliance; or when sending volume is large enough that per-message smarthost fees exceed the operational cost of self-hosting.

When should I relay through a smarthost?

When you don't want to manage IP reputation; when you're sending from cloud instances with bad-by-default IP reputation; when your ISP blocks port 25; when you want deliverability analytics and bounce handling provided as a service; or when send volumes are low enough that a smarthost provider's free tier covers them.

What is the difference between a smarthost and a transactional email provider?

Transactional email providers (SendGrid, Mailgun, Postmark, AWS SES, etc.) are smarthost services with extras — API-driven sending, deliverability dashboards, webhook callbacks for events, template management, and so on. A bare smarthost just relays SMTP. The category boundary is fuzzy; most modern smarthosts are transactional providers.

Can I use multiple smarthosts?

Yes, and many production setups do. Patterns: split by traffic type (transactional via Postmark, marketing via SendGrid), failover (primary smarthost with secondary for outages), or geographic optimization. The complexity is monitoring and keeping authentication records in sync across providers.