Resend
Resend emails not sending
A success message on your site only means your code decided to show one. The send either never called Resend, was rejected, or landed somewhere you are not looking.
Symptoms
- The page says the message was sent, and the inbox is empty, including spam.
- The Resend email log has no row for that recipient.
- The log shows 403, 422, or a validation error on the from-address.
- Only the address on the Resend account receives mail.
Common causes
The from-address domain is not verified
Resend will not send for an arbitrary domain. The domain on the from-address has to be verified, including the subdomain if you send from alerts@ or hello@ on a subdomain.
The API key is missing on the deployment
The key works in the editor and is empty in production. The code then skips the API, or sends with a placeholder, and still renders the thank-you page.
The key belongs to another team, or cannot send
A key copied from a personal sandbox, or a key limited to a different permission, is rejected. The error is in the API response, which a lot of generated code logs and then ignores.
The template throws before the request
A render error in the React email, or a missing field, aborts the function before fetch. There is no Resend log because there was no request.
The recipient is suppressed
A previous bounce or complaint suppresses the address. Later sends fail for that recipient only, which looks like a random bug.
DNS is only half done
The dashboard can show the domain as unverified, or verified while a receiver still rejects mail, if the SPF, DKIM, or DMARC records Resend gave you are not the records that are live.
Fix it
Read the Resend email log
Search the recipient. No row means your server did not make the request. A row with an error code is the thing to fix, not the copy on your thank-you page.
Match the from-address to a verified domain
Open domains in Resend and confirm the exact domain is verified. If you send from a subdomain, that name has to be the one that was verified.
Read the deployed environment
Confirm RESEND_API_KEY, or whichever name your code uses, is set on the host that serves production. Redeploy after you add it. A local .env does not travel with a preview publish.
Send one message from the Resend dashboard
If that arrives, the domain can send and the bug is in your code. If it does not, stop looking at the app and fix the domain or the suppression list.
Log the API status in the handler
Treat a non-2xx as a failure the user can see. Returning the thank-you page after a 403 is how this bug hides for a week.
Check suppressions and spam
Remove a suppressed recipient only if the address is valid again. Also check the spam folder before you change DNS you already got right.
Catch it automatically
Map the signup and assert the thank-you state a person can see. That proves the page still claims success. It does not prove Resend accepted the message. Use the Resend log for that, and use the replay so a deleted form does not wait on a customer to tell you.
Watch the next break before a customer does.
Map the path once. The next publish does not get to fail in private.
Questions
Why does email to my own address work and nowhere else?
Unverified domains and sandbox-style setups often deliver only to the account owner. Verify the sending domain before you treat a self-send as proof.
The page says sent. Is that a Resend bug?
Not by itself. Check the log. If Resend has no attempt, the bug is in the app: a missing key, a thrown template, or a success page that does not read the response.
Do I need to monitor the Resend API?
You need to notice when the form stops reaching a success state, and you need the provider log when the success state is a lie. Those are both worth having.