Core difference
Postmark is organized around servers and message streams. MailChannels is organized around account or sub-account credentials, authenticated sending domains, runtime send payloads, webhooks, and suppression types. The key migration decision is whether Postmark server and stream boundaries should become MailChannels sub-accounts, application metadata, or a simpler shared account model.Feature mapping
| Postmark concept | MailChannels concept | Migration approach |
|---|---|---|
| Server-scoped send API | /send payload | Replace server token sends with MailChannels API key sends. |
| Servers | Account or sub-account boundaries | Preserve server isolation only when it matters for credentials, reporting, or tenancy. |
| Message streams | Transactional flag and application metadata | Map transactional versus broadcast intent into send classification and suppression policy. |
| Server templates | Application-managed Mustache content | Export templates and move storage outside Postmark. |
| Sender signatures | from identities | Preserve sender addresses and align them with authenticated domains. |
| Sender domains | DKIM and Domain Lockdown | Recreate DNS authentication through MailChannels. |
| Webhooks and legacy hook URLs | MailChannels webhooks | Recreate event delivery and update payload consumers. |
| Message-stream suppressions | MailChannels suppression list | Collapse stream-scoped suppressions into account or sub-account policy. |
| Inbound processing | No MailChannels Email API equivalent | Replace inbound processing with another receiving architecture. |
Send payload notes
Postmark send calls often carry server and stream intent through the token, endpoint, or message stream field. MailChannels sends should make equivalent intent explicit in account selection, sub-account selection, send classification, and application metadata.| Concern | Postmark behavior | MailChannels behavior |
|---|---|---|
| Authentication | Account token or server token | MailChannels API key authentication |
| Isolation | Server boundary | Account or sub-account boundary |
| Stream type | Transactional or broadcast streams | transactional send behavior and suppression policy |
| Templates | Server templates | Application-owned content plus runtime data |
| Inbound | Server inbound processing and triggers | External receiving service |
Template migration
Export templates per Postmark server and preserve the server context in the new template naming scheme when needed. Replace Postmark template aliases or IDs in application code with application-owned template references.Suppression policy
Recommended defaults:| Postmark source | MailChannels target |
|---|---|
| Hard bounces and spam complaints | Suppress as both transactional and non-transactional. |
| Broadcast-stream manual suppressions | Suppress as non-transactional unless policy requires blocking all mail. |
| Stream-scoped suppressions | Preserve isolation with sub-accounts only when stream boundaries are operationally important. |
Inbound migration
Postmark inbound processing and inbound rule triggers do not have MailChannels Email API equivalents. Replace those flows before cutover with a dedicated inbound provider, mailbox polling, or an application webhook receiver backed by another receiving service.Cutover checklist
- Decide how Postmark servers map to MailChannels account boundaries.
- Replace server-token authentication with MailChannels API keys.
- Translate message stream intent into send classification and metadata.
- Move templates out of Postmark.
- Publish and validate MailChannels DKIM records.
- Recreate webhook consumers for MailChannels events.
- Replace inbound processing before production cutover.