Moving from Postmark to Pharos

The order the work happens in.

1. 01

   Export the suppression list

   Pull every suppressed address out of Postmark before anything else changes.

2. 02

   Verify the domain on Pharos

   Add four DNS records alongside the ones already there. Both providers stay authenticated.

3. 03

   Move the send call

   Point the application at POST /v1/send or the SMTP relay, behind whatever flag you use.

4. 04

   Ramp the traffic

   Move a share of sending across, watch the events, increase it. No cutover window is required.

5. 05

   Repoint the webhook and clean up DNS

   Move the event consumer, then remove the Postmark records once nothing depends on them.

Steps two and three are reversible and can overlap for as long as you like. An SPF record may name both providers, DKIM selectors are independent of one another, and the single DMARC record does not change at any point. That is what makes a phased migration possible: there is no moment where the domain is authenticated for the new provider and not the old one.

Step 1 — export the suppression list.

One call per stream, with that server’s token. The reason field is the part worth keeping: HardBounce, SpamComplaint and ManualSuppression mean different things on the way in, and flattening them to one list throws away the distinction that tells you which addresses may ever be reactivated.

# list the streams on this server
curl -s "https://api.postmarkapp.com/message-streams" \
  -H "Accept: application/json" \
  -H "X-Postmark-Server-Token: $POSTMARK_SERVER_TOKEN" \
  | jq -r '.MessageStreams[].ID'

# dump one stream's suppressions, keeping the reason
curl -s "https://api.postmarkapp.com/message-streams/outbound/suppressions/dump" \
  -H "Accept: application/json" \
  -H "X-Postmark-Server-Token: $POSTMARK_SERVER_TOKEN" \
  | jq -r '.Suppressions[] | [.EmailAddress, .SuppressionReason] | @csv' \
  >> suppressions.csv

# repeat for every stream, on every server token you hold

Import the whole file. Every address on it should arrive at Pharos suppressed, and the ones marked SpamComplaint should never be reactivated by anyone, on either side.

Pharos suppresses an address automatically on a hard bounce and on a complaint, keeps the list per account, and lets you export it again whenever you like — including on the way out, if this page ever needs writing in the other direction. The difference between a hard and a soft bounce decides which addresses end up on it.

Steps 3 and 4 — move the call, then the traffic.

The send call is plain HTTP. There is no SDK to install and nothing to import, which means the change in your application is a URL, a header and a body shape rather than a dependency.

curl -X POST https://api.pharos.email/v1/send \
  -H "Authorization: Bearer $PHAROS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-4471" \
  -d '{
    "from": "receipts@yourdomain.com",
    "to": "customer@example.com",
    "subject": "Your receipt",
    "html": "<p>Thanks for your order.</p>"
  }'

If you would rather not touch application code at all, point your existing mailer at the SMTP relay on smtp.pharosinfra.net:587 with STARTTLS. Same pipeline, same events, and a migration that is four lines of configuration. The Idempotency-Key header matters more during a migration than at any other time: a retry across a half-switched deployment is exactly the situation that sends a password reset twice.

Then ramp. Send a percentage, read the events, raise it. There is no warmup requirement to satisfy here — the sending IPs are dedicated to Pharos and already have a reputation — but ramping is still how you find the template that renders wrong or the address list nobody had cleaned, at a volume where finding it is cheap.

When to stay on Postmark.

Four reasons not to do any of the above. They are here because you would find them during the migration otherwise, and finding them then costs a great deal more than reading them now.

• You send broadcast mail on a broadcast stream

  Message streams let one account carry transactional and bulk mail with separate reputations. Pharos has no equivalent because it carries transactional mail only. If you use both streams, only one of them has anywhere to go here.

• You process inbound mail

  Inbound servers, inbound domain forwarding and inbound rules have no counterpart on Pharos. Nothing about this migration should involve deleting an MX record that something else depends on.

• Your templates live in their editor

  Pharos has versioned templates, but there is no importer. Templates authored and maintained in Postmark’s editor are a manual re-entry job, and the time that takes belongs in the decision rather than in a surprise during the cutover week.

• Nothing is wrong

  Postmark has run transactional mail for well over a decade and refuses bulk mail on principle, which is the same principle Pharos is built on. If your mail arrives, your support questions get answered and the bill is not the problem, the honest advice is to stay. A migration costs a week and buys you nothing you do not already have.

Pharos carries transactional mail only — mail a recipient's own action caused. That single constraint is the reason for most of the gaps above, and it is written down in the acceptable use policy rather than discovered at suspension time.