An SMTP relay is a server that accepts outgoing mail from one system and forwards it on toward its final destination. It is typically used for transactional mail like receipts, password resets and notifications rather than person-to-person outreach. For cold email specifically, the relay model runs into a problem before volume or deliverability even come up: most relay providers' own policies do not allow unsolicited mail. This page covers that restriction using each provider's own acceptable use policy, a detail that sits alongside the wider picture in our cold email deliverability guide.
This page explains what an SMTP relay actually does and how it differs from sending through a real mailbox. It also covers what SendGrid, Mailgun, Postmark and Amazon SES say in their own policy pages about unsolicited email, and why most cold outreach runs through real mailboxes instead.
What is an SMTP relay in cold email terms?
An SMTP relay is infrastructure that takes a message handed to it by an application or server and routes it onward to the recipient's mail server, without the sender needing to run their own full mail server. It is built for software sending mail on a schedule or trigger: an app sending a signup confirmation, a system sending an invoice, a platform sending a password reset.
The relay model assumes every message corresponds to an action the recipient already took, which is the opposite assumption cold email starts from. That mismatch is the root of most of the restrictions relay providers put on their own services.
What is the difference between an SMTP relay and sending cold email from a real mailbox?
An SMTP relay sends as an application, often from a shared or pooled sending identity, while a real mailbox sends as a person, from an individual inbox with its own send and receive history. Receivers treat the two very differently, and so do the providers themselves.
| SMTP relay (transactional ESP) | Real mailbox (Google Workspace, Microsoft 365) | |
|---|---|---|
| Built for | Triggered, consent-based transactional mail | Any mail a person sends, including outreach |
| Typical sender identity | Shared or pooled across the ESP's customers | One mailbox, one person, one history |
| Replies | Often not expected or monitored | Expected; a real inbox receives them |
| Cold or unsolicited email | Against most providers' own acceptable use policies | Not restricted by the mailbox provider itself |
| Reputation unit | The ESP's shared sending infrastructure | The individual mailbox and sending domain |
A cold email that replies, gets a reply back, and continues as a real conversation fits the mailbox model naturally. A relay has no expectation of a two-way exchange at all, which is part of why reply handling on relay infrastructure is often an afterthought rather than a built-in feature.
What do SendGrid, Mailgun, Postmark and Amazon SES say about cold email in their own policies?
All four of the major transactional ESPs prohibit unsolicited bulk email in their own current acceptable use or terms of service pages, opened today. None of them carve out an exception for "cold outreach" as a category; the restriction is written around consent, not around intent.
- SendGrid (Twilio): its own Email Prohibited Content Types and Uses page lists as a prohibited action "sending unsolicited or unwanted emails in bulk" and separately prohibits "sending emails to email addresses that you obtained from the Internet or social media... without obtaining prior affirmative consent."
- Mailgun (Sinch): its own Acceptable Use Policy states that "acquiring or sending to a third-party mailing list is prohibited," that emails "can only be sent where permission has been expressly obtained," and sets a required spam complaint threshold of 0.08% or lower.
- Postmark (ActiveCampaign): its own Terms of Service, section 5, states "all email lists contained and/or used with respect to the Service must be permission-based subscriptions" and that "use of a list that has been purchased or rented from a third party is prohibited," with a spam complaint ceiling of 0.1% and a bounce ceiling of 10%.
- Amazon SES: AWS's own Acceptable Use Policy prohibits using the service "to distribute, publish, send, or facilitate the sending of unsolicited mass email or other messages, promotions, advertising, or solicitations (or 'spam')," and SES's own sending review FAQ describes account review and pausing specifically triggered by mail that "appears to be unsolicited."
The common thread across all four is affirmative, provable consent. A cold email to a prospect who has never interacted with your business does not fit that bar on any of these platforms, regardless of how well-written or targeted the email is.
Why does most cold email go through real mailboxes instead of a transactional ESP?
Because sending cold outreach through a relay provider that explicitly prohibits unsolicited mail puts the sending account at risk of suspension with no reliable warning, independent of how carefully the campaign is run. The policy violation exists at the point of sending to a non-consenting recipient, not at some later point where quality or targeting might excuse it.
A real mailbox on Google Workspace or Microsoft 365 does not carry this specific restriction the way a transactional ESP's own terms do. Those platforms are built around a person sending and receiving mail, and cold outreach sent at reasonable volume with proper authentication operates within what the mailbox is for. This is also why replies work naturally: a prospect who responds to a cold email sent from a real mailbox is replying to an actual inbox someone is watching, not to a relay with no expectation of a two-way conversation.
Can I still use SMTP relay infrastructure for part of a cold email setup?
Technically a relay can sit between an application and the final delivery hop, but using one to send unsolicited cold outreach still runs into the same acceptable use restrictions regardless of where in the chain it sits. The restriction is about what the mail is and whether the recipient consented, not about the specific protocol or hop used to deliver it.
Cold outreach platforms that route mail through a transactional ESP's shared infrastructure carry the same account risk the ESP's own policy describes, whether or not the end sender realizes a relay is involved. Checking the acceptable use policy of whatever is actually delivering the mail, not just the platform's own marketing, is worth doing before relying on it for outreach.
How does Pipefire send cold email without using an SMTP relay?
Pipefire sends cold email from real mailboxes it sets up on your sending domains, not through a transactional relay service. This avoids the acceptable-use conflict that a relay provider's own policy creates for unsolicited mail. Every domain gets its own SPF, DKIM and DMARC, a 14-day warm-up period, and automatic pausing at 3% hard bounces or 0.1% complaints, keeping each mailbox's sending within the bounds a real inbox is built for.
See our sending domain setup for how Pipefire sets up domains and mailboxes, and our cold email deliverability guide for the wider set of signals that decide whether outreach reaches the inbox.
SMTP relay cold email FAQ
Can I use SendGrid or Mailgun for cold email?
Not within their own acceptable use policies. Both providers explicitly prohibit sending unsolicited bulk email and require affirmative consent for mail sent through their platforms, and cold outreach to a prospect who has not opted in does not meet that bar, regardless of list quality or personalization.
What is the difference between an SMTP relay and an SMTP server for cold email?
An SMTP relay typically refers to a third-party service that forwards mail on behalf of another system, while an SMTP server can refer more broadly to any server handling mail transfer, including one you run yourself. In practice the terms overlap heavily in marketing copy, which is why checking a specific provider's own acceptable use policy matters more than the label it uses.
Will Amazon SES ban my account for sending cold email?
AWS's own sending review FAQ describes manual investigation and account pausing specifically for mail that "appears to be unsolicited," and AWS's Acceptable Use Policy prohibits unsolicited mass email outright. There is real account risk in using SES for cold outreach, not just a theoretical policy breach.
Why do transactional ESPs care so much about unsolicited cold email?
Because every ESP's deliverability depends on the collective reputation of its shared sending infrastructure, and Postmark's own terms describe this directly: a single bad sender can damage the reputation that every other customer on the platform depends on. That is why the policies are strict and enforced rather than aspirational.
Does Pipefire use an SMTP relay service for cold email?
No. Pipefire sends from real mailboxes it sets up for you rather than routing cold outreach through a transactional relay provider, which sidesteps the acceptable-use conflict those providers' own policies create for unsolicited mail.