How to Migrate From Mailgun to Mailer To Go

Guide Migration, SMTP, Deliverability, Mailgun July 9, 2026 by Mailer To Go Team

A step-by-step guide to migrating transactional email from Mailgun to Mailer To Go: sending-domain setup, SPF/DKIM/DMARC, swapping SMTP/API credentials, importing bounces/unsubscribes/complaints, and a safe parallel-run cutover with rollback.

Migrating from Mailgun to Mailer To Go is a controlled swap of DNS and credentials — not a rewrite. The real work is carrying your suppression data across and cutting over gradually so your sending reputation survives the move. Here’s the whole process in order, with the exact config and a reversible rollout.

Still comparing options? The Mailgun alternatives post covers the why. This is the how.

Before you start: inventory what Mailgun is doing for you

Note these down before you touch anything:

Your Mailgun sending domain (usually mg.yourdomain.com) and every From: address in use.
Suppression data — bounces, unsubscribes, and complaints. Carrying this over is non-negotiable; re-mailing a suppressed contact is the fastest way to wreck a fresh domain.
How you send — SMTP, the Mailgun API (mailgun.js, mailgun-ruby, or raw HTTP), or both.
Routes and inbound rules, if you use Mailgun for inbound or forwarding.
Webhooks (delivered/opened/clicked/failed/complained) and their consumers.
Volume at average and peak, for planning warm-up.

Step 1 — Create your Mailer To Go sending domain

Sign up at mailertogo.com and add a sending subdomain. If you were already on Mailgun’s mg.yourdomain.com, moving to mtg.yourdomain.com keeps the same clean separation from your root domain — and lets us manage its DNS if you delegate it. See Why Mailer To Go sends from mtg.yourdomain.com.

Step 2 — Authenticate (SPF, DKIM, DMARC)

Publish the SPF, DKIM, and DMARC records from your dashboard. You already did the equivalent for Mailgun, so this will feel familiar — the difference is the record values. During the overlap, keep both providers authorized on the domain. Real records and dig verification: Email authentication, end to end.

Step 3 — Swap your credentials

SMTP. Mailgun’s config uses smtp.mailgun.org with a postmaster@mg.yourdomain.com-style username. Repoint the same mailer:

# Before — Mailgun
host: smtp.mailgun.org   port: 587
username: postmaster@mg.yourdomain.com
password: <your Mailgun SMTP password>

# After — Mailer To Go
host: smtp.<region>.mailertogo.net   port: 587
username: <MAILERTOGO_SMTP_USER>
password: <MAILERTOGO_SMTP_PASSWORD>

In Rails this is an environment change, not a 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 call Mailgun’s API, the lowest-effort move is to switch that transport to SMTP. In Node, replacing mailgun.js with Nodemailer:

// Before — mailgun.js
// const mg = mailgun.client({ username: "api", key: process.env.MAILGUN_API_KEY });
// await mg.messages.create(DOMAIN, { 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 bounces, unsubscribes, and complaints from Mailgun before cutover — from the dashboard, or via the API:

curl -s --user "api:$MAILGUN_API_KEY" \
  https://api.mailgun.net/v3/mg.yourdomain.com/bounces > bounces.json
curl -s --user "api:$MAILGUN_API_KEY" \
  https://api.mailgun.net/v3/mg.yourdomain.com/unsubscribes > unsubscribes.json
curl -s --user "api:$MAILGUN_API_KEY" \
  https://api.mailgun.net/v3/mg.yourdomain.com/complaints > complaints.json

Load those addresses into your Mailer To Go suppression list so no one who bounced or opted out on Mailgun gets mailed again. Don’t send a single production message until this is done.

Step 5 — Warm up and cut over gradually

A new sending domain starts with no reputation. Run Mailgun and Mailer To Go in parallel and move traffic in stages — 10% → 25% → 50% → 100% across a week or two — beginning with high-trust mail (receipts, password resets). Monitor bounce and complaint rates at each increment, and keep Mailgun able to take traffic back until you’re done.

Step 6 — Verify, then decommission

Send tests and confirm SPF, DKIM, and DMARC all PASS (Gmail → Show original).
Repoint webhooks to your Mailer To Go event handlers; confirm bounce/complaint events still arrive.
If you used Mailgun routes for inbound, set up the equivalent before you drop the domain there.
After a few clean days at 100%, cancel Mailgun — but keep its SPF/DKIM records for a week or two as a rollback safety net, then remove them.

Rollback

The cutover is credentials + DNS, so rolling back is just repointing your environment variables at Mailgun. Keeping both providers authenticated through the overlap is what makes rollback a one-line change.

New to subdomain sending or authentication? See Why Mailer To Go sends from mtg.yourdomain.com and the SPF/DKIM/DMARC setup guide. Coming from a different provider? See Migrating from SendGrid to Mailer To Go.