Searches for a "Gmail SMTP relay service" or "SMTP relay service Google" come from teams that already pay for Google Workspace and wonder whether its relay is enough for the mail their applications send. The same question appears for Microsoft 365 and for cloud platforms that offer email features. The honest answer is that a business mailbox suite's relay can be a sensible choice for a small, internal and low-volume purpose, and a poor one for customer-facing application mail at scale. The difference lies in design intent. A workspace relay exists so that people's devices and a few internal systems can send mail as members of your organisation. A dedicated SMTP relay service exists to deliver application mail for many recipients, with the reputation controls, event feedback and volume handling that implies. This guide is for engineering leaders deciding which to use. It explains what each is designed for, the criteria that decide the choice, what to ask your own admin console and the provider's documentation (without us stating limits that change), how to migrate when you outgrow the suite and how to keep SPF, DKIM and DMARC working when you use both. For the dedicated side, see our SMTP relay architecture guide.
What a mailbox suite's relay is for
Business mailbox suites such as Google Workspace and Microsoft 365 let administrators allow devices and servers to send mail through the organisation's mail system, often by IP address or by authenticated account. The typical use cases are multifunction printers, scanners, monitoring tools that send alerts to staff, internal line-of-business applications and small notifications to a limited number of recipients. The mail is sent on behalf of your organisation's domain, using your organisation's mail infrastructure. See Gmail SMTP settings and limits for the personal-mailbox side, which is a different feature again.
Because this infrastructure is shared by all of a company's staff mail, it is tuned for the patterns of human email: moderate volume per user, mostly replies and one-to-few messages and a user base inside the organisation. It is not built around the needs of bulk or high-volume application sending, such as per-message event feedback, suppression management, per-stream IP pools or large burst handling.
What a dedicated relay service is for
A dedicated SMTP relay service is designed around application mail. Its core features are submission with per-service credentials, durable queueing and retry, pacing by receiving provider, authentication signing for your sending domains, bounce and complaint processing, suppression, searchable logs, webhooks and IP management. It exists to deliver mail to people outside your organisation at volume and to give you the data to improve it. See how an SMTP relay works.
How to choose
| Factor | Suite relay is reasonable when | Move to a dedicated relay when |
|---|---|---|
| Recipients | Mostly staff or a small known set | Customers, prospects and the public |
| Volume | Low and steady, well within the suite's published limits | High, bursty, or growing |
| Mail type | Alerts, scans, device notifications | Transactional, notifications at scale, any marketing |
| Feedback | You do not need per-message events | You need bounces, complaints and delivery events in your systems |
| Reputation | Shared with your staff mail and acceptable | You want application mail separated from staff mail |
| Visibility | Admin logs are enough | You need message search and per-attempt detail |
| Compliance | Suite terms already meet your needs | You need separate controls and records for application mail |
| Risk | A suite limit would only inconvenience staff | A limit would block customer-facing mail |
The reputation risk of mixing
If application mail shares a domain and infrastructure with staff mail, a deliverability problem in one affects the other. A campaign with high complaint rates can reduce the placement of an executive's email to a customer. A compromised application that starts sending spam can lead the suite to restrict sending for the whole organisation. Separating streams is a general best practice; see separating transactional and marketing streams. Use a subdomain for application mail so that its reputation is isolated from your main domain, with its own authentication.
Limits: read them, do not remember them
Sending limits for mailbox suites differ by plan, by account age and by the type of relay configuration, and providers update them. We do not state them here. Before you rely on a suite for any application, do three things.
- Read the provider's current documentation on sending and relay limits for your specific plan and configuration.
- Check what the provider does when a limit is reached: reject, delay, or suspend. The consequence matters more than the number.
- Test with realistic volume in a staging environment, and set alerts for rejections and deferrals.
Also check whether the suite requires authentication or IP allow-listing for relay, and whether your applications can meet that requirement securely.
Authentication when you use both
Many organisations keep their suite for staff mail and add a dedicated relay for applications. This works well if authentication is planned.
- SPF. A domain can have only one SPF record, and it is limited to ten DNS lookups. Adding a second sender means merging includes, not adding a second record. See SPF with Google Workspace, Microsoft 365 and multiple senders. Use a subdomain for application mail to keep records simple.
- DKIM. Each sender signs with its own selector. Add the provider's DKIM records from its dashboard. See DKIM records.
- DMARC. Make sure each sender's mail aligns with the From domain. Start with monitoring before you tighten policy. See DMARC records and multiple vendors on one domain.
Copy the exact SPF include and DKIM values from each provider's own dashboard. For our service these are in the dashboard domain settings. Check the result with the SPF, DKIM and DMARC checker.
Migrating application mail off a suite relay
- Inventory senders. Find every system that uses the suite relay: printers, scripts, applications and monitoring tools. Check relay logs and configuration.
- Classify them. Keep device and staff-notification mail on the suite if it fits. Move customer-facing and high-volume systems.
- Set up the dedicated relay. Authenticate a subdomain, create per-service credentials and configure TLS on port 587. Our host is
smtp.migosmtp.com. - Change senders gradually. Update one system at a time and watch bounces and complaints.
- Update the From address to the application subdomain if you changed it, and keep replies working. See inbound email processing if replies must reach an application.
- Remove the old path when nothing uses it, and revoke relay permissions.
Platform email features in cloud providers
Large cloud platforms also offer email sending features and relay arrangements. The same logic applies. Some are designed for application mail and some are intended for internal system messages with limits and approval steps. Ask the same questions: what is it designed for, what are the current limits and consequences, what feedback do you get and how do you leave. Our Amazon SES alternatives guide gives a neutral evaluation framework that works for any of them.
Common mistakes
- Using a personal or shared mailbox login as an application SMTP credential.
- Sending customer mail through the suite relay until a limit or suspension forces an emergency migration.
- Merging SPF badly and exceeding the ten-lookup limit.
- Sending application mail from the main domain, so a problem affects staff mail.
- Relying on IP allow-listing without controlling who can reach that IP.
- Not monitoring rejections, so failures are silent.
If you are planning the change, our SMTP relay and dedicated IPs pages describe the options, and the API reference covers the HTTPS route.
Move application mail to a dedicated relay Authenticate a subdomain, create per-service credentials and keep staff mail on your suite.
References and further reading
Frequently asked questions
Is the Google Workspace SMTP relay enough for application email?
It can suit low-volume internal mail from devices and staff systems. For customer-facing or high-volume application mail you usually need a dedicated relay with event feedback and reputation control.
What are the sending limits of the Google or Microsoft relay?
They vary by plan and configuration and change over time, so check the provider's current documentation for your plan and test what happens when a limit is reached.
Why separate application mail from staff mail?
A problem with application mail, such as complaints or a compromised app, can harm placement or trigger restrictions for staff mail on the same domain and infrastructure.
Can I use a suite and a dedicated relay on the same domain?
Yes, with planned SPF, DKIM and DMARC. Use a subdomain for application mail, merge SPF includes into one record and stay under the ten-lookup limit.
How do I migrate application mail off the suite relay?
Inventory senders, classify them, authenticate a subdomain on the new relay, move systems one at a time while watching bounces and complaints and remove the old path when unused.