SMTP Relay: What It Is, How It Routes Mail, and Where It Breaks
An SMTP relay accepts a message and forwards it toward its destination. As a commercial product it means handing mail to a provider that owns the outbound addresses, their reputation, the retry logic and bounce handling. What you are buying is their infrastructure, under their acceptable use policy.
Key takeaways
- On a shared pool you inherit reputation built by every other customer sending through it.
- Many relay services prohibit unsolicited commercial email in their acceptable use policy.
- Changing relay moves the connecting address and leaves every domain-level signal unchanged.
- Most B2B cold outbound sends from real mailboxes instead, because replies have to land somewhere.
An SMTP relay is a mail server that accepts a message from one system and passes it on toward its destination, rather than delivering it into a mailbox it hosts. Relaying is the ordinary business of SMTP, defined in RFC 5321: a message can pass through several servers on its way, each accepting responsibility and handing it to the next. In commercial usage the phrase usually names a specific product, a service you authenticate to and hand mail to so that it does the sending on your behalf.
That double meaning is worth separating before anything else. Relaying is a behaviour every mail server performs. An SMTP relay service is a thing you buy, and what you are buying is somebody else's sending infrastructure, reputation and deliverability operations.
What the service actually does for you
You connect to the provider's endpoint, authenticate, and submit a message. From there the provider handles the parts that are tedious and consequential: maintaining the outbound addresses and their reputation, negotiating connections and retries with receiving servers, processing bounces and complaint feedback, and giving you an interface to see what happened.
The alternative is running your own outbound mail server, which is entirely possible and involves owning all of that yourself, including the address reputation and the delisting requests when something goes wrong. The work is not difficult so much as continuous, which is the reason most organisations pay somebody else to do it.
Two adjacent terms cause most of the confusion.
Submission versus relay. A mail client handing a message to its own provider is using the submission service, conventionally on port 587 with authentication. A server accepting mail addressed to somebody else and forwarding it is relaying. Most commercial services are technically the first while being sold as the second, which is harmless as long as nobody is trying to reason precisely about who is responsible for what. It becomes relevant when a provider points at the distinction to explain why a particular behaviour is or is not theirs to fix.
Open relay. A server that relays for anyone without authentication. These were common in the early internet, were comprehensively abused, and are now blocklisted on sight. It is the reason authentication is mandatory on every relay service, and the reason "free SMTP relay" searches are a minefield: an unauthenticated endpoint that will carry your mail today is an endpoint carrying everybody else's too, and its addresses will be listed shortly.
- Step 1Submit
Your application or platform authenticates to the relay endpoint and hands over the message.
- Step 2Queue
The relay accepts responsibility, queues the message and manages retries and deferrals.
- Step 3Deliver
The relay connects to the recipient's MX host and delivers, using its own outbound addresses.
- Step 4Report
Bounces and feedback return to the relay, which surfaces them to you.
Where the textbook definition misleads
You are renting a reputation, not just a pipe. The relay's outbound addresses carry a history built by every customer sending through them. On a shared pool, your mail is judged partly on behaviour you did not produce, and a neighbour's bad campaign becomes your placement problem. This is the most important property of the choice and the one least visible in the pricing page.
Provider policies differ sharply on cold outbound, and it is a contractual question. Many transactional relay services permit only mail the recipient asked for, and prohibit unsolicited commercial email in their acceptable use policy. Sending cold campaigns through a service whose terms forbid it risks account termination mid-campaign, which is a worse failure than any deliverability problem. Read the acceptable use policy before the pricing.
A relay does not change what receivers think of your domain. Authentication still has to align to your domain, your sending history still accrues to it, and your list quality still governs the bounce and complaint rates. Switching relays moves the connecting address and leaves every domain-level signal exactly where it was, which is why it so rarely fixes the problem people switch to fix.
Sending limits are a property of the mailbox provider too. Where an outbound programme sends through Workspace or Microsoft 365 mailboxes rather than a relay, the constraint is the provider's per-account limits, and those are published and enforced. The limits by provider are worth knowing before designing around a volume the architecture cannot support.
Free is the wrong axis. The free tiers that dominate searches for this term are either strictly rate-limited, restricted to transactional mail, or both. The meaningful comparison is between architectures, mailbox-based sending against a relay service against your own infrastructure, and the costs that decide it are reputation ownership and policy fit rather than the per-message price.
- Sends from the provider's shared outbound addresses
- Per-account limits set by the provider
- Replies land naturally in a real mailbox
- Standard for cold outbound at modest per-mailbox volume
- Provider owns the addresses and their reputation
- Higher volume and better reporting
- Acceptable use policy may forbid cold outbound
- Shared pools mean inherited reputation
- Full control of reputation and configuration
- You own warmup, monitoring and delisting
- Needs sustained volume to be worth it
- The most operational work by a wide margin
What this means when you are running outbound
Most B2B cold outbound does not use a relay service at all, and understanding why clarifies the whole decision. Campaigns send through ordinary mailboxes on ordinary domains, because the message is meant to read as a person writing to a person and because replies need to arrive somewhere a human can answer them. That architecture caps per-mailbox volume, which is a constraint on the inventory rather than a problem to route around.
Relay services fit the adjacent job: high-volume mail sent from an application, where the sending identity is a system rather than a person. If your programme genuinely needs one, three things decide the choice.
Whether the acceptable use policy permits what you intend to send. This is first because it is the only one that can end the campaign abruptly.
Whether you are on a shared or dedicated pool, and what volume the dedicated option requires to be worth having, since an under-used dedicated address never establishes standing.
Whether your domain-level work is done. Correct authentication aligned to your domain matters more than the relay's marketing, and it is the part that travels with you if you change provider. A relay that signs only under its own domain leaves your DMARC alignment resting on whatever else you have configured, which is worth establishing before rather than after the migration.
Where replies fit, and why it decides the architecture
The question that settles the architecture for most outbound programmes is not throughput. It is what happens when somebody answers.
A relay service is built to send. Its job ends when the message is delivered, and the reply comes back to whatever address the message said to reply to. If that address is not a real, monitored mailbox, the reply arrives nowhere useful, and for a cold campaign the reply is the entire product. Everything else in the programme exists to produce it.
That is why mailbox-based sending is the default shape for this work rather than a compromise forced by cost. The mailbox that sends is the mailbox that receives, replies land in a real inbox with the original message threaded above them, and a person can answer in the ordinary way. Bolting a reply path onto a relay-based architecture is possible and is additional machinery that has to be built, monitored and kept working.
The corollary is worth stating for anyone designing this from scratch: decide where replies land before choosing how mail leaves. Most of the apparent trade-offs resolve immediately once that constraint is fixed, and a design that produces excellent sending statistics and loses answers is not a working design.
The migration that does not fix anything
A recognisable pattern is worth naming, because it wastes weeks. Placement declines, a team concludes the sending infrastructure is at fault, and moves to a new relay. Mail improves for a short period, because the new addresses have no history with the receivers, and then settles back to roughly where it was.
The reason is that the domain, the list and the message did not change, and those carry most of the judgment. The new addresses simply had nothing on file yet. If a migration is genuinely warranted, the way to find out is the comparison that separates sender-side from list-side causes: are all campaigns on this inventory affected, or one? If sibling campaigns on the same infrastructure are healthy, the infrastructure is not the variable and changing it will not help. That check costs one query and saves a migration.
- Yes: The acceptable use policy permits the mail you intend to send
- Yes: You know whether the outbound pool is shared or dedicated
- Yes: Authentication aligns to your domain, not only to the relay's
- Yes: Bounce and complaint feedback reaches your suppression process
- Yes: Replies arrive somewhere a person will read them
- No: Changing relay as the first response to a placement problem
The short version
An SMTP relay accepts a message and passes it along. As a product, it is somebody else's sending infrastructure, and what you are really acquiring is their address reputation, their retry logic and their bounce handling, subject to their rules about what you may send.
For cold outbound the usual architecture is not a relay at all, because campaigns send from real mailboxes on real domains so that replies land somewhere useful. Where a relay does fit, choose it on policy fit and reputation ownership rather than on price, and do the domain-level work regardless, since authentication, domain history and list quality follow you across any infrastructure change. If placement is the problem, an audit will identify it faster than a migration.
RevenueFlow runs cold email and LinkedIn outreach for B2B teams on sending infrastructure we build and monitor ourselves. See how the campaigns work.
Specification behaviour verified as of August 2026 against RFC 5321. Provider policies change; verify current terms with the vendor before relying on them.
Frequently asked questions.
Frequently asked questions- What is the difference between an SMTP relay and an SMTP server?
- Relaying is a behaviour rather than a product: any server that accepts a message and passes it on is relaying. A mail client handing a message to its own provider is technically using the submission service. Commercial relay services are usually the second while being sold as the first, which is harmless unless you are reasoning precisely.
- Can I use a relay service for cold email?
- Read the acceptable use policy before the pricing. Many transactional relay services permit only mail the recipient asked for, and sending cold campaigns through one whose terms forbid it risks account termination mid-campaign, which is a worse failure than any deliverability problem you were trying to solve.
- Will switching relay providers fix my deliverability?
- Usually not. Mail often improves briefly because the new addresses have no history with receivers, then settles back, because the domain, the list and the message did not change and those carry most of the judgment. Check whether all campaigns on the inventory are affected or only one before migrating anything.
- What is an open relay and why does it matter?
- A server that relays for anyone without authentication. They were common early on, comprehensively abused, and are now blocklisted on sight, which is why authentication is mandatory on every legitimate relay service. It is also why free unauthenticated endpoints are a poor idea: their addresses will be listed shortly.