Switch transactional email providers
Switching transactional email providers means authenticating your domain, carrying over suppression lists and updating every app that sends. Here's the safe order.
Official sources last reviewed · How we review
Build your personalized plan
A few questions, revealed as they become relevant. Your answers stay in this browser.
Start with the basics
Optional. Provider names only. Never enter API keys or passwords.
We never ask for phone numbers, card numbers, passwords or codes. Names of providers or nicknames are enough.
Your plan so far
16things this change touches
- critical2
- high9
- moderate5
- low0
Updates as you answer. Every item will explain why it’s there.
What could break
In a typical transactional email provider plan, these are the most serious things to get right.
Authenticate your sending domain with Postmark (DKIM and SPF)
Critical · Email delivery
Mail from the new provider fails authentication and lands in spam or is rejected.
Update API keys and SMTP settings in every environment
Critical · Integrations & APIs
Any system still holding the old settings keeps sending through the old provider, or fails completely once the old account is closed.
Test password resets and sign-in codes end to end
Critical · Sign-in & recovery
Users can't get into their accounts, and support is flooded with lockout requests.
List everything that sends through the old provider
High · Email delivery
A forgotten sender keeps using the old credentials, and its password resets or receipts silently stop when the old account closes.
Check sending limits and account approval
High · Email delivery
Mail is throttled or blocked on cutover day because the new account isn't approved for your volume yet.
Set up the custom return-path (bounce) domain
High · Email delivery
SPF passes for the provider's domain but not yours, so DMARC depends on DKIM alone and bounces are handled under the provider's name.
Check your DMARC policy and alignment
High · Email delivery
Password resets and receipts quietly go to spam or bounce on cutover day.
Use a new click-tracking domain and leave the old one working
High · Website & DNS
Links in past receipts, account emails and newsletters stop working for customers who open them later.
Export suppression lists from Twilio SendGrid and import them
High · Email delivery
Sending to addresses that bounced or complained damages your sender reputation, and emailing people who unsubscribed can breach anti-spam rules.
Update the code that calls the provider's API
High · Integrations & APIs
Sends fail on unexpected errors, retries cause duplicates, or message IDs your app stores no longer match.
Before and after the change
Before you change it
- List everything that sends through the old provider
- Check sending limits and account approval
- Verify sender addresses and reply-to inboxes
- Authenticate your sending domain with Postmark (DKIM and SPF)
- Set up the custom return-path (bounce) domain
- Check your DMARC policy and alignment
- Use a new click-tracking domain and leave the old one working
- Export suppression lists from Twilio SendGrid and import them
- Export message logs and reports you may need
After the change
- Update API keys and SMTP settings in every environment
- Update the code that calls the provider's API
- Update SMTP plugins and platform settings
- Rebuild event webhooks
- Update firewall rules and allowlists
- Switch traffic in stages and keep a way back
- Test password resets and sign-in codes end to end
- Test delivery and authentication at major mailbox providers
- Monitor deliverability for the first weeks
- Alert on sending errors and bounce spikes
- Revoke Twilio SendGrid keys, then close the account
- Remove the old provider's DNS records once mail has settled
Your own plan adds or removes items based on your answers, and explains why each one is there.
The safe order
Doing things in the right sequence is what keeps you from getting locked out halfway through.
Before the change
Step 1: Find everything that sends email
Apps, workers, plugins and tools that hold the old provider's keys or SMTP settings.
- List everything that sends through the old provider (high risk)
Step 2: Prepare the new account
Limits, sender addresses, templates and mailbox-provider requirements.
- Check sending limits and account approval (high risk)
- Verify sender addresses and reply-to inboxes (moderate risk)
Step 3: Authenticate your domain
Add the new provider's records alongside the old ones and check DMARC.
- Authenticate your sending domain with Postmark (DKIM and SPF) (critical risk)
- Set up the custom return-path (bounce) domain (high risk)
- Check your DMARC policy and alignment (high risk)
- Use a new click-tracking domain and leave the old one working (high risk)
Step 4: Carry over suppressions and logs
Addresses you must not mail again, and the records you may need later.
- Export suppression lists from Twilio SendGrid and import them (high risk)
- Export message logs and reports you may need (moderate risk)
During the change
Step 5: Update keys, code and webhooks
Every system and environment that sends or receives events.
- Update API keys and SMTP settings in every environment (critical risk)
- Update the code that calls the provider's API (high risk)
- Update SMTP plugins and platform settings (high risk)
- Rebuild event webhooks (high risk)
- and 1 more
Step 6: Move traffic over in stages
One email type at a time, with the old provider ready as a fallback.
- Switch traffic in stages and keep a way back (high risk)
Verify
Step 7: Test delivery and authentication
Inbox placement and passing SPF, DKIM and DMARC at the big mailbox providers.
- Test password resets and sign-in codes end to end (critical risk)
- Test delivery and authentication at major mailbox providers (high risk)
Step 8: Watch deliverability for the first weeks
Bounces, complaints and DMARC reports.
- Monitor deliverability for the first weeks (high risk)
- Alert on sending errors and bounce spikes (moderate risk)
Clean up
Step 9: Revoke old keys and close the old account
Only after the old provider has gone quiet.
- Revoke Twilio SendGrid keys, then close the account (high risk)
Later
Step 10: Remove the old provider's DNS records
Once in-flight mail has settled and old links no longer matter.
- Remove the old provider's DNS records once mail has settled (moderate risk)
Why this change needs a plan
Transactional email is the mail your product can't do without: password resets, sign-in codes, receipts and account alerts. Switching providers touches your DNS, your application code and every tool that quietly sends through SMTP.
The usual problems are authentication that doesn't align with your DMARC policy, suppression lists left behind (so you start mailing addresses that bounced or complained), webhooks your app depends on, and old tracked links that break when a tracking domain is repointed.
The safe approach is to set up and verify the new provider alongside the old one, switch traffic in stages with a way to roll back, and only clean up the old provider once deliverability looks normal.
Why it matters
If transactional email fails, users can't reset passwords or sign in, customers don't get receipts, and support requests pile up. Deliverability problems can take weeks to repair.
What makes it risky
Risk is highest when the provider sends password resets or sign-in codes, when you receive inbound email through it, when you also send marketing email (unsubscribes must carry over), and when your DMARC policy rejects unaligned mail.
Common mistakes
- Switching API keys before the new provider's DKIM and return-path records are verified.
- Starting with an empty suppression list and sending to addresses that previously bounced or complained.
- Repointing the click-tracking domain, which breaks links in emails already sent.
- Updating production but forgetting staging, background workers, website plugins and other tools that send by SMTP.
- Deleting the old provider's DNS records on cutover day instead of waiting for in-flight mail to settle.
Frequently asked questions
Will switching providers hurt my deliverability?
It can for a while, mostly if authentication isn't aligned, suppressions are missing, or volume jumps suddenly on new IP addresses. Authenticate first, import suppressions, move traffic in stages and watch bounce and complaint rates.
Do I need to change my SPF record?
Usually you add the new provider's include to your existing SPF record (a domain should have only one) and remove the old include later. Many providers also use a custom return-path domain so SPF aligns for DMARC.
Can I run both providers during the switch?
Yes, and it's the safer way. Both can be authenticated on the same domain, so you can move one type of email at a time and switch back if something goes wrong.
What happens to my suppression list?
It stays with the old provider unless you export it. Export bounces, unsubscribes and spam complaints and import them into the new provider before you send.
When can I remove the old provider's DNS records?
After all traffic has moved, retries and bounces have settled, and you no longer need old tracked links to work. Then remove the old DKIM records, SPF include, and return-path and tracking records.
Regional notes
General information, not legal advice. Check the official source where you live.
- Canada
- If you send commercial email to people in Canada, CASL's consent and unsubscribe rules apply. Carry over unsubscribe records with your suppression list.
- United States
- The FTC's CAN-SPAM guidance requires honouring opt-out requests for commercial email promptly. Import unsubscribes before you send marketing email from the new provider.