Skip to main content

​
Core difference

Resend provides a modern send API for a team’s own mail, with domains, templates, contacts, broadcasts, audiences or segments, webhooks, and receiving-related event signals. MailChannels is built for platforms where users, tenants, customers, or agents are the senders. It adds authenticated outbound delivery, runtime personalization, DKIM, Domain Lockdown, webhooks, sender isolation, and explicit suppression types so you can contain abuse without taking down good senders. Resend broadcast and inbound receiving workflows need separate replacements.

​
Feature mapping

​
Send payload notes

Resend send requests are straightforward, but MailChannels uses its own personalization-centered payload and authentication.

​
Template migration

Export Resend templates and replace template references in application code with application-owned template names, files, or records. Keep the runtime variable contract explicit so the MailChannels payload provides every value required by the new renderer.

​
Suppression policy

Recommended defaults:

​
Marketing migration

MailChannels Email API does not provide a Resend broadcast or audience store. Move broadcast planning, segmentation, approval, and scheduling into an external workflow. Use MailChannels as the governed delivery layer for permission-based messages that should move through shared-sender controls.

​
Inbound migration

Resend receiving and email.received workflows do not map to MailChannels Email API resources. Replace them with a dedicated inbound mail service or application-owned receiving architecture before changing production routing.

​
Cutover checklist

  • Replace Resend endpoint and authentication.
  • Translate send payloads into MailChannels personalizations.
  • Move templates out of Resend.
  • Publish and validate MailChannels DKIM records.
  • Recreate webhooks for MailChannels event payloads.
  • Replace broadcasts and audiences externally.
  • Replace receiving workflows before production cutover.