Skip to content

Supabase email problemWhy do my Supabase sign-up emails go to spam, and how do I fix it?

Your users sign up, wait for the confirmation email, and find it in spam, or never find it at all. A common cause is that the sending domain can’t prove the email is really from you. Here’s what to set up, in order, or hand it over at a fixed price.

Short answer

Send through your own email provider (custom SMTP in Supabase, such as Resend or Twilio SendGrid) from your own domain, and verify that domain with the provider so SPF and DKIM pass. Add a DMARC record, starting with p=none, or edit the one you already have. Keep the From: address on the domain you verified, ideally the same domain as your website, and leave open and click tracking off for sign-up emails.

Fix it in this order

  1. 01

    You’re still on Supabase’s built-in sender

    “Work with your email sending service to configure DKIM, DMARC and SPF for your sending domain.” Supabase, Send emails with custom SMTP

    Supabase’s built-in sender is not meant for production: it only delivers to your project’s team, and it currently sends 2 messages an hour, a limit Supabase says can change without notice. Real users need custom SMTP from an email provider, set on the SMTP settings page under Authentication in the Supabase dashboard, sending from an address on your own domain.

  2. 02

    Your sending domain isn’t verified, so SPF and DKIM fail

    “Set up SPF or DKIM email authentication for your sending domains.” Google, Email sender guidelines

    SPF and DKIM are DNS records that prove your email provider may send as your domain; DMARC, below, tells inboxes what to do when they fail. Adding your domain in the email provider gives you the records to add where your domain is managed. Resend says SPF and DKIM are set up automatically once the domain is verified, so wait until the provider shows it as verified. Google’s sender guidelines ask for SPF or DKIM from every sender. Caution: if your domain already sends email, for example staff mail, it may already have an SPF record. Ask your email provider how to combine them rather than adding a second one.

  3. 03

    The From: address doesn’t match the verified domain

    “For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain.” Google, Email sender guidelines

    The domain in the From: address must match the domain you verified. If it uses a Gmail address or an old domain instead, the checks fail even though the records exist. Use an address on the verified domain, such as no-reply@ or hello@ on it.

  4. 04

    No DMARC record

    “An email must pass either SPF or DKIM checks (but not necessarily both) to achieve DMARC compliance and be considered authenticated.” Resend, DMARC

    DMARC is one more DNS record, named _dmarc, that tells inboxes what to do with email that fails SPF and DKIM. Check first whether your domain already has one: if it does, edit it, and don’t add a second. Start with p=none and an address that can receive the reports. Move to quarantine or reject only once your sign-up emails and your other email, such as staff mail, all pass, or the stricter setting can block that mail.

    _dmarc.example.com  TXT  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
  5. 05

    Links point at Supabase’s shared address

    “Setting up a custom domain will reduce the likelihood of your messages being picked up as spam due to another Supabase project's bad reputation.” Supabase, Send emails with custom SMTP

    Sign-up and reset emails link to your project’s Auth server. Without a custom domain, that link sits on Supabase’s shared address, so Supabase suggests a custom domain to keep other projects’ reputation off your emails.

  6. 06

    Tracking on sign-up emails

    “It would seem like adding open and click tracking would be ideal to gather this information, but this has been seen to negatively impact your inbox placement.” Resend, How to avoid Gmail’s spam folder

    Resend’s guide says open and click tracking has been seen to hurt inbox placement, so turn it off for sign-up and password reset emails.

  7. 07

    A brand new domain, a different website, or marketing on the same address

    “Make sure that the domain you send with is the same domain where your website is hosted.” Resend, How to avoid Gmail’s spam folder

    Resend says sending a large volume from a new domain tends to land in spam, so start small. Send sign-up emails from your website’s domain. Supabase says not to mix Auth emails with marketing, so send newsletters from a separate subdomain or address, and complaints about them don’t drag down your sign-up emails.

Checked against the vendor’s docs on : Google: Email sender guidelines; Resend: How to avoid Gmail’s spam folder; Resend: DMARC; Resend: Domains; Supabase: Send emails with custom SMTP; Twilio SendGrid: Configure domain authentication.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Supabase email rate limit exceeded · Supabase emails link to localhost · Supabase staging environment · Supabase RLS fixes

Questions

More on this error

I use SendGrid and emails say “via sendgrid.net”. Is that the problem?

Twilio SendGrid says domain authentication removes that tag and improves your chance of reaching the inbox. If you still see it, authentication isn’t finished: set up domain authentication in SendGrid and add the DNS records it gives you.

How do I know if it’s fixed?

Sign up with fresh addresses on the live site, at Gmail and at another provider, and see where the emails land. Your email provider’s dashboard should show the domain as verified. Once you send enough email for Google’s Postmaster Tools to show figures, Google says to keep the spam rate there below 0.3%.

What access do you need to sort it out?

A look at your Supabase SMTP settings and your email provider’s domain page, plus whoever manages your DNS. You add the records yourself, or give access to the DNS provider; we write down each record and why it is there.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.