How to Migrate From Postmark to Mailer To Go

Guide Migration, Postmark, SMTP, Deliverability July 10, 2026 by Mailer To Go Team

A step-by-step guide to migrating transactional email from Postmark to Mailer To Go: sending-domain setup, SPF/DKIM/DMARC, swapping SMTP/API-token credentials, exporting your suppression streams, and a safe parallel-run cutover with rollback.

Postmark has earned its reputation for fast, reliable transactional delivery — so if you’re moving, you already value deliverability. The good news: switching to Mailer To Go is a controlled swap of DNS and credentials, and you can run both side by side and roll back at any point. Here’s the whole migration in order.

Weighing it up first? See how the two stack up in Mailer To Go vs Postmark. This guide is the how.

Before you start: inventory what Postmark is doing for you

Servers and message streams — Postmark separates transactional and broadcast into streams; note which you use.
Sender signatures / domains — the From: addresses and domains you’ve verified.
Suppression data — bounces and spam complaints, per message stream. This must come with you; re-mailing a suppressed address wrecks a new domain’s reputation.
How you send — SMTP (with a Server API Token) or the Postmark HTTP API (X-Postmark-Server-Token), or both.
Webhooks — delivery/bounce/open/click, and their consumers.
Volume at average and peak, for warm-up planning.

Step 1 — Create your Mailer To Go sending domain

Sign up at mailertogo.com and add a sending subdomain — we recommend mtg.yourdomain.com. It isolates your reputation and, if you delegate it, lets us manage the DNS. See Why Mailer To Go sends from mtg.yourdomain.com.

Step 2 — Authenticate (SPF, DKIM, DMARC)

Publish the SPF and DKIM records from your dashboard, plus a DMARC policy. You did the equivalent in Postmark (DKIM + Return-Path), so this is familiar — just new values. Keep both providers authorized on the domain during the overlap. Full walkthrough with dig verification: Email authentication, end to end.

Step 3 — Swap your credentials

SMTP. Postmark’s tell is smtp.postmarkapp.com with your Server API Token used as both username and password. Point the same mailer at Mailer To Go instead:

# Before — Postmark
host: smtp.postmarkapp.com   port: 587
username: <Server API Token>
password: <Server API Token>

# After — Mailer To Go
host: smtp.mailertogo.com   port: 587   (or 465 for SSL)
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.mailertogo.com
  port:            587,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true
}

API. If you call Postmark’s HTTP API, the lowest-effort move is to point your mailer at Mailer To Go over SMTP (least code). Full language-by-language examples: Send email with Mailer To Go.

Step 4 — Import your suppression list (do not skip)

Export suppressions from Postmark before cutover — from the dashboard, or via the API per message stream:

curl "https://api.postmarkapp.com/message-streams/outbound/suppressions/dump" \
  -H "Accept: application/json" \
  -H "X-Postmark-Server-Token: $POSTMARK_SERVER_TOKEN" > postmark-suppressions.json

Load those addresses into your Mailer To Go suppression list so anyone who bounced or complained on Postmark is never emailed again.

Step 5 — Warm up and cut over gradually

A new sending domain has no reputation yet, so don’t flip everything at once. Run both providers in parallel and shift traffic in stages (10% → 25% → 50% → 100% over a week or two), starting with your most engaged mail (password resets, receipts). Watch bounce and complaint rates at each step, and keep Postmark ready to take traffic back until you’re fully cut over.

Step 6 — Verify, then decommission

Send tests and confirm SPF, DKIM, and DMARC all PASS (Gmail → Show original).
Repoint your webhooks at your Mailer To Go event handlers and confirm bounce/complaint events flow.
Once 100% runs clean through Mailer To Go for a few days, close your Postmark servers — but leave Postmark’s DNS records in place for a week or two as a rollback safety net, then remove them.

Rollback

Because the switch is credentials + DNS, rollback is fast: point your mailer’s environment variables back at Postmark. Keeping both providers authenticated during the overlap is what makes that a one-line change.

New to subdomain sending or authentication? Start with Why Mailer To Go sends from mtg.yourdomain.com and the SPF/DKIM/DMARC setup guide. Coming from a different provider? See the guides for SendGrid, Mailgun, and Amazon SES.