Resend vs SendGrid

SendGrid is the incumbent. It's been the default answer to "how do I send email from my app" for over a decade, it's owned by Twilio, and it does everything: transactional API, marketing campaigns, contact management, template editor, dedicated IPs, sub-users, and enterprise agreements with the compliance paperwork attached.

Its problem is that all of that shows. The API is dated, the dashboard is heavy, the documentation is a maze of overlapping versions, and the onboarding involves account review and sender verification that can take real time. Free-tier and low-volume accounts have historically had a rougher deliverability experience than paid ones, because a large shared platform inevitably carries a mixed reputation.

Resend is the modern reimplementation of the transactional half. Small API, excellent docs, React Email for templates, domain verification in minutes, webhooks that are pleasant to consume, and a dashboard that shows you what you need. It does not attempt to be a marketing platform, and that focus is the product.

For a new application sending transactional email, Resend is the better developer experience by a wide margin and we'd recommend it by default.

For an organisation that needs campaigns and transactional in one contract, with enterprise support and procurement-friendly terms, SendGrid remains the more complete offering.

If cost per message is the binding constraint at high volume, both lose to Amazon SES, which is roughly a tenth of the price and gives you a fraction of the product.

Our killer field on the email hub is time-to-first-send: signup to a real email in a real inbox, measured. It's a proxy for something less measurable — how much of the product is designed for the person integrating it.

Resend measures in minutes. Sign up, add a domain, paste three DNS records, send. There's a shared onboarding domain if you want to test before DNS propagates, and the SDK call is three lines.

SendGrid measures in hours to a day, sometimes longer. There's sender identity verification, an account review that can flag new accounts, and API key scoping to configure. None of it is unreasonable — it's the machinery of a platform that has spent a decade being abused by spammers — but it is friction, and it is friction concentrated in the first hour of your experience.

The documentation difference compounds it. SendGrid's docs cover multiple API versions, several SDKs at different maturity levels, and a marketing product entangled with a transactional one. Finding the current way to do a thing takes longer than doing it. Resend's docs are one version of one product.

This is a one-time cost, so weigh it appropriately against a decision you'll live with for years. But it does correlate with how the rest of the integration will feel.

SendGrid offers a visual template editor with a versioning system, dynamic templates using Handlebars, and a drag-and-drop designer aimed at marketers. If someone who isn't an engineer needs to change email copy without a deploy, this is a real advantage and Resend has no equivalent.

Resend's answer is React Email — templates as React components in your repository. They're type-checked against the data you pass, previewed locally, reviewed in pull requests, and they share your design tokens. For engineering-led teams this is strictly better: emails stop being a separate untested artefact and become part of the codebase.

The cost is that changing a word requires a deploy, and a non-technical colleague cannot fix a typo at 6pm.

The architecture that resolves this cleanly: transactional emails as code, because they're part of the product and should be reviewed like it; campaign emails in a marketing tool, because they change constantly and shouldn't need engineers. That splits the vendors, which is fine — the two use cases have almost nothing in common beyond the SMTP protocol.

Both support attachments, custom headers, tags and per-message metadata that flows into webhooks. Both handle unsubscribe headers, which since the 2024 bulk-sender requirements is not optional for anything remotely promotional.

Deliverability is mostly determined by your own behaviour: list hygiene, bounce handling, engagement, and a properly configured sending domain with SPF, DKIM and a DMARC policy. Do those badly and no vendor saves you.

Where the platform matters is shared IP reputation. SendGrid is enormous, which means its shared pools carry the aggregate behaviour of a very large and very mixed customer base. Established paid accounts generally sit in better-managed pools; low-volume and free-tier accounts have historically had a noisier experience. Dedicated IPs are available and are the standard fix above roughly fifty thousand messages a month, at which point you're managing your own reputation and warmup.

Resend's pools are younger and smaller, with a customer base skewed toward transactional senders, and its deliverability is generally reported as good. Dedicated IPs are available on higher plans.

The structural point worth understanding: mailbox providers now weight the sending domain's reputation more heavily than the IP's. That change has narrowed the practical difference between providers considerably, and it means your own domain's history is the asset you're building. Which is also why you should think carefully before sending marketing blasts from the same domain as your password resets — use a subdomain, and keep the reputations separate.

Both price per message with plan tiers. Resend's free tier is more generous and its entry pricing is lower. SendGrid's advantage appears at high volume and in negotiated enterprise contracts, where a Twilio-scale vendor can do things a startup can't.

Check log and event retention on whichever plan you're considering. It's the field that differs most between tiers and it's invisible until support asks whether a customer received something six weeks ago. Short retention makes a support workflow impossible, and you generally find out at the worst time.

At genuinely high volume — millions of messages a month — the economics change. Amazon SES is roughly a tenth of the price of either, and what you give up is real: a sandbox exit ticket before you can send to arbitrary addresses, no template system worth using, bounce and complaint handling you assemble yourself out of SNS topics, and a dashboard that tells you very little.

The architecture large senders converge on is SES for bulk volume plus a premium provider for the messages that absolutely must arrive. Two reputations to manage and two integrations to maintain, justified only by the size of the bill it avoids.

Below that scale, pick on developer experience and product fit — the price difference between these two will not be what determines your margins.