Resend Email

Resend is a strong email choice for a small product team that wants sign-ups, receipts and password resets connected to its application with little integration ceremony. The catch is production ownership: its free allowance stops at 100 emails a day, and your app must handle messages rejected by quotas. Choose Resend email for its developer workflow; choose your plan around peak demand and your provider around data requirements.

Verified against Resend's live pricing, documentation and security pages on 13 November 2026. This review evaluates documented workflows, limits and billing arithmetic; it does not claim signed-in testing or measured inbox placement.

What the Resend Email Platform Does

Resend is an email delivery service your application calls through an API, a programmatic interface, or SMTP, the standard mail-sending protocol. It sends individual event-triggered messages and marketing Broadcasts, manages contacts and templates, reports delivery events, and receives inbound email for your application to process. Your product still decides who should receive a receipt, whether a reset request is valid, and what to do when a message fails. The getting-started documentation describes the sending paths and supported language integrations.

Who Should Use It, and Who Should Skip It?

Resend fits founders and developers who want email to behave like another application service: version the template, supply event data, send the message, and handle the result. The strongest case is a small SaaS product where the same people own the application and its transactional emails.

The decision rests on integration effort, failure handling, marketing ownership and data constraints. It does not rest on an unsupported claim that one provider lands more messages in the inbox.

Skip a migration if your existing provider works and you cannot name the problem Resend will solve. A tidier API is not, by itself, a reason to move established mail traffic. Postmark deserves the shortlist when separate sending infrastructure is a requirement; Amazon SES deserves it when your team wants to retain ownership inside AWS.

If a marketer will own onboarding journeys every day, compare Loops, which centers its product on SaaS lifecycle email. Resend now has Automations too, so the comparison should be the actual journey your operator needs to maintain, not an outdated claim that Resend only sends API messages.

Resend Alternatives: When Each Makes More Sense

Twilio SendGrid: prefer it when existing Email API, SMTP and Marketing Campaigns operations already meet your needs. Keep it unless the cost of maintaining that setup exceeds a specific migration benefit.

Postmark: prefer it when transactional and broadcast traffic separation is a deciding requirement. Its Message Streams documentation describes separate IP infrastructure; that is a concrete architectural distinction, not a promise of better results for your particular domain.

Mailgun: shortlist it when email validation and routing sit alongside sending in your requirements. Those additional tools matter more for that buyer than a pleasant send-call syntax.

Amazon SES: prefer it when your engineers already own AWS operations and want to build email into that environment. Compare the whole implementation effort, including monitoring and incident handling.

Loops: prefer it when the buying decision starts with onboarding, activation and win-back journeys owned by a SaaS lifecycle operator. Demonstrate the same journey in both products before choosing.

For a broader campaign-platform decision, the GetResponse review covers a different buying problem from choosing an application's mail transport.

Resend Email API: From a Product Event to a Message

Resend's strongest capability is the short path between an application event and a templated message. Its Node.js SDK takes a sender, recipient, subject and content, then returns a result containing data or an error. Other documented quickstarts cover Python, PHP, Ruby, Go, Rust, Java and .NET; adopting the service does not require adopting React.

Consider a receipt after a successful payment. Your application records the payment, prepares the receipt data, asks Resend to send it, and stores the returned message identifier against that payment. A support person can then investigate the receipt without searching by a customer's name alone. The Node.js quickstart shows the underlying send operation.

Resend Email Templates: Choose Who Owns the Copy

React Email lets developers build email content from React components. Resend supports both code-owned messages and hosted templates; Resend's React Email integration guide documents local preview, HTML or plain-text output, and upload into hosted Templates.

For a receipt, keep the layout in code when changes should travel through application review. If someone outside engineering needs to correct the receipt wording, a hosted template can be a better boundary: the app supplies variables while the content owner edits the message. Resend's Templates documentation describes the editor, version history and sending by published template ID.

The payoff is a clear owner for each change. Neither approach means you should approve a password-reset email from a preview alone. Before launch, exercise the link, expiration behavior and content in the email clients your customers use.

Retries Need an Identity

