React Email 6.0 just shipped: an open-source visual editor and what it means for your stack. Alex Rivera Frontend Engineer Published May 12, 2026 On April 17, Resend shipped React Email 6.0 - the biggest update to the framework since it went open source. The headline feature is an open-source visual editor you can embed in your own app, but the release also unifies the package layout, ships a new template collection, and crosses 2 million weekly npm downloads (a 108% jump in five months). For anyone building transactional or lifecycle email in a React codebase, this is the upgrade to plan for this quarter. I spent the last week migrating a small React Email project from 5.x to 6.0 and integrating the new editor into an internal admin panel. Here's what's actually different, what to watch for in the upgrade, and the parts of the workflow where you still need a cross-client testing tool. What's actually new in 6.0. An open-source visual editor you can embed. The standout feature is @react-email/editor - an open-source WYSIWYG editor you install separately and drop into your own app with a few lines of code: import {EmailEditor} from "@react-email/editor"; export default function MyEditor {return <EmailEditor />;} The editor outputs the same semantically correct, table-based HTML that the React components produce. The point is not to replace the developer authoring loop - it's to let your marketing team tweak copy, swap images, and adjust layouts on templates a developer originally built in code, without round-tripping through engineering for every microcopy change. This is a meaningful gap closer. Most engineering-led teams using React Email today either lock marketers out of the templates entirely or maintain a parallel set of templates in their ESP for the marketing side to edit. Neither is great. An embedded editor that produces the same HTML the code produces is the bridge. One package to import from. The component library is now unified into a single react-email package. The pre-6.0 setup with @react-email/components, @react-email/render, and a separate preview-server is collapsed: // Before (v5) import {Button, Container, Html} from "@react-email/components"; // After (v6) import {Button, Container, Html, Heading, Tailwind} from "react-email"; What was @react-email/preview-server is now @react-email/ui. The render function still lives at @react-email/render for now and is unchanged - your existing render scripts (like the one in last week's cross-client testing guide) keep working with no edits. A new template collection. React Email 6 ships with a new set of starter templates designed by Character Studio, covering authentication flows, e-commerce sequences, and onboarding. They're available both as React Email components and as Figma source files - useful if your designer wants to iterate in Figma and hand off to engineering with a clean baseline. Growth signal: 2M weekly downloads. The framework now does ~2M weekly npm downloads and counts 196 open-source contributors. For context, that's roughly a doubling since the previous major release in late 2025. Whatever you think about React Email as a tool, it's now the dominant authoring framework for transactional email at React-shop SaaS companies, and that gravity will only grow. The upgrade path from 5.x. The good news: the v5 | v6 path is mechanical for most projects. Here's the playbook. 1. Swap the imports. Run a project-wide find-and-replace from @react-email/components to react-email. The component APIs themselves are unchanged, so a clean string swap usually does it. npm uninstall @react-email/components @react-email/preview-server npm install react-email@latest @react-email/ui@latest 2. Update the preview-server scripts. If you had email dev wired up via the old preview-server package, the binary now comes from @react-email/ui. Most package.json scripts will need a one-line update - check the docs for the exact command for your setup. 3. Don't install the editor yet if you don't need it. The editor is a separate install (@react-email/editor). It pulls in additional dependencies and is only worth adding if you actually plan to expose template editing to non-developers. For pure code-authoring teams, skip it and your bundle stays the same size as v5. 4. Test the rendered HTML, not just the dev preview. This is the bit that bites people on every React Email upgrade. The component implementations get small tweaks between major versions - usually for the better - but those tweaks change the output HTML in ways that can render differently in Outlook, Gmail dark mode, or older Apple Mail. The dev server's Chromium preview won't show you any of those changes. Run your render script and diff the output HTML between v5 and v6 before deploying. Then preview the v6 output in actual client renderers. What 6.0 doesn't solve. The new editor is a real step forward, but it doesn't change the fundamental rendering reality of email: every client interprets your HTML differently, and a tool that compiles to HTML - no matter how good - can't see the inside of the client's renderer. A few specific things React Email 6.0 still won't do for you: It still can't show you Outlook desktop. The editor and the preview server both render in Chromium. Classic Outlook on Windows uses the Word rendering engine, which strips most modern CSS. If your template uses border-radius, gradient backgrounds, web fonts, or any of the dozen properties Outlook silently drops, the editor will show you the polished Chromium rendering and Outlook will show your subscribers something completely different. The caniemail.com scoreboard is a useful reality check on which clients support which features: It still can't catch dark-mode inversions. Apple Mail and Outlook both auto-invert email colors in dark mode using heuristics that vary by client and OS version. A grey background you chose for hierarchy can flip to dark grey while the dark text on top stays dark - leaving an unreadable block your editor preview never showed. You need to test in actual dark mode in actual clients to catch this. It still can't simulate image-blocking. Many corporate Outlook installs and the Gmail web preview block images by default. The editor shows you the fully-loaded version. Your alt text, fallback text colors on image backgrounds, and the readability of the email-without-images need to be tested separately. It still can't show real client market share. Editor previews are Chromium. They don't tell you that Apple Mail handles ~55% of opens globally, that Gmail is ~30%, and that Outlook desktop is a much smaller (but stickier) ~5-8%. Knowing which renderers matter most for your specific audience is what lets you triage rendering bugs sensibly. How this fits with your existing workflow. * Upgrade the package on a feature branch. Mechanical import rewrites + dependency swap. * Re-render every template with your existing render script. Diff the output HTML against your v5 baseline. * Visually QA the v6-rendered HTML in Postdrop or your tool of choice across Gmail, Outlook (classic and new), Apple Mail, and any clients with material share for your audience. The output is going to be slightly different - make sure "different" is also "still correct." * Decide on the editor separately. If you have a marketing or lifecycle team that owns template copy, set up a small admin route with @react-email/editor and let them iterate without engineering as a bottleneck. If you don't, skip it. * Re-snapshot in CI. If you're running snapshot tests against your rendered HTML (and you should be), accept the new baseline once you've manually verified the v6 output. From there, future regressions surface in code review. Bottom line. React Email 6.0 is an unambiguously good release: a thoughtful editor, a cleaner package surface, and useful new templates. For React-stack teams, it lowers the barrier to letting non-developers safely touch email templates - which has been one of the longest-standing pain points in the workflow. What it doesn't do, and what no authoring framework can do, is render your HTML in the actual clients your subscribers use. The editor's Chromium preview is the same Chromium preview the dev server has always shown - and it's still not Outlook. Pair the upgrade with a real cross-client testing step and you'll catch the regressions before your customers do. Skip the testing step and 6.0 just gives you faster, prettier ways to ship the same Outlook bugs.

AhaSend vs SendGrid vs Resend vs Mailgun: which transactional email service is right for you? Mark Kraakman April 17, 2026 Choosing a transactional email provider is one of those infrastructure decisions that's easy to get wrong the first time. The differences between services aren't always obvious from pricing pages, and the factors that matter most - deliverability, support responsiveness, data residency - are hard to evaluate until you're already integrated. This article gives you a factual, side-by-side comparison of four services: AhaSend, SendGrid, Resend, and Mailgun. It covers pricing, infrastructure, developer experience, and a dimension that most comparison articles skip entirely - where your data actually lives. A quick overview. SendGrid is the oldest and now owned by Twilio. It started as a transactional email API and grew into a full platform covering both transactional and marketing email. The platform is extensive, pricing is split across two separate products (Email API and Marketing Campaigns), and the free tier was changed from a permanent plan to a 60-day trial. Resend is the newest entrant, built with a strong developer-experience focus. It's popular in the React and Next.js ecosystem. Data is processed through US infrastructure. Mailgun is a long-standing developer-focused API, now owned by Sinch. It supports both US and EU data regions. Its free tier is limited to 100 emails per day. AhaSend is a European transactional email service built on KumoMTA, incorporated in the Netherlands, with ISO27001 certification pending, and operates under GDPR. It focuses exclusively on transactional email, with a developer-first API, official SDKs, SMTP relay, and a feature set built around deliverability and compliance. Pricing comparison. Pricing as of April 2026. | / | AhaSend | SendGrid | Resend | Mailgun | | Free tier | 1,000 emails/mo, permanent | 100 emails/day trial | 3,000 emails/mo, permanent | 100 emails/day | | Entry paid plan | €10/mo (25,000 emails) | $19.95/mo (50,000 emails) | $20/mo (50,000 emails) | $15/mo (10,000 emails) | | Full plan | €80/mo (100,000 emails) | $89.95/mo (100,000 emails) | $90/mo (100,000 emails) | $90/mo (100,000 emails) | | Overage rate | €0.45/1,000 (max $0.50 USD) | variable, plan-dependent | $0.90/1,000 | $1.10-$1.80/1,000 | | Dedicated IP | Accessible at 100k/mo (Pro), included at 300k+ | Add-on from $30/mo | Add-on from $30/mo (Scale+) | Included on Foundation+, add-on $59/IP/mo | A few things worth noting on pricing: SendGrid's free tier changed in early 2025. New accounts now get a 60-day timed trial rather than a permanent free plan. If you want a free tier you can actually build on without a clock running, the other three options are better starting points. Mailgun's entry plan starts at $15/month for 10,000 emails. The Scale plan at $90/month for 100,000 emails is the relevant full-plan comparison, which puts it on par with AhaSend Max and Resend Scale on volume but at a higher overage rate. Overage rates on Mailgun are the highest of the four. Resend and AhaSend are closely matched on full-plan pricing. AhaSend prices in euros but also offers USD pricing, which is a natural fit for European businesses billing in euros. Where they diverge is on overage: Resend charges $0.90 per 1,000 additional emails, while AhaSend's overage is €0.45 (max $0.50 USD) - roughly half the cost. Infrastructure and deliverability. All four services offer high-quality shared delivery infrastructure. The meaningful differences are in how they manage shared pools and when dedicated IPs become available. If you want to understand what poor infrastructure actually costs your business, AhaSend wrote about that here. SendGrid's shared infrastructure is extensive but has historically attracted complaints in user reviews about shared IP reputation degradation. Dedicated IPs are available as an add-on on paid plans. Resend actively manages its shared IPs and positions them as high quality for most senders. Dedicated IPs are available on the Scale plan for senders exceeding 500 emails per day. Mailgun includes a dedicated IP on its Foundation plan and above, making it one of the earlier access points for dedicated sending infrastructure. Additional IPs cost $59/month each. AhaSend runs high-quality shared delivery tiers for most senders, with dedicated IP access opening at 100,000 emails per month on the Pro plan and one dedicated IP included in the Max plan. The infrastructure runs on KumoMTA, the same engine used by some of the largest commercial senders globally, and is built for high availability with geo-redundant architecture across Europe. Developer experience. All four services offer REST APIs, SMTP relay, and webhook support. The differences are in SDK quality, documentation, and how quickly you can get from signup to first send. Resend has a strong developer experience reputation, particularly in the React and Next.js ecosystem. Its TypeScript SDK is well-regarded and documentation is clean. That said, its focus is narrow - if you're not building in the React ecosystem, the differentiation is less meaningful, and the platform lacks some of the operational depth that more established services offer. SendGrid has the most comprehensive API coverage and the widest range of official SDKs, but the platform's age shows in places. The dashboard can be complex to navigate, and the split between Email API and Marketing Campaigns products creates confusion for new users. Mailgun has a solid API with good documentation and detailed delivery logs. It doesn't have the same modern developer-experience polish as Resend, but it's reliable and well-understood. AhaSend offers official SDKs in Go, with JavaScript/TypeScript and Ruby in progress. The API is REST and SMTP, with a full Management API, sandbox mode, scoped API keys, inbound email routing, and signed webhook endpoints available across all paid plans. Setup to first send is documented as under five minutes. One feature worth calling out specifically is subaccounts - AhaSend supports isolated subaccount environments within a single account, which is particularly useful for agencies, hosting providers, or SaaS platforms managing email infrastructure on behalf of multiple clients. This is uncommon in the transactional email space. Data residency and GDPR. This is the dimension most comparison articles skip, and for European businesses it's increasingly the deciding factor. SendGrid is a US company (Twilio) with US-based infrastructure. Customer data is processed in the United States. GDPR compliance is possible through contractual means, but data leaves European jurisdiction. Resend is a US company with US-based infrastructure. The same applies. Mailgun is owned by Sinch (Swedish company) and does offer an EU data region as a sending option. This is a meaningful differentiator compared to SendGrid and Resend for European senders who need data to stay in the EU. AhaSend is incorporated in the Netherlands as AhaSend B.V. and operates exclusively on European infrastructure. Data stays in Europe. GDPR compliance is built into the product, not added as a contractual layer. For transparency: AhaSend does offer an optional US egress node for customers who need it - email may transit this node for delivery purposes, but is never stored outside Europe. For European businesses operating under GDPR, this removes a layer of legal complexity and vendor dependency risk. Summary: who should use what. SendGrid makes sense for high-volume senders who are already integrated, who need the full marketing + transactional combination on one platform, or who are building on US infrastructure and have no data residency requirements. Resend makes sense for developer teams working in the React/Next.js ecosystem who prioritize developer experience and clean API design, and who are comfortable with US-based data processing. Mailgun makes sense for developers who want a proven, stable API with predictable pricing and don't need a modern developer experience, or who need US/EU region flexibility without moving to a fully European provider. AhaSend makes sense for European businesses and developers who want their transactional email infrastructure to stay in Europe - whether for GDPR compliance, sovereignty reasons, or simply because they prefer working with a European vendor in their timezone. It's also well-suited to developers who value a focused, transactional-only product without the complexity of a combined marketing platform. And on pricing, particularly at scale, AhaSend is hard to ignore: with the lowest overage rate of the four and a straightforward plan structure, the cost difference compounds quickly as volume grows. Looking for a deeper comparison? See its dedicated pages for AhaSend vs SendGrid and AhaSend vs Mailgun.