PostmarkvsResend

Postmark templates use Mustache for variable substitution. The dashboard has a drag-drop builder for marketing-style layouts and a code editor for raw HTML. Templates are versioned; you preview with sample data; A/B testing is supported. The mental model is 'design templates separately, send by template ID.'

Resend's headline feature is React Email — a component library where you write templates in JSX (<Email><Heading>{title}</Heading><Button href={...}>Confirm</Button></Email>). The components handle email-client quirks for you (Outlook table layouts, Gmail dark mode). Templates live in your codebase, version with your repo, type-check.

Postmark provides per-recipient delivery reports, bounce-type classification (hard, soft, transient), spam-complaint tracking, and a deliverability dashboard that scores your sender reputation. The 'inbox or spam' question is answerable from their tools alone.

Resend provides delivery, bounce, and spam-complaint events via webhooks and the dashboard. The reputation tooling is less detailed — you see what happened to each email, but the macro 'are we trending well or badly' view is thinner than Postmark's.

Postmark requires you to use 'message streams' — Transactional and Broadcast are separate, with separate sender reputation. Marketing emails sent through Transactional get blocked. The discipline is enforced by the platform, which is part of why deliverability stays strong over time.

Resend doesn't enforce a separation. You decide which emails are transactional, which are broadcasts, and how to manage their respective sender reputation. The freedom is real and so is the rope.

Postmark emits webhooks for all major events (delivery, bounce, open, click, spam complaint, subscription change). Signing is HMAC. Rate limits are generous. The event payload is well-documented and stable across versions.

Resend emits the same set of events with HMAC signing. Webhook UX is polished — replay button in the dashboard, signed payloads validated by the SDK. The set is identical to Postmark in practice.

Postmark's inbound is mature: parses MIME, attachments, threading headers, original-recipient resolution. You configure a parse address (e.g., support+inbound@yourdomain.com), point an MX record, receive a webhook on each email. Used heavily for support workflows and reply-to-thread features.

Resend's inbound parsing covers the same use case — set up an inbound address, receive a webhook with parsed body and metadata. Newer than Postmark's; the edge cases (calendar invites, encrypted attachments) are still maturing.

Postmark walks you through adding DNS records for a custom domain. SPF, DKIM, return-path are checked automatically. The dashboard shows the validation state per record. Brand tracking domain (for click links) is available on Pro tiers.

Resend's domain setup is similar — add DNS records, wait for validation, send from your domain. Validation UX is slightly cleaner; the documentation is among the best in the ESP space. Branded tracking domains are supported.

Postmark has SOC 2 Type II, GDPR, and HIPAA-eligible plans. The HIPAA tier is real (BAA available) and used by healthtech apps. Audit logs show who sent what when. Enterprise customers can SSO into the Postmark dashboard.

Resend has SOC 2 and GDPR. HIPAA-eligible plans are not yet available. Audit logs and SSO are present but younger. For consumer apps and most B2B SaaS this is fine; for healthtech it's a blocker.

Migrating from Postmark to Resend (or vice versa) is mostly an SDK swap and a domain re-verification. Templates need re-authoring (Mustache → React Email or vice versa). Sender reputation does NOT migrate — your new ESP starts you on a 'warm-up' pattern, sending small volume increasingly to build a fresh reputation.

The reputation reset is the real cost. For 30 days post-migration, deliverability often dips before recovering. Plan around it: don't migrate during a launch week, pre-warm the new ESP with low-stakes emails first.