Migrate from Resend to sendvia

Your own AWS setup, a re-verified domain, and two call sites to update: what changes, and what you give up by moving.

This page walks through moving outbound sending from Resend to sendvia. The short version: an AWS account of your own, a domain re-verified under your own SES identity, and two call sites in your codebase to update. Nothing about your application code has to change beyond the request itself.

01What you will need

• An AWS account. Free to open, and it is the account SES and SNS will run in.
• An IAM user scoped to SES and SNS, not your AWS root credentials.
• Whoever controls DNS for the sending domain, since new records go in during step three.
• Your existing Resend account, kept active until the cut-over step confirms sendvia is delivering.

02Set up SES and connect it

Create the AWS account first if you do not already have one, then a dedicated IAM user for sendvia rather than the account root. The setup guide covers both, along with requesting production access.

A new SES account starts inside Amazon's sandbox: sending is limited to email addresses you have verified individually, at up to 200 a day. Amazon reviews a production access request itself, and typically clears it in 12 to 24 hours. You can add and verify a domain while still in sandbox, so start the request early and use the wait for the next two steps.

Once the IAM user exists, paste its access key and secret into sendvia and add the sending domain. sendvia generates the records the next step needs.

03Move the DNS records

Nothing about your DNS host changes here: only the records on it do. Resend's own verification asked for a small set of entries there, the ones the table below replaces.

Those two can come out once the records below are confirmed active. sendvia's own DNS panel checks each one live and marks it once it resolves.

The MX and TXT pair on bounce.yourdomain.com is not decoration. That is sendvia's MAIL FROM host: always a bounce subdomain of the domain you send from, never a plain sender-looking subdomain, because that shape is too easily mistaken for a customer's own inbox. Skip the MX and the SPF TXT above it authenticates nothing at all, so it changes nothing: SES falls back to its own amazonses.com envelope domain and DMARC ends up resting on DKIM alone. Once DKIM and DMARC are both confirmed, tighten the DMARC policy from p=none to p=quarantine and then p=reject, and add BIMI if you publish a brand logo. The setup guide covers both.

04Swap the API call

Resend takes the same four fields at POST https://api.resend.com/emails, with the API key as a bearer token and the recipients as an array.

curl -X POST https://api.sendvia.io/v1/send \
  -H "Authorization: Bearer sv_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from":    "[email protected]",
    "to":      "[email protected]",
    "subject": "Your receipt",
    "html":    "<p>Thanks for your order.</p>"
  }'

curl -X POST https://api.resend.com/emails \
  -H "Authorization: Bearer re_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from":    "[email protected]",
    "to":      ["[email protected]"],
    "subject": "Your receipt",
    "html":    "<p>Thanks for your order.</p>"
  }'

Both answer with JSON and both report a result per recipient. A successful sendvia call comes back as {"success":true,"total":1,"sent":1,"failed":0} plus a results array.

The reply that surprises a reader arriving from a provider which owns the sending account is the 422. sendvia refuses a from-address on a domain it has not verified inside your own SES account, because it has no sending identity of its own to fall back on. Verify the domain and the same call goes through.

# 422 {"error":"The domain \"yourdomain.com\" has not been verified. Add and verify it in the dashboard first."}

Two ceilings worth knowing before you port a batch job: a single call takes up to 50 recipients, and /v1/send/batch takes up to 500 messages. A scheduled send accepts send_at up to 72 hours ahead.

05Swap the SMTP settings

The same swap applies wherever your codebase or transactional templates send mail through a relay rather than the REST API. Resend publishes SMTP settings of its own at smtp.resend.com.

Point whatever library or mail transfer agent you use at the new host, port and credentials, and nothing else about the message needs to change.

curl --url smtp://smtp.sendvia.io:587 \
  --user "sendvia:sv_live_your_api_key" \
  --mail-from [email protected] \
  --mail-rcpt [email protected] \
  --upload-file receipt.eml

06Verify and cut over

Run both providers in parallel before you retire the old one. Send the same traffic through each for a week, compare what lands in the inbox and the spam folder, and watch bounce and complaint rates on both sides before you touch the old key.

What it records against a message is a bounce, a complaint, a delivery delay or a rejection, published by SES to an SNS topic in your own account. Delivery is not on that list. sendvia marks a message delivered when nothing has gone wrong two minutes after it was sent, which is an inference rather than a confirmation. Resend, Postmark, Mailgun and SendGrid all receive a real delivery event from their own systems, and sendvia does not. If your parallel run needs a real delivery signal to compare against, get it from the side still running through Resend.

Once bounce and complaint rates hold steady and the logs agree, move the remaining traffic over and cancel the old account. sendvia keeps 7 days of send logs on the free plan and 90 on the paid one, so keep the old provider's own history if you need it further back than that.

What you will lose by moving

Moving is not free of trade-offs. This is what the data on this site records Resend doing that sendvia does not. Read it before you commit to a date.

Set against that: no dedicated IP option, no inbound email or parsing, no teams or sub-accounts and no official SDKs are what sendvia itself does not do, whichever provider you are moving from. Weigh both lists before you start, not after.