SMTP relay: what it is, how it works, and when your mail needs one

Strip email down to its plumbing and one verb is left: relay. A message travels from the machine where it was written to the machine where it will be read by being handed from mail server to mail server, and every server in that chain that accepts the message and passes it onward is, for that hop, a relay. "SMTP relay" as a product name means something narrower and more useful: a server, usually someone else's, that accepts your application's outgoing mail and takes over the job of delivering it to the world. This guide covers both meanings, because you cannot evaluate the product without understanding the verb.

Relaying, as the protocol defines it

SMTP is a store-and-forward protocol. RFC 5321, the specification, describes a sender connecting to a receiving server, offering a message, and getting a numeric verdict for every step (the code grammar is catalogued in SMTP reply codes). The receiving server either holds the message for a local mailbox or relays it onward toward the domain in the recipient address, which it locates through that domain's MX record.

In the earliest decades of email, most servers relayed for anyone who asked. That courtesy died for a specific reason: spammers routed their volume through other people's servers to borrow their standing. A mail transfer agent that still forwards mail from arbitrary strangers is called an open relay, and operating one today is a fast route onto every blocklist that matters, which you can confirm from the outside with the blacklist checker. Modern relaying is therefore closed by default: a server relays only for senders it can identify, by credentials or by source IP.

The relay as a product

When a provider sells "SMTP relay" or a "smarthost," the offer is this: point your application, website, or device at our server, authenticate, and we deliver your mail from our infrastructure. Your code speaks ordinary SMTP, usually to port 587, the mail submission port defined in RFC 6409, with STARTTLS and a username and password. Everything downstream becomes the relay operator's problem: connection management, retries on deferral, bounce capture, IP reputation.

That last item is the real product. Mailbox providers judge mail substantially by the reputation of the IP and domain it arrives from, and reputation is earned slowly through warm-up and consistent volume. A relay service rents you sending infrastructure whose reputation already exists, either on a shared IP pool or on a dedicated IP of your own once volume justifies it (the trade-off is covered in dedicated IP vs shared IP).

Relay versus API: same delivery, different doorway

Most commercial relay operators expose two doorways to the same sending pipeline: the SMTP endpoint and an HTTP API. SMTP wins when you cannot change the sending software, which is exactly the situation with legacy applications, CRMs, monitoring systems, printers, and anything else with an "SMTP settings" screen and nothing more. An API wins for new code: structured error responses instead of parsing reply codes, and no connection state to manage. Deliverability does not differ between the doorways; the message leaves the same infrastructure either way.

What a relay does not do for you

A relay delivers from its IPs, but it sends as your domain, and mailbox providers authenticate the domain. Three records remain your responsibility, all covered in SPF, DKIM and DMARC explained. Your SPF record must include the relay's sending ranges via the include mechanism the provider documents, and stacking several providers is how domains hit the 10-DNS-lookup limit. The relay will sign with DKIM using a selector you publish at your DNS host, and without that step many relays sign with a generic domain that fails alignment. And your DMARC policy governs what receivers do when authentication fails. Verify the whole triad from the outside with the email authentication checker before trusting a new relay with production mail; Google and Yahoo both make authentication non-negotiable for bulk senders in their published sender requirements.

When you actually need one

The clear cases: an application that must send mail (receipts, resets, notifications) from a server whose own port 25 is blocked by the hosting provider, a default many cloud and hosting platforms now apply; a fleet of devices or legacy systems that only speak SMTP; a marketing stream that has outgrown the sending limits of an office suite, the situation described for Google in sending email through Google Workspace and for Microsoft in sending email through Microsoft 365. The clear non-case: ordinary person-to-person office mail, which your mailbox provider already relays.

Running your own relay on a VPS is technically possible and operationally expensive: you inherit warm-up, reverse DNS, blocklist monitoring, bounce processing, and the slow accumulation of reputation, with none of a provider's history. Most senders are better served renting the infrastructure.

Choosing a relay operator

We treat relay and transactional providers as one category and profile them individually in our services directory, where entries such as SMTP2GO, Mailjet and Elastic Email illustrate the range of offerings rather than a shortlist; measured placement comparisons will come from our deliverability benchmark as test cycles complete, so nothing here endorses a vendor. The questions that separate operators are checkable without a benchmark: does the provider document its IP pool policy and offer dedicated IPs at your volume; does it hand you bounce and complaint data (a feedback loop you can act on); does it require or merely permit proper DKIM with your own domain; and does it publish sending limits and throttling behavior rather than discovering them for you at send time.

Related guides

• Sending email through Google Workspace — Google's own relay endpoints, limits and configuration
• Sending email through Microsoft 365 — the M365 counterpart: SMTP AUTH, direct send, connectors
• What is transactional email — the mail stream most often pointed at a relay
• Dedicated IP vs shared IP — whose reputation your relayed mail rides on
• Email authentication checker — verify SPF, DKIM and DMARC after connecting a relay
• SPF checker — confirm the relay's include made it into your record

About this guide

Written by InboxRatio Editorial. Protocol behavior follows RFC 5321 (SMTP) and RFC 6409 (message submission); authentication mechanics follow RFC 7208 (SPF) and RFC 9989 (DMARC, which replaced RFC 7489 in May 2026); provider requirements are drawn from the mailbox providers' published sender guidelines. Vendor-selection criteria are stated as questions to ask, not recommendations. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on protocol and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

30 September 2026. RFC references and provider documentation reviewed quarterly.

Frequently asked questions

What is an SMTP relay? A mail server that accepts your outgoing email and delivers it onward to recipients' servers on your behalf. As a commercial service, it means renting a provider's sending infrastructure: your application submits mail over SMTP, and the provider's servers, IPs and retry machinery handle delivery.

What is the difference between an SMTP server and an SMTP relay? Every relay is an SMTP server, but a server that only receives mail for its own mailboxes is not relaying. "Relay" describes the forwarding role: accepting mail whose final destination is elsewhere and passing it on.

What port does SMTP relay use? Port 587 with STARTTLS is the standard submission port per RFC 6409, and most providers also accept 465 (implicit TLS). Port 25 is for server-to-server delivery and is blocked for outbound use by most cloud and residential networks.

Is an open relay the same thing? No. An open relay forwards mail from anyone without authentication, which is how spammers historically laundered volume, and blocklists treat open relays as hostile infrastructure. Modern relay services authenticate every sender by credentials or registered IP.

Do I still need SPF and DKIM if I use a relay? Yes. The relay supplies the IPs, but receivers authenticate your domain: your SPF record must include the relay's ranges, DKIM must sign with your domain via a published selector, and DMARC ties both to the address recipients see. An unauthenticated relay setup fails the major providers' sender requirements.

Can I use a free SMTP relay? Free tiers exist across the category and are workable for low transactional volume. The constraint is rarely price: free tiers ride shared IP pools whose reputation you don't control and cap daily volume. Compare providers as a category in our services directory rather than optimizing for the word "free."

The relay question is never really "which server accepts my mail." It is whose reputation your mail travels on and whether your domain's records vouch for the arrangement. Connect the relay, publish the records, and let the email authentication checker prove the chain holds.