{"id":562,"date":"2026-11-14T01:46:48","date_gmt":"2026-11-14T07:16:48","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=562"},"modified":"2026-11-14T08:47:53","modified_gmt":"2026-11-14T14:17:53","slug":"migrating-from-postmark-streams-templates-and-cutover","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/migrating-from-postmark-streams-templates-and-cutover\/","title":{"rendered":"Migrating from Postmark: Streams, Templates and Cutover"},"content":{"rendered":"\n

The migration goes cleanly. Templates ported, credentials swapped, delivery rates holding. Nobody notices anything for about three weeks.<\/p>\n\n\n\n

Then a customer says they never received a password reset. Then another. You check, and your transactional mail is landing in spam at Gmail \u2014 not because anything broke, but because the monthly newsletter you now send down the same pipe has been quietly teaching Gmail that this sending identity is bulk mail.<\/p>\n\n\n\n

Postmark was preventing that. Not as a feature you configured, but as an architecture it enforced. It is the one thing that does not survive the move unless you deliberately rebuild it.<\/p>\n\n\n\n

Quick Answer: What Moves and What Rebuilds<\/h2>\n\n\n\n
Asset<\/th>Moves or rebuilds<\/th>Effort<\/th><\/tr><\/thead>
SMTP credentials<\/td>Moves \u2014 four variables<\/td>Minutes<\/td><\/tr>
Templates<\/td>Export into your repository<\/td>Hours<\/td><\/tr>
Suppression data<\/td>Export per stream, import first<\/td>Before first send<\/td><\/tr>
MessageStream<\/code> references in code<\/td>Remove or remap<\/td>Hours<\/td><\/tr>
Webhooks<\/td>Remap payloads and verification<\/td>Hours<\/td><\/tr>
Stream separation<\/strong><\/td>Rebuild yourself, with subdomains<\/strong><\/td>The real work<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Everything above the last row is an afternoon. The last row is the migration.<\/p>\n\n\n\n

Sequencing\u2014DNS TTL, SPF lookup limits, the percentage ramp, rollback \u2014 is covered in our guide to migrating email providers without downtime<\/a>. Follow that ordering alongside this.<\/p>\n\n\n\n

What Postmark Was Doing For You<\/h2>\n\n\n\n
\"Postmark's
Two reputations become one. That is the risk, and it is invisible for weeks.<\/figcaption><\/figure>\n\n\n\n

Most providers treat separating transactional from marketing mail as a best practice you may choose to follow. Postmark treats it as a property of the system.<\/p>\n\n\n\n

Its message streams documentation<\/a> states plainly that “transactional and broadcast traffic do not mix in Postmark, including IP ranges.” There is a dedicated transactional IP pool and a dedicated broadcast IP pool, and a message goes down one or the other depending on which stream you send it to.<\/p>\n\n\n\n

So if you have been sending password resets through a transactional stream and a newsletter through a broadcast stream, those two have been running on separate sending infrastructure the whole time. One could have a bad month without touching the other.<\/p>\n\n\n\n

Move to a provider that does not enforce that, send both through the same credentials, and the two reputations merge. Postmark’s own write-up on the subject<\/a> describes the failure mode: when you use the same servers and address for both, filters such as Gmail’s may start classifying all of it as bulk. It also cites Google’s own guidance to separate mail by purpose as far as possible \u2014 advice Gmail publishes for all senders<\/a>, not just Postmark customers.<\/p>\n\n\n\n

Common Mistake<\/p>\n\n\n\n

Treating stream separation as a Postmark feature rather than an email architecture. It reads like vendor functionality, so it gets dropped from the migration plan along with the stream API \u2014 and because reputation damage accumulates over weeks rather than appearing on cutover day, the migration looks like a success right up until transactional deliverability starts sliding. By the time anyone connects the two, the newsletter has been training receivers on your sending identity for a month. Rebuild the separation before the first marketing send, not after you see a problem.<\/p>\n\n\n\n

Streams Are Not Just a Routing Label<\/h2>\n\n\n\n

Before you can remove them from your code, it helps to know exactly what you have.<\/p>\n\n\n\n

Stream type<\/th>What it carries<\/th>API value<\/th><\/tr><\/thead>
Transactional<\/td>One recipient, triggered by a user action<\/td>outbound<\/code><\/td><\/tr>
Broadcast<\/td>Many recipients, sent on your schedule; requires an opt-out link<\/td>broadcast<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Two details catch people out.<\/p>\n\n\n\n

First, the default transactional stream’s API value is outbound<\/code>, not transactional<\/code><\/strong>. If you are grepping for stream references by name, searching for “transactional” will miss most of them.<\/p>\n\n\n\n

Second, a Postmark server supports up to 10 streams. Accounts that have been running for a few years often have more than the two obvious ones \u2014 a separate stream for a legacy product, one somebody created for testing, one for a specific client. Enumerate them rather than assuming there are two.<\/p>\n\n\n\n

Quick Fix<\/p>\n\n\n\n

Finding Every Postmark Integration Point<\/p>\n\n\n\n