SendStreak logo

What is SMTP relay?

SendStreak Academy

SMTP relay is the process of routing an outgoing email through an intermediary mail server rather than sending it directly from your application to the recipient’s mail server. The intermediary - called a relay server or smart host - accepts the message from your application via SMTP, then takes responsibility for delivering it to the final destination.

When your application sends an email, it has two choices: connect directly to the recipient’s mail server (direct sending) or hand the message off to a relay server that delivers it on your behalf. Nearly all production email goes through relay, because direct sending from application servers creates significant deliverability problems.

How SMTP relay works

The relay process adds one hop to the delivery chain:

  1. Your application connects to the relay server via SMTP (typically on port 587 with STARTTLS or port 465 with implicit TLS).
  2. It authenticates using credentials provided by the relay service.
  3. It submits the message using the standard SMTP commands (MAIL FROM, RCPT TO, DATA).
  4. The relay server accepts the message and queues it for delivery.
  5. The relay server looks up the recipient’s MX records in DNS and connects to the recipient’s mail server.
  6. The relay server delivers the message, handling any temporary failures and retries.

From your application’s perspective, the job is done after step 3. The relay server handles the complex work of DNS lookups, connection management, retry logic, and bounce processing.

Direct sending vs. SMTP relay

  Direct sending SMTP relay
How it works Your server connects directly to the recipient’s MX server Your server sends to a relay, which delivers to the recipient
IP reputation Your server’s IP needs its own reputation The relay’s IP pool has established reputation
Retry handling You must implement retry logic The relay handles retries automatically
Bounce processing You must parse bounce messages The relay processes and reports bounces
Port requirements Needs outbound port 25 (often blocked by cloud providers) Uses port 587 or 465 (not blocked)
Deliverability Poor without significant warm-up and infrastructure Good out of the box with a reputable relay
Setup complexity High - DNS, IP reputation, feedback loops Low - authenticate and send

The biggest practical issue with direct sending is that most cloud providers (AWS, Google Cloud, Azure, DigitalOcean) block outbound port 25 by default to prevent spam. You would need to request an exception. SMTP relay avoids this entirely because it uses submission ports (587 or 465).

Why relay improves deliverability

Relay services maintain large pools of IP addresses with established sending reputations. When your email comes from one of these IPs, receiving mail servers are more likely to accept it. Building this reputation yourself takes weeks of careful warm-up and consistent sending patterns.

Relay services also handle the operational complexity that affects deliverability:

  • Automatic retries for temporary failures (SMTP 4xx responses), with proper exponential backoff.
  • Bounce handling - the relay processes bounce messages (5xx responses) and reports them back to you, so you can stop sending to invalid addresses.
  • Feedback loop processing - when recipients mark your email as spam, the relay receives these signals and reports them.
  • Connection pooling - the relay maintains persistent connections to major mail servers, reducing connection overhead.

Common SMTP relay services

Most email infrastructure providers offer SMTP relay as their core product. You configure your application to send through their SMTP servers, and they handle delivery.

Service SMTP server Notes
Amazon SES email-smtp.{region}.amazonaws.com Low cost, requires sender verification
Google Workspace smtp-relay.gmail.com For Google Workspace customers, separate from smtp.gmail.com
Postmark smtp.postmarkapp.com Focused on transactional email
Mailgun smtp.mailgun.org Supports both transactional and marketing
SendStreak Uses your configured provider Wraps your existing SMTP relay with templates and tracking

Note the distinction for Google Workspace: smtp.gmail.com is the standard submission server for individual Gmail and Workspace accounts. smtp-relay.gmail.com is a dedicated relay service for Google Workspace organizations that allows routing through Google’s servers with higher limits and different authentication options.

SMTP relay vs. email API

Many providers offer both SMTP relay and a REST API for sending email. The choice depends on your use case:

SMTP relay is the better choice when you have existing code that already speaks SMTP (e.g., using Nodemailer in Node.js or the emails library in Python), when you want provider portability (all SMTP servers use the same protocol), or when you are migrating from one provider to another.

Email API is the better choice when you want richer features out of the box (template rendering, batch sending, scheduling), when you prefer JSON over SMTP protocol details, or when you need synchronous delivery status in the API response.

Both approaches end up doing the same thing - delivering your message to the recipient’s mail server. The delivery path and authentication requirements are identical.

Authentication for relayed email

When using a relay service, you still need proper SPF, DKIM, and DMARC records on your sending domain. The relay sends on your behalf, so receiving servers check your domain’s authentication records.

Each relay provider documents the DNS records you need to publish. Typically this means adding an include to your SPF record (to authorize the relay’s IPs) and publishing a DKIM public key (to verify signatures the relay applies on your behalf).

Try SendStreak for Free now!