Resend supports idempotency keys, identifiers that make a repeated send request return the original result instead of sending another email. The documented protection lasts 24 hours. For the receipt workflow, derive the key from the receipt event and keep the request content stable when retrying. The idempotency guide defines both the window and the error when the same key accompanies a different payload.

That window is a boundary your application must respect. A job replayed after it expires needs your own durable record of whether the receipt was already requested. Provider deduplication is useful protection during retries; it is not permanent business-event history.

SMTP Makes Existing Applications Easier to Move

Resend also fits an application that already speaks SMTP. Its SMTP settings specify smtp.resend.com, username resend, and the API key as the password. Port 465 uses implicit TLS; 587 uses STARTTLS. Use the matching encryption setting in your mail client or framework.

This can preserve your existing email-generation code while changing the transport. The diagnostic tradeoff is specific: Resend says it does not provide SMTP server logs, although SMTP-sent messages appear in the Emails table. If connection-level debugging is a recurring requirement, account for that before migrating.

Domain Setup: Make Authentication Part of Launch

Resend requires a verified sending domain, and the setup belongs on the launch checklist beside the API integration. DNS, the system that publishes your domain's records, is where you authorize the service to send on your behalf.

SPF identifies permitted sending infrastructure. DKIM adds a cryptographic signature to messages. DMARC tells receiving systems how to handle messages that fail the domain's authentication policy. These are separate jobs; a green domain-verification badge does not replace deliberate DMARC configuration.

For a new SaaS product, a practical setup is:

1. 1

   Choose the sender and sending region

   Add a domain in Resend's Domains page. For a new sender, use a purposeful subdomain such as account.example.com; choose the sending region appropriate to your recipients.

2. 2

   Publish the generated records

   Copy Resend's DKIM and SPF configurations into your DNS provider exactly as shown. Verify the domain before connecting customer-facing sends. Avoid substituting a generic record copied from a tutorial.

3. 3

   Add DMARC and separate sending purposes

   Configure DMARC after verification. Consider a separate marketing subdomain so newsletter settings and transactional settings can be managed independently.

4. 4

   Preserve established reputation during migration

   If you already have an established sending address, plan the migration around that history. Resend recommends retaining an established address rather than automatically replacing it with a new subdomain.

The domain setup guide provides the sequence; the verified-domain guidance explains the migration exception and separate tracking settings. For a password reset, favor a clean, direct link over tracking every click merely because the setting exists.

Delivery Events and Inbound Mail: Close the Loop

Resend gives your application information after the send call, which is what makes the service useful when a customer says a receipt never arrived. Webhooks are HTTPS notifications sent to your application when events occur. Resend documents delivery, bounce, open and click events, request verification, replays and storing event data in your own database in its webhook guide.

For the receipt workflow, verify webhook requests, associate each event with the stored message identifier, and make event processing safe to repeat. A bounce should create an actionable customer-support state, not disappear into a log nobody checks. Keep that history in your own system if it must survive the provider's retention window.

Delivered does not mean seen in the inbox. Resend defines that status as delivery to the recipient's mail server. Its email-management documentation distinguishes delivered, bounced, delayed, failed and suppressed states. Use those distinctions when explaining a failure to a customer.

Deliverability Tools Help Diagnose; They Do Not Prove Placement

Resend's Deliverability Insights checks for issues such as domain mismatch in links, missing DMARC and missing plain-text content. These are useful checks on the message you control. They do not establish an inbox-placement percentage.

Its suppression list also prevents continued sends to addresses that hard-bounce or complain. The important boundary is team-wide suppression: an address on the list is skipped across your domains and subdomains for transactional and Broadcast mail. The suppression documentation also notes that Gmail/Google Workspace does not return complaint events.

For a combined marketing and transactional setup, that has a practical consequence: moving a suppressed recipient to a different sending subdomain will not restore their password-reset email. Investigate the suppression reason and provide an account-recovery path. Do not blindly remove the suppression and resend.

Receiving Email Is Documented, Too

Resend supports inbound email at a verified domain or its managed resend.app subdomain. The receiving guide describes webhook notifications, retrieving message content and attachments, forwarding, and threaded replies.

A useful workflow is a reply to an order receipt: associate the incoming message with the order, retrieve its content, then create a support task. Receiving infrastructure saves you from operating the mail intake yourself. You still own attachment handling, sender trust and what an incoming message is allowed to change in the product.

Broadcasts and Contacts: Keep Marketing Intent Explicit

Resend can serve a small team's newsletter and product announcements without making the developer build a campaign sender from scratch. Broadcasts offer an editor, scheduling, contact targeting and performance tracking. The Broadcasts guide describes both dashboard and API workflows.

For a feature announcement, import or add consenting contacts, put the intended recipients in a Segment, choose the appropriate Topic, prepare the message, check its unsubscribe behavior, and schedule the Broadcast. A Segment is your internal grouping; a Topic is a preference the recipient can control.

If an old integration refers to Audiences, update your assumptions. Resend now uses global Contacts and Segments: one email address can belong to several segments while counting as one Contact. Its Audiences migration guide says the Audiences API is deprecated. That matters when old code treats an unsubscribe as local to a particular audience.

Resend also documents Automations with custom triggers, conditions, delays and wait-for-event steps. A welcome sequence can therefore live in Resend rather than entirely in application code. Before moving a lifecycle program, map its actual triggers and exit conditions: being able to draw a sequence does not decide who will maintain it.

Resend Email Pricing: Pro Is the Practical Starting Point

Resend's entry Pro plan is $20 per month for 50,000 emails, with no daily email cap and 10 domains. Free provides 3,000 per month, capped at 100 per day, with 3 domains. That daily wall matters earlier than the monthly allowance: a hypothetical launch with 60 sign-ups and two messages per sign-up needs 120 sends that day. The current pricing page also lists Scale from $90 per month for 100,000 emails and custom Enterprise plans.

Resend API Pricing: Compare the Volume Selector Before Overages

At its full included allocation, entry Pro works out to $0.40 per 1,000 emails: $20 divided by 50,000, multiplied by 1,000. At only 5,000 emails of actual use, the same subscription works out to $4 per 1,000. These are allowance economics, not prices per successful inbox delivery.

The vendor's machine-readable pricing schedule also lists Pro at $35 for 100,000 emails. At that volume, staying on entry Pro with enabled overages would cost $20 + 50 × $0.90 = $65. Choose the larger Pro allocation before assuming that either overages or Scale is the next sensible purchase.

Marketing is a separate meter: Free covers 1,000 contacts; Pro marketing starts at $40 per month for 5,000; Enterprise is custom. Broadcast sending is unlimited against the contact allowance and does not consume the transactional quota. Sending a newsletter through /emails instead uses transactional quota and leaves unsubscribe handling to your implementation.

For this reader, start with paid transactional Pro when production bursts can exceed Free. Add marketing capacity when the contact list needs it. Evaluate Scale for its operating features, such as its dedicated-IP option, rather than treating its name as proof that it is the cheapest way to buy more sends.

The Limitations That Can Change the Decision

Resend's main constraints concern delivery ownership, retention, shared limits and stored data. They matter more than whether the first API call looks elegant.

Quota Rejections Are Your Application's Responsibility

Resend counts both sent and received email toward the transactional quota, and multiple recipients count separately. Free's daily quota resets at midnight UTC. Paid overages are off until an admin enables them; a quota-rejected send returns an error, and Resend does not queue or retry that message. These rules are explicit in its account limits documentation.

Put retryable work in your own queue and alert on quota failures. For password resets, check token validity before retrying an old job. A message sent after the limit resets may no longer be useful.

A Paid Plan Does Not Automatically Buy More Requests per Second

All accounts start with 10 requests per second per team, shared across API keys and domains. Creating another key does not create another pool. Batch sending can put up to 100 emails in a request, but your queue still needs to respect the request limit. Resend says a plan upgrade does not automatically raise it; higher throughput requires a separate discussion with support.

This is the difference between capacity and throughput. Capacity asks how many messages fit in the month. Throughput asks how many requests your application can make during a burst. Budget and engineer for both.

Retention Is Not Your Permanent Audit Trail

Free, Pro and Scale retain email and log data for 30 days; Enterprise offers flexible retention. Keep your own event history when a receipt dispute or support investigation may arrive later. Also preserve the business event independently of the provider's 24-hour idempotency window.

Early deletion is constrained too. Resend's public data-handling guidance says there is no API for deleting an individual email; early removal of sent messages requires support, and received messages cannot be removed before the retention window ends. A workflow requiring immediate programmatic deletion is a poor fit.

Sending From Europe Does Not Mean Storing Data There

Resend offers sending regions in North Virginia, Ireland, São Paulo and Tokyo. Its region documentation distinguishes sending location from storage location.

Customer data, including message content, delivery logs, webhook payloads and account records, is stored in the United States. Resend says there is no setting that moves that stored data to the EU. Its GDPR page states its compliance position, describes self-auditing, and explains the standard DPA and transfer clauses. Those statements do not turn an Ireland sending domain into EU-only storage.

Resend also states SOC 2 Type II compliance; its public page identifies the reporting period, while the report itself requires login. The security overview lists encryption protections and labels HIPAA as “In progress.” These are vendor statements reviewed here, not an independent compliance audit.

If EU-only storage or a currently available HIPAA arrangement is a firm procurement requirement, do not approve Resend from its sending-region menu or security badges. Resolve the exact requirement before integration.

Verdict: Use Resend When Your Team Can Own the Edges

Resend is a strong choice when a small product team wants a coherent path through templates, API or SMTP sending, delivery events and occasional marketing campaigns. Its value is reducing integration work while leaving product behavior under your control.

The decision flips when US storage fails your requirements, SMTP-level diagnostics are essential, or your application cannot safely handle quota failures and retries. A working older provider also remains a good choice when a migration has no concrete payoff.

For next week's implementation, take one password-reset flow and one receipt flow through domain authentication, quota rejection, duplicate requests, bounce handling and support lookup. Include a peak-day volume estimate. Choose Resend when you can name the owner and expected behavior at every failure point, not merely when the welcome email renders nicely.

Frequently Asked Questions

The name overlaps with the ordinary action “resend an email.” The answers below distinguish the product from mailbox actions.

What are some good free email sending services?

For an application, Resend is a reasonable starting point when its Free daily and monthly limits fit. A free allowance is not enough for production if a launch burst can exhaust it; size the service around the busiest day.

How to Resend and email in new Outlook?

In new Outlook, open Sent Items, select the message, then use the more-options menu and Advanced actions → Resend message. Review the draft before sending. Microsoft's resend instructions describe this mailbox feature; it is unrelated to Resend's API.

Is it resent or Resend?

“Resend” means send again; “resent” is its past tense. Resend, capitalized, is also the email-platform brand reviewed here.

How do I take back an email that I already sent?

Do not treat the Resend platform as a mailbox-recall tool. Outlook has a separate recall feature with account and organization restrictions; Microsoft's recall explanation says it cannot recall messages sent to external or personal accounts.

How do I resend an email that I've already sent?

In Outlook, use the sent-message action described above. In an application, decide whether this is a retry of the original event or an intentional new send; reusing a Resend idempotency key within its protection window prevents a duplicate.

Can I retrieve an email I've already sent?

If you mean inspect a Resend message, use its Emails page and message details within the retention period. If you mean remove the recipient's copy, inspecting or deleting your own record is not the same operation as mailbox recall.

How can I view emails I've sent?

Resend lists sent and scheduled messages in its Emails dashboard, including SMTP sends. Open a message to inspect metadata, preview, HTML, plain text and delivery events.

Why can't I see the emails I've sent?

For Resend, check whether the send was accepted and whether its data is still within retention. For Outlook, check the correct Sent Items folder and saving settings; Microsoft's sent-email guide explains why a sent copy may be missing.

How do I get my sent messages back?

First distinguish a missing mailbox copy from expired provider logs. For Resend investigations beyond its retention window, use the event history you stored yourself; do not build a support process that assumes the provider dashboard is permanent storage.

Use the AI Business Workflow Audit Checklist to assign an owner to each email trigger, failure and recovery step; get the checklist through the newsletter.