Migrating from another provider
Three steps. The second one is the one people skip and the one that matters.
1. Point your code at us
The request shape is deliberately the same as what you already have, so this is usually a base URL and a key rather than a rewrite.
From SendGrid, Resend, Postmark or Mailgun over SMTP: change the host, username and password. Nothing else.
| Setting | Value |
|---|---|
| Host | smtp.postrun.dev |
| Port | 465 or 587 |
| Username | postrun |
| Password | your API key |
Over HTTP: point the base URL at https://api.postrun.dev and swap the key.
The field names — from, to, subject, html, text, cc, bcc,
reply_to, headers, attachments, scheduled_at — are the ones you are
already sending.
2. Import your suppression list
Do this before your first send.
Your old provider has been quietly refusing to mail addresses that hard-bounced or marked you as spam. That list does not come with you. If you start sending without it, your first campaign mails every dead address you have accumulated — and a bounce spike on day one is the single fastest way to damage your sending reputation, on a brand-new account with no history to absorb it.
Export the list and paste it into Suppressions → Import. Header rows and blank lines are skipped, so you can paste a raw export without cleaning it up.
Where to find it:
| Provider | Where |
|---|---|
| SendGrid | Suppressions → Global Unsubscribes, plus Bounces and Spam Reports |
| Resend | Suppressions → export |
| Postmark | Suppressions tab, per message stream |
| Mailgun | Suppressions → Bounces / Complaints / Unsubscribes |
Import all of them. An address that bounced permanently and an address that complained are both addresses you must not mail again.
3. Consider a dedicated sending domain
Your existing domain works exactly as it does today if you copy three DKIM records — the third row of the table in the quickstart, and what every provider asks of you.
But if you use a separate domain for sending and point its nameservers at us, that is the last DNS work you will ever do for email. Key rotation, tracking subdomains, DMARC policy changes and anything we add later all happen without touching a zone of yours again.
This takes over all of that domain’s DNS. Use one that is not used for anything else. We check and warn before you switch, but a domain with a website or mail on it will break when the change propagates.
Two reasons it is worth doing at migration time rather than never:
- You are already in the DNS console.
- A separate sending domain keeps transactional reputation off the domain your
team emails from. A bad bounce week then costs you deliverability on
mail.acme.com, not on the address your CEO writes from.
If you do not have a spare domain, you can register one with us and skip the nameserver step entirely — it lands in the first row of that table.
What changes
Your daily limit starts low. A new account is capped and rises automatically as delivery history builds. This is not a judgement about you — it is how a shared sending reputation stays intact when anyone can sign up, and it means you never have to ask for a limit increase. If you are migrating real volume and cannot wait for the ramp, tell us.
Rejections happen earlier. A suppressed recipient is refused when you send,
not silently accepted and bounced later. Your code sees a suppressed error
instead of a delivery that never happens.
Errors carry a stable slug. Branch on name — validation_error,
rate_limit_exceeded, quota_exceeded, suppressed — not on the prose, which
may be reworded.