BUILD OS · AUTHENTICATION

Supabase magic link email is not received

Short answer

Check the email provider logs first: if no send was requested, the app or a rate limit stopped it; if it was sent but filtered, the sending domain is not authenticated; if it arrives but fails, the redirect URL is not allowed or the one-time link was already consumed. Production needs a real SMTP provider on a verified domain.

Symptoms

  • Users request a sign-in link and nothing arrives, or it lands in spam.
  • It works for your own address during testing, then stops after a few attempts.
  • The email arrives but the link opens an error or an expired-link page.

Why this happens

A magic link depends on four systems in sequence: the auth service issuing a one-time token, an SMTP provider sending it, the recipient mail server accepting it, and an allowed redirect URL consuming it. Default built-in SMTP is rate-limited and not meant for production traffic.

Most likely causes

  1. The built-in development SMTP is still in use and its hourly limit is reached.
  2. SPF, DKIM or DMARC are missing for the sending domain, so mailbox providers filter the message.
  3. The Site URL or redirect allow-list does not include the production (or preview) domain.
  4. A mail security scanner opened the one-time link before the user did.
  5. The auth rate limit for email sign-in was hit while testing.

How to diagnose it

  1. Open the email provider or auth logs and find the request for that address: requested, accepted, delivered or rejected.
  2. No request logged: check the app error and rate limits. Rejected or spam: check domain authentication.
  3. If the email arrives, compare the link’s redirect with the allowed redirect URLs, character by character.
  4. Test one Gmail and one Outlook address separately.

Fix

  • Configure a production SMTP provider with a verified sending domain.
  • Publish SPF, DKIM and DMARC records and wait for the provider to validate them.
  • Add every environment’s callback URL to the redirect allow-list.
  • If scanners consume links, use a one-time code or a confirmation step before consuming the token.

Verify the fix

Do not close the issue until these checks pass in the environment that matters:

  • Gmail and Outlook receive the link in the primary inbox within two minutes.
  • The link signs the user in on the production domain.
  • Re-using an already consumed link shows a clear message and a way to request a new one.

Related Ship Passport checks

Build School’s production-readiness standard marks this area as proven only with evidence from these checks (it is Build School’s own standard, not an external certification):

  • importantSign-in emails reach the inbox
  • criticalAn expired or used link fails safely
  • importantThe sending domain is authenticated

Common false fix

Asking users to check spam, or raising the rate limit of the default SMTP, hides the problem until real traffic arrives.

Primary references

Related pattern

Verify the current behavior before asking an agent to refactor it →

Build OS stage

Authentication · Explore Build OS →

Run ShipCheck →Learn the systemGet help fixing it