What Is SMTP Relay and How Does It Work?

SMTP relay is the process by which an email message is transferred from one mail server to another on its way to the final destination. Every email you send passes through at least one relay hop, and often several. Understanding how relaying works is essential for configuring mail servers, troubleshooting delivery issues, and securing your infrastructure against abuse.

How SMTP Works at a High Level

The Simple Mail Transfer Protocol (SMTP), defined in RFC 5321, governs how mail is transmitted between servers. The basic flow:

1. The sending client (Mail User Agent) submits the message to its outgoing mail server (Mail Submission Agent) over port 587.
2. The outgoing server looks up the MX records for the recipient's domain.
3. The outgoing server connects to the recipient's mail server (Mail Transfer Agent) over port 25 and transmits the message.
4. The recipient's MTA delivers the message to the recipient's mailbox.

In this simple case, there is one relay hop. But in practice, the chain is often longer.

The MTA Relay Chain

When an email passes through multiple servers before reaching its destination, each intermediate server is acting as a relay. This happens in several scenarios:

• Internal routing: A large organization may route mail through multiple internal MTAs (gateway, filter, delivery server).
• Third-party relay services: The sender's server forwards mail to a relay service (like SendGrid, Amazon SES, or Mailgun) that handles final delivery.
• Smart hosts: A mail server is configured to forward all outbound mail to a specific upstream server rather than delivering directly.
• Backup MX servers: If the primary MX is unreachable, a secondary MX accepts the message and relays it to the primary when it comes back online.

Each relay hop adds a Received header to the message (per RFC 5321, Section 4.4), creating an auditable trail of the message's path. You can inspect this chain using the InboxTooling MX Lookup to verify which servers handle mail for a domain.

Open Relays: The Historical Problem

An open relay is a mail server that accepts email from any sender and forwards it to any destination without authentication. In the early days of the internet, open relays were common and considered a feature -- they allowed mail to traverse networks that were not fully interconnected.

Today, open relays are a critical security vulnerability. Spammers exploit them to send massive volumes of unsolicited email without using their own infrastructure. The consequences of running an open relay:

• Your server's IP address will be added to public blocklists (DNSBLs) within hours.
• Your legitimate outbound mail will be rejected by recipient servers.
• Your network may be flagged by your ISP or hosting provider.
• You may face legal liability under anti-spam regulations.

Modern mail server software (Postfix, Exim, Exchange) is configured by default to reject relay attempts from unauthorized senders. If you manage a mail server, verify this is the case.

Authenticated Relay

Authenticated relay requires the sending client to prove its identity before the server will relay the message. Authentication methods include:

• SMTP AUTH (RFC 4954): The client provides a username and password (or token) during the SMTP session. This is the standard for client-to-server submission on port 587.
• IP-based authentication: The relay server accepts connections only from specific IP addresses. Common in enterprise environments and when configuring connectors (e.g., Microsoft 365 SMTP relay).
• Client certificate authentication: TLS client certificates verify the sending server's identity.

Authenticated relay is the correct way to allow applications, devices, and remote servers to send email through your infrastructure.

Smart Hosts

A smart host (or relay host) is a server that an MTA is configured to forward all outbound mail to, instead of performing its own MX lookups and direct delivery. This is common when:

• The local server does not have a public IP address or has a poor IP reputation.
• The organization uses a centralized outbound gateway for logging, compliance, or filtering.
• A cloud-based relay service handles delivery, SPF alignment, and reputation management.

In Postfix, a smart host is configured with the relayhost directive:

relayhost = [smtp-relay.example.com]:587

In Exchange, this is configured through Send Connectors that route mail to a specific host.

SMTP Relay Services

Dedicated relay services exist specifically to handle outbound email delivery at scale. They provide:

• Dedicated or shared IP addresses with managed reputation.
• SPF and DKIM alignment for your domain.
• Bounce handling and feedback loop processing.
• Analytics: open rates, click rates, bounce rates, complaint rates.
• Throttling and queue management to respect recipient server rate limits.

Popular relay services include Amazon SES, SendGrid, Mailgun, Postmark, and SparkPost. These are essential for organizations sending bulk email (newsletters, transactional notifications) where reputation management is critical.

When using a relay service, your SPF record must include the service's sending infrastructure. For example:

@ TXT "v=spf1 include:amazonses.com ~all"

Checking Your Relay Configuration

To verify your mail infrastructure:

1. MX records: Confirm your MX records point to the correct servers using the InboxTooling MX Lookup.
2. Open relay test: Ensure your server rejects unauthorized relay attempts. You can test this by connecting to your server via telnet from an external IP and attempting to send to a third-party domain without authenticating.
3. SPF alignment: If you use a relay service, verify your SPF record includes that service. Run a check with the InboxTooling Full Report.
4. Header inspection: Send a test message and inspect the Received headers to confirm the relay chain matches your expected configuration.

Security Best Practices

• Never run an open relay. Verify that your MTA requires authentication for relay.
• Use TLS for all relay connections. STARTTLS on port 587 for submission; opportunistic TLS on port 25 for server-to-server transfer.
• Restrict relay by IP where possible. For devices and applications with static IPs, IP-based authentication is simpler and avoids credential management.
• Monitor your sending IP reputation. Even with authenticated relay, compromised credentials can turn your server into a spam source.
• Implement rate limiting. Prevent any single authenticated user or application from sending excessive volumes.

SMTP relay is a fundamental building block of email delivery. Configured correctly, it enables reliable, authenticated, and scalable email sending. Misconfigured, it opens the door to abuse and deliverability disasters.

Stay on top of your email infrastructure. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.