Resend vs AWS SES vs Mailgun for Transactional Email

What you need to know

• Resend is the best developer experience in 2026 and the right choice for new projects using React or Next.js. The React Email integration is a meaningful productivity improvement.
• AWS SES is the cheapest option at scale and the right choice for high-volume senders already on AWS. The setup complexity is a one-time cost.
• Mailgun is the reliable middle ground for teams that need good deliverability without the AWS SES setup overhead.
• Configure SPF, DKIM, and DMARC before going to production with any service. Missing authentication records significantly reduce deliverability.
• Separate transactional and marketing email onto different sending domains or services to protect transactional deliverability.

The core argument

The transactional email service decision is usually not made deliberately. Teams pick the service with the most visible documentation when they need to implement password reset, and that service becomes the default for all email for years. The cost of that decision is typically only noticed when email volume grows and the pricing model that works at 1,000 emails per month is expensive at 100,000.

For new projects starting today, Resend is the most productive choice. The API is clean, the React Email library produces maintainable HTML email templates that do not involve fighting with table-based layouts, and the documentation for common patterns (Next.js integration, authentication flows) is excellent. Resend's pricing is competitive for the volumes typical of early-stage SaaS. The only scenario where Resend is not the right choice is very high volume where SES's per-email pricing produces a significant cost advantage.

The scenario for AWS SES is explicit: you are already on AWS, you are sending 100,000 or more emails per month, and you have the engineering time to set up and maintain the SES integration. At 100,000 emails per month, SES costs $10 per month. Resend at similar volume costs roughly $150 per month on the pro plan. The $140 per month savings may or may not justify the SES setup complexity depending on the team size and the value of engineering time.

Common mistakes

1. Not configuring DMARC. SPF and DKIM are commonly configured because the email service onboarding requires them. DMARC is often skipped because it is optional for sending but important for long-term deliverability and domain protection. Start with DMARC in monitoring mode (p=none) to identify authentication failures before switching to enforcement mode (p=reject). A DMARC policy that rejects unauthenticated email prevents domain spoofing.

1. Sending transactional and marketing email from the same IP pool. Marketing email generates more spam complaints and unsubscribes than transactional email. If both types share an IP, marketing email complaints degrade the deliverability of transactional emails (password resets, purchase receipts) that users need to receive. Separate transactional email onto a dedicated IP (usually available at higher plan tiers) or use separate services.

1. Not handling bounce and complaint webhooks. All three services send webhooks when emails bounce or generate spam complaints. Not processing these webhooks means continuing to send email to invalid addresses (which harms deliverability) and to addresses that have marked emails as spam (which violates CAN-SPAM and harms deliverability further). Process bounce webhooks to update email validity in the database and suppress future sends to bounced addresses.

1. Using the same domain for email and web without DMARC enforcement. A domain without DMARC enforcement can be spoofed: malicious actors can send emails that appear to be from your domain. Enable DMARC monitoring mode to understand the sending patterns before enabling enforcement, then move to enforcement to prevent domain spoofing.

1. Not testing email rendering across clients. Email clients render HTML differently. An email that looks correct in Gmail may look broken in Outlook 2019. Services like Litmus and Email on Acid provide cross-client rendering previews. At minimum, test in Gmail, Apple Mail, and Outlook before deploying new email templates.

Where to start

1. Choose the service and configure DNS records before writing any email code. SPF, DKIM, and DMARC records require 24 to 48 hours to propagate. Configure them at the start of the project so authentication is in place before the first email is sent.

1. Implement a bounce and complaint webhook handler on day one. Before sending to real users, implement the webhook endpoint that receives bounce and complaint notifications and updates a suppression list in the database. This prevents future sends to invalid or complaining addresses from the start.

1. Build the first email template in React Email (for Resend) or use a template library. Writing HTML emails from scratch in 2026 involves fighting against email client quirks. React Email (Resend), MJML (Mailgun), or a similar abstraction handles the email client compatibility issues and produces responsive, well-rendered emails from readable component code.

Related reading

• Resend vs Postmark vs SendGrid vs Mailgun
• Pylon vs Plain vs Front for Modern Customer Support
• Push Notifications: The Architecture Most Apps Get Wrong
• Lead Pipeline Automation: From Form to CRM Without Touching It