"SMTP relay service" and "SMTP provider" are searches from people who already know what SMTP is and need to decide where their servers, applications and devices should hand mail off. They may run a fleet of services that currently send directly, or through a corporate mail server, and have started to see blocked mail, deferrals or an audit finding. The relay decision is smaller than a full platform choice, but it has outsized effects: it determines the IP reputation your mail inherits, how authentication is applied, what happens during an outage and how you monitor delivery. This guide is for engineering leaders and platform teams. It explains what an SMTP relay service does and the architecture patterns around it, the security properties to require (authentication, TLS, access control), how to evaluate providers, the operational practices that keep a relay healthy and how a dedicated relay differs from the relay features in a business mailbox suite, which we cover in our Google Workspace comparison. We operate a relay ourselves, so test our claims as you would anyone's.
What an SMTP relay service does
An SMTP relay accepts messages from your systems over the SMTP submission protocol and forwards them to the recipients' mail servers. Your applications do not need to manage delivery queues, retries, per-provider pacing or IP reputation; they hand mail to the relay and move on. A relay service usually adds authentication signing (DKIM), bounce and complaint processing, suppression, logging and event delivery. For the fundamentals, see how an SMTP relay works and SMTP servers vs services.
"SMTP provider" and "SMTP relay service" overlap heavily. In practice, a provider offers one or more relays plus the tooling around them. The questions below apply to both.
Why teams move to a dedicated relay
- Direct sending fails. Servers that send straight from cloud addresses are often blocked or deferred, and outbound port 25 may be restricted by the network provider.
- Reputation is scattered. Mail leaves from many hosts, each with its own address and no consistent authentication.
- No visibility. Logs are spread across servers, and nobody can answer "did this customer's email go out?"
- Compliance questions. Auditors ask where mail is sent from, how it is encrypted and who can send.
- Operational burden. Teams tire of maintaining queues, retries and blocklist responses.
Architecture patterns
| Pattern | Description | Use when |
|---|---|---|
| Direct to provider | Each application or service connects to the relay with its own credentials | Modern services, simple topology, per-service visibility |
| Internal relay (smart host) | Applications send to an internal mail server, which forwards everything to the external relay | Legacy systems, devices and many hosts that cannot hold credentials |
| Per-stream credentials | Separate credentials, and ideally separate domains or IP pools, for transactional, marketing and internal mail | Any organisation sending more than one kind of mail. See separating the streams |
| Primary and standby | A second relay available if the first degrades, behind your own wrapper or smart host | Critical mail such as one-time passcodes |
The internal smart-host pattern is useful because it gives you one place to apply rate limits, logging and policy, and one set of credentials to manage. It also adds a component you must run. Choose it deliberately.
Security properties to require
Authenticated submission
Never accept open relaying. A relay should require credentials for every submission and let you create separate credentials per service, with the ability to revoke one without affecting others. Store credentials in a secret manager, never in source control.
Encryption in transit
Submission should use TLS. Our relay accepts connections on port 587 with STARTTLS at smtp.migosmtp.com. Configure clients to require TLS and to validate the server certificate. See which SMTP port to use. Also ask how the provider handles TLS when delivering to recipients' servers.
Sender authentication
Verify your own sending domain with SPF and DKIM and align it with DMARC. Copy the exact records from the provider's dashboard domain settings. See authenticating your sending domain. If other vendors send for the same domain, plan SPF carefully; see multiple vendors on one domain and the SPF lookup limit.
Access and audit
Ask who at the provider can access your message data, how that access is logged and how long logs and content are kept. Ask about role-based access to the dashboard and API keys, and about audit logs for configuration changes.
Evaluating SMTP relay providers
| Question | What a good answer looks like |
|---|---|
| What ports and TLS modes are supported? | Clear documentation; modern TLS; the ports your environment can reach |
| How are credentials scoped? | Per-service credentials, revocation, optional restrictions |
| What are the rate and size limits? | Documented, adjustable, and clear about what happens when exceeded |
| What happens to messages during an incident? | Accepted messages are queued durably; communication is prompt |
| How do I see what happened to a message? | Searchable logs with per-attempt details and retention you can state |
| What IP options exist? | Shared and dedicated options, with warm-up guidance |
| How are bounces and complaints handled? | Automatic suppression, events to you, export of lists |
| What support is included? | Technical responses within stated targets |
| How do I leave? | Standard protocol, exportable suppressions and logs |
The same logic as a full vendor evaluation applies. Use the scorecard if you are comparing several.
Operating a relay well
- Separate credentials per service and environment. A leaked staging credential should not be able to send production mail.
- Rate limit at the edge. Even with a provider's limits, protect yourself from runaway jobs with limits in your own code or smart host.
- Monitor outcomes. Track bounce rate, complaint rate and deferrals by receiving provider, and alert on change. See email delivery monitoring and SLOs.
- Process feedback. Use webhooks or logs to suppress hard bounces and complainers. See SMTP bounce codes explained.
- Warm up new IPs. Ramp volume gradually. See warm-up guide.
- Test changes in staging. See testing email in staging.
- Document ownership. Name an owner for the relay, the DNS records and the runbook.
Questions to put to your own team first
Before you contact any provider, answer a few questions internally, because they determine which of the patterns above you need. How many distinct systems send mail today, and who owns each? Which of them can store a credential securely, and which are devices or legacy software that can only point at a host name? Which messages are time-critical, and which can wait? Where do replies go, and does anything depend on them? Which team will be paged when mail fails, and what do they see when it does? Teams that cannot answer these usually discover during a migration that a forgotten billing script or a monitoring tool was sending from an address nobody knew about. A short inventory, even a spreadsheet, before the move saves a surprise afterwards.
It also helps to define what "healthy" looks like before you start: the share of messages accepted by the relay on first attempt, the typical time from submission to delivery, and the bounce and complaint rates you see today. With that baseline, you can tell whether the move improved anything, and you can spot a regression within hours. Our guide to email delivery monitoring and SLOs shows how to turn those numbers into targets and alerts.
Common mistakes
- Hard-coding one shared credential across every service.
- Using port 25 from cloud hosts and wondering why mail is blocked.
- Disabling certificate validation to "make TLS work".
- Sending marketing and transactional mail through the same credentials and IPs.
- Ignoring bounce and complaint data.
- Forgetting that SPF can break when you add another sender.
Our SMTP relay page describes what we provide, and the dedicated IPs page covers reputation isolation. For code-level examples, see sending email from your app.
See the SMTP relay Authenticated submission on port 587 with STARTTLS, per-service credentials and delivery events.
References and further reading
Frequently asked questions
What is an SMTP relay service?
A service that accepts messages from your systems over SMTP submission and delivers them to recipients' mail servers, handling queues, retries, authentication signing, bounces and logging.
Should applications send directly to the relay or through an internal server?
Direct submission suits modern services. An internal smart host suits legacy systems and devices and gives one place for limits and logging, but you must run it.
What security properties should a relay have?
Mandatory authentication, per-service revocable credentials, TLS for submission, support for SPF, DKIM and DMARC alignment, and clear access and audit controls.
Why does sending directly from cloud servers often fail?
Outbound port 25 is frequently restricted and cloud IP ranges often have weak reputation, so mail is blocked or deferred. A relay avoids both problems.
What should I monitor on a relay?
Bounce rate, complaint rate and deferrals by receiving provider, queue and delivery times, authentication failures and unusual volume per credential.