How to Migrate From SendGrid to Mailer To Go
Moving your transactional email from SendGrid to Mailer To Go is mostly a DNS-and-credentials swap — the hard part isn’t the code, it’s cutting over without losing your sending reputation or re-mailing people who already bounced or unsubscribed. This guide walks the whole migration in order, with the exact config changes and a safe, reversible rollout.
If you’re still deciding, the SendGrid alternative comparison covers the why. This guide is the how.
Before you start: inventory what SendGrid is doing for you
Migrations go wrong when something invisible gets left behind. Write down:
- Sending domains and From: addresses you send from today.
- Your suppression data — bounces, blocks, spam reports, and unsubscribes. This is the one thing you must carry over; re-mailing a suppressed address tanks your reputation on day one.
- How you send — SMTP, the Web API (
@sendgrid/mail,sendgrid-ruby,sendgridfor Python), or both. - Templates stored in SendGrid (dynamic templates) versus rendered in your app.
- Event webhooks (delivered/open/click/bounce) and anything downstream that consumes them.
- Rough daily/peak volume, so you can plan warming.
Step 1 — Create your Mailer To Go sending domain
Sign up at mailertogo.com and add a sending subdomain rather than your root domain — we recommend mtg.yourdomain.com. It isolates your reputation and, if you delegate it, lets us manage DNS for you. See Why Mailer To Go sends from mtg.yourdomain.com for the reasoning and setup.
Step 2 — Authenticate (SPF, DKIM, DMARC)
Publish the SPF, DKIM, and DMARC records shown in your dashboard for the sending domain. If you already run DMARC for SendGrid, you’re ahead — you just add Mailer To Go as an authorized source during the overlap and tighten once SendGrid is gone. Full walkthrough with real records and dig verification: Email authentication, end to end.
Step 3 — Swap your credentials
SMTP. SendGrid’s tell-tale config is the literal username apikey. Point the same mailer at Mailer To Go instead:
# Before — SendGrid
host: smtp.sendgrid.net port: 587
username: apikey
password: SG.xxxxxxxx (your SendGrid API key)
# After — Mailer To Go
host: smtp.<region>.mailertogo.net port: 587
username: <MAILERTOGO_SMTP_USER>
password: <MAILERTOGO_SMTP_PASSWORD>
In Rails, that’s just new environment values — no code change:
# config/environments/production.rb
config.action_mailer.smtp_settings = {
address: ENV["MAILERTOGO_SMTP_HOST"], # smtp.<region>.mailertogo.net
port: 587,
user_name: ENV["MAILERTOGO_SMTP_USER"],
password: ENV["MAILERTOGO_SMTP_PASSWORD"],
authentication: :plain,
enable_starttls_auto: true
}
API. If you use SendGrid’s SDK, switch the transport to SMTP (the least-code path) or to the Mailer To Go API. In Node, moving off @sendgrid/mail to SMTP via Nodemailer:
// Before — @sendgrid/mail
// sgMail.setApiKey(process.env.SENDGRID_API_KEY);
// await sgMail.send({ to, from, subject, html });
// After — Nodemailer over Mailer To Go SMTP
const nodemailer = require("nodemailer");
const transport = nodemailer.createTransport({
host: process.env.MAILERTOGO_SMTP_HOST,
port: 587,
auth: { user: process.env.MAILERTOGO_SMTP_USER, pass: process.env.MAILERTOGO_SMTP_PASSWORD },
});
await transport.sendMail({ to, from, subject, html });
Step 4 — Import your suppression list (do not skip)
Export your suppressions from SendGrid before you cut over — Suppressions → Global Unsubscribes / Bounces / Spam Reports / Blocks in the dashboard, or via the API:
curl -s -H "Authorization: Bearer $SENDGRID_API_KEY" \
https://api.sendgrid.com/v3/suppression/bounces > bounces.json
curl -s -H "Authorization: Bearer $SENDGRID_API_KEY" \
https://api.sendgrid.com/v3/suppression/unsubscribes > unsubscribes.json
Load those addresses into your Mailer To Go suppression list so a hard-bounced or unsubscribed contact is never emailed again. This single step protects the reputation you spent years building on SendGrid.
Step 5 — Warm up and cut over gradually
Your new sending domain has no reputation yet, so don’t flip 100% of traffic at once. Run both providers in parallel and shift traffic in stages — e.g. 10% → 25% → 50% → 100% over a week or two — starting with your most engaged, lowest-risk mail (password resets, receipts). Watch bounce and complaint rates at each step. Keep SendGrid live and able to take traffic back until you’re fully cut over.
Step 6 — Verify, then decommission
- Send test mail and confirm SPF, DKIM, and DMARC all PASS (Gmail → Show original).
- Repoint your event webhooks at your app’s Mailer To Go handlers and confirm bounce/complaint events still flow.
- Once 100% of traffic runs clean through Mailer To Go for a few days, downgrade or cancel SendGrid — but leave your SPF/DKIM records for it in place for a week or two in case you need to roll back, then remove them.
Rollback
Because the switch is credentials + DNS, rollback is fast: point your mailer’s environment variables back at SendGrid. Keeping both providers authenticated during the overlap is what makes that a one-line change instead of an emergency.
New to sending from a subdomain or to email authentication? Start with Why Mailer To Go sends from mtg.yourdomain.com and the SPF/DKIM/DMARC setup guide. Migrating from a different provider? See Migrating from Mailgun to Mailer To Go.