Managed sending is the right default, and custom SMTP is the alternative. With managed sending someone else owns the IP reputation, watches the blocklists, handles the feedback loops, and gets woken up when a shared IP gets listed at three in the morning. For most senders that's a strictly better deal than doing it yourself.
Custom SMTP routes outbound mail through your own Amazon SES, SendGrid, Mailgun or Postmark account instead. It's genuinely better in three specific situations, and it's also chosen fairly often for two reasons that turn out to be wrong.
This is how to tell which you're in, and how per-domain custom SMTP routing works if you decide to do it.
What Custom SMTP Actually Changes
Only the outbound path. Incoming mail still arrives at our servers via your MX records, still gets filtered, still lands in the same mailbox. What changes is the last hop on the way out: instead of handing your message to our sending infrastructure, we authenticate to your provider and hand it to them.
Everything downstream of that becomes theirs. Their IP addresses, their reputation, their rate limits, their bounce handling, their suppression list. You have swapped one operator for another, and you've taken on the relationship with the new one.
Concretely, what moves to your side:
| Concern | Managed sending | Your own SMTP |
|---|---|---|
| IP reputation | Ours to maintain | Your provider's, and your usage shapes it |
| Rate limits | Plan-based daily and hourly caps | Whatever your provider allows |
| Bounce and complaint handling | Handled and surfaced in the dashboard | Your provider's console and webhooks |
| Blocklist removal | Ours to chase | Yours, with your provider |
| Per-message cost | Included | Billed by your provider |
Three Good Reasons for Custom SMTP
1. Volume beyond what the plan is for. Plan limits top out at a few thousand messages per mailbox per day. If you're sending hundreds of thousands of transactional messages a month, a dedicated sending provider is both cheaper and better suited — that's the product they build. Don't try to push a bulk workload through a mailbox platform; both of you'll have a bad time.
2. You already have the relationship. If your application already sends receipts and password resets through SES with a warmed dedicated IP, routing your staff mail through the same place consolidates reputation instead of splitting it across two senders. Fewer moving parts and one console to look at when something goes wrong.
3. You're on Nano. Managed sending isn't included on Nano, so custom SMTP is how you send at all. That's the intended path rather than a workaround.
Two Reasons That Do Not Hold Up
"I will get better deliverability." Usually not, and often the reverse. A shared pool at a mature provider carries an established reputation built by thousands of senders. A fresh sub-account at SES has none — you're starting from zero and every large receiver treats you as an unknown until you've earned otherwise. Unless you're moving enough volume to warm and hold a dedicated IP, you're trading a good reputation you didn't have to build for a blank one you do.
"I want to bypass the sending limits." The limits exist because volume from a young domain looks like a compromised account, and receivers respond to it accordingly. Routing around the limit doesn't change how Gmail evaluates a domain that suddenly sends ten thousand messages. Your provider will apply its own ramp anyway, and if you push past it they will suspend the account — which is a worse outcome than a rate limit, because it's manual to undo. See sending limits and domain warm-up.
Per-Domain Custom SMTP and Reusable Profiles
Custom SMTP is configured per domain, which is more useful than it first appears.
Each domain points at its own outbound route. One domain can relay through SES while another uses managed sending, and a third can use a different provider entirely. For an agency, that means a client who insists on their own infrastructure gets it without changing anything for every other client.
Credentials are saved as profiles on the account rather than being typed per domain. Add SES once, then attach that profile to as many domains as you like. When the credential rotates, you change it in one place. Entering the same credentials six times is how five of them end up stale.
Setup: open the domain's SMTP tab, pick a saved custom SMTP profile or create one with hostname, port, username and password, then test before saving. The test opens a real SMTP session and authenticates. Don't skip it — an untested credential fails at the moment somebody sends something important, and the error surfaces to them rather than to you.
The DNS Half Nobody Mentions
Custom SMTP changes which servers send as your domain, and your DNS has to say so. Skip this and every message fails authentication.
SPF must include the new sender. Your provider publishes an include mechanism — include:amazonses.com, include:sendgrid.net, or similar. It has to be added to your existing record, not published as a second record. Two SPF records on one domain is an invalid configuration and both stop working.
Watch the lookup budget. SPF permits ten DNS lookups. Every include costs at least one, and provider includes frequently nest. Adding a third sender is where domains quietly cross the limit and the record becomes a permanent error. See the SPF lookup limit.
DKIM comes from the provider now. Your provider signs outbound mail with its own key, so their DKIM record has to exist alongside ours. Most give you two or three CNAMEs to publish. Mail that goes out through them and is signed only by us will fail DKIM.
DMARC alignment still has to work. DMARC requires SPF or DKIM to align with the visible From domain. Provider setups that sign with the provider's own domain rather than yours will pass DKIM and fail alignment — which fails DMARC. This is the single most common way a BYO-SMTP migration breaks, and it's invisible until the reports arrive. See DMARC alignment.
Desktop Clients Are a Separate Decision
Custom SMTP routing applies to mail composed in webmail or submitted through our API. A desktop client submits directly to whichever SMTP server it's configured with.
You have two sane arrangements. Point clients at us and let the domain's route apply, which keeps one place to change things. Or point clients at your provider directly, which removes a hop and is marginally faster.
What you shouldn't do is configure some clients one way and some the other. Two paths out means two sets of authentication results and two places to look when a message goes missing, and you won't remember which machine is which.
What You Now Own
Bounce handling. Hard bounces at your provider need suppressing at your provider. The dashboard shows what our infrastructure observed; it doesn't have visibility into their queue.
The complaint feedback loop. Spam complaints go to whoever owns the sending IP. Configure your provider to forward or store them, and actually read them — a rising complaint rate is the earliest warning you get before deliverability falls off.
Credential rotation. An expired SMTP password fails on the next send. Rotate it in the profile, and the test button confirms it before anyone notices.
The provider's own rules. SES starts in a sandbox that only sends to verified addresses, and getting out requires a support request describing your use case. That surprises people mid-migration on a Friday.
Frequently Asked Questions
Does custom SMTP change how I receive mail?
No. Only the outbound path changes. Inbound still arrives via MX at our servers and lands in the same mailbox with the same filtering.
Can different domains use different custom SMTP providers?
Yes. Custom SMTP is per domain, so one can relay through SES while another uses managed sending. Credentials are saved as reusable account-level profiles.
Will custom SMTP improve deliverability?
Not by itself, and often the opposite at first. A new provider sub-account starts with no reputation. It helps when you've the volume to warm and hold a dedicated IP, or when you already have an established sending relationship to consolidate onto.
Do I still need SPF and DKIM records?
More than before. Your provider's SPF include has to be merged into your existing record, and their DKIM records published. Mail sent through them but signed only by us fails DKIM, and misaligned signing fails DMARC.
Does custom SMTP remove the sending limits?
Your provider's limits apply instead of ours. Their ramp requirements are usually stricter, and exceeding them gets an account suspended rather than rate-limited.
What happens if my provider goes down?
Outbound mail for domains using that route fails until it recovers. Managed sending isn't a fallback — the domain uses the route it's configured with.
Is custom SMTP required on the Nano plan?
Yes. Nano doesn't include managed sending, so custom SMTP is how you send outbound mail on that plan.
Can I configure custom SMTP over the API?
Yes — custom SMTP profiles and per-domain routing are both available through the REST API and over MCP, including the connection test.
