Core difference
Postmark is organized around servers and message streams. MailChannels is organized around sender governance for platforms with many senders: account or sub-account credentials, authenticated sending domains, runtime send payloads, webhooks, suppression types, and reputation boundaries. 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
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.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: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.