Bolt.new emails not sending: contact forms and auth emails
Emails from a Bolt.new app usually fail because the RESEND_API_KEY secret is missing or misspelt, the sending domain is not verified in Resend, or the project is not published on a custom domain, which Bolt lists as a prerequisite. Auth emails like password resets are a separate case: they come from Supabase's default sender until you claim the database and turn on custom SMTP. Fix the secret first, then the domain.
What you'll see
People submit your contact form and nothing reaches you, or new users never get a confirmation email. In the Bolt editor you may see "The following secrets are used in the code but don't exist yet: RESEND_API_KEY". Password reset emails might arrive, but from a generic Supabase address that looks like spam.
Why it happens
1. The secret is missing or misnamed
Bolt reads the key from a secret named exactly RESEND_API_KEY, and the name is case-sensitive. resend_api_key or a key pasted into the code does not count.
2. The sending domain is not verified
Resend needs DNS records on the domain you send from. Until they verify, sends fail or fall back to restrictions that only allow mail to your own address.
3. No published custom domain
Bolt's email guide lists a published project with a custom domain as a prerequisite. An unpublished project or one still in preview cannot complete the setup.
4. Auth emails ignore your SMTP settings
For Bolt-managed databases, Bolt's docs say SMTP settings save but emails still come from Supabase's address until you claim the database into your own Supabase account.
How to fix it
- Create an API key at Resend and copy it straight away; it may not be shown again.
- In Bolt, click the database icon, open Secrets in the left menu and create RESEND_API_KEY with the key as its value. If Secrets is missing, the project has no database yet.
- In Resend, go to Domains > Add Domain, enter your primary domain and add the DNS records it lists. For a domain bought through Bolt, add them under profile icon > Settings > Cloud > Custom domains > Open domain settings.
- Wait for verification, usually 10 to 20 minutes according to Bolt, occasionally a few hours. Then make sure the code's from address uses that verified domain.
- Trigger an email from the live app and check Resend's logs and your Bolt project logs for server function errors.
- For auth emails, click the database icon > Advanced > Claim, then in Supabase enable custom SMTP under Authentication > Email > SMTP Settings with host smtp.resend.com, port 465, user resend and a separate Resend key.
Prompt to paste into Bolt.new
My contact form must email me@example.com via Resend from a server function, using the RESEND_API_KEY secret and the from address hello@example.com on my verified domain. Show the success message only after the function returns OK, otherwise show a clear error, and disable the button while it sends.
How to check it's fixed
- Submit the live form and check both inbox and spam, then confirm the send appears in Resend's delivery logs.
- Run Forgot password on the live site and check the email comes from your own domain.
What a QAlaunch scan shows for this
- Whether an empty form submission shows validation messages or silently does nothing.
- Console errors and failed requests on the page with the form.
- The scan does not send real messages or read inboxes, so delivery itself has to be tested by hand.
See exactly what a full report contains in the sample report.
Frequently asked questions
Do I need a custom domain to send email from Bolt?
For app emails through Resend, Bolt's guide lists a published project with a custom domain as a prerequisite, and you send from a domain you have verified. That also keeps your mail out of spam.
Why do password reset emails come from Supabase?
Auth emails use Supabase's built-in sender until custom SMTP is active. On a Bolt-managed database, you have to claim it into your own Supabase account before SMTP settings take effect.
Can I use the same Resend key for SMTP?
Bolt recommends a separate key for Supabase SMTP. It keeps the two uses apart and lets you revoke one without breaking the other.
Rather have a QA engineer test it by hand?
If this is a site you're launching or handing to a client, I'll go through it by hand, including the Bolt.new-specific issues a scan can't reach, like logged-in flows.
- Up to 10 key pages tested by hand, not a scan
- Every flow a customer uses: forms, sign-up, checkout, booking
- Real mobile and desktop browsers
- A written report in plain language, with screenshots
- A 15-minute call to walk you through it
- 10 years of professional QA experience
Tell me about your site and I'll reply personally, usually the same day.
No payment now. I'll confirm scope and price first.
Related fixes
- Bolt.new custom domain not connecting: causes and fixes
- Lovable contact form not sending email: how to make it deliver
- Bolt.new blank page after deploy: causes and fixes
- Bolt.new site shows 404 on refresh: the Netlify fix
- Bolt.new environment variables not working after deploy
- Bolt.new Google sign-in not working: causes and fixes
More for Bolt.new: all Bolt.new fixes · Bolt.new testing · 9 bugs every AI-built site ships with
Written by Waqas Ahmad, QA engineer with 10 years of professional testing experience. Last checked October 26, 2026.
Sources: Bolt help center: send emails · Resend: 403 error with the resend.dev domain