Password reset email not sending

Lovable, Bolt, and Cursor ship Supabase-backed auth that relies on the built-in shared SMTP server by default. That server is deliberately rate-limited — around three to four emails per hour per project — and is intended for development only. Founders test locally, confirm the password reset email arrives, deploy to production, and then onboard their first ten users. Most of those users never see the reset email because the shared SMTP quota was exhausted on hour one. Supabase logs the request as "email sent" because it queued the message; the message itself never leaves the throttled queue.

Even when founders configure their own SMTP, the second trap is a missing DNS trust chain. Gmail and Outlook check SPF, DKIM, and DMARC to decide whether a message is trustworthy. Without those records, the message is either rejected outright or dumped into spam. The app-side code looks correct, the Supabase log says "email sent," the SMTP provider log says "delivered" — but the recipient never sees the message because their mail server silently quarantined it.

The third problem is sender verification. Resend, Postmark, and SendGrid all require you to verify the domain you send from. AI generators often write a sender like noreply@yourapp.com without telling you that you must add domain verification records. The first send then silently fails at the SMTP provider level, Supabase logs a generic error, and the founder cannot tell whether the problem is Supabase, SMTP, DNS, or code. The only path out is to check each layer in order.