Supabase Auth Emails Going to Spam: Diagnosis & Fixes
Supabase auth emails landing in spam? Fix requires custom SMTP, DNS records, and branded from-address. This guide covers diagnosis, 3-step fixes, testing, and when to use managed hosting.
- Supabase's default email provider uses shared infrastructure, causing auth emails to land in spam filters for production apps.
- Three fixes required: configure custom SMTP, add SPF/DKIM/DMARC DNS records, and use a branded from-address.
- Email provider reputation filters take 1-7 days to recognize your new sender; full warmup takes 2 weeks.
- If email configuration feels complex, Ship handles DNS records and SMTP setup automatically on flat-rate pricing.
Your Supabase auth emails are vanishing into spam filters because the default email provider uses shared infrastructure with poor domain reputation. Supabase's built-in email sender works for development, but production apps need a custom SMTP provider, proper DNS authentication (SPF/DKIM/DMARC), and a branded from-address. This guide walks you through diagnosis and fixes.
The Invisible Failure: Why Signups Silently Disappear
The worst part of this bug is that it doesn't error. Your app looks fine. Supabase logs show the email was sent successfully. But the email never arrives in your users' inboxes--it lands in spam, or vanishes entirely. You don't see bounce errors. You don't see delivery failures. You see declining signups, confused user support emails asking "did my registration work?", and no clear way to debug what happened.
This is the invisible failure. It's not a crash. It's a silent conversion killer.
The reason your auth emails go to spam is reputation-based. Email providers (Gmail, Outlook, Yahoo) evaluate every sender by domain reputation, authentication protocols, and sending volume patterns. Supabase's default email provider uses a shared sender domain. When one malicious actor sends spam through that same domain, all senders on it (including you) get burned. It's like sharing a phone number with a telemarketer--when they spam thousands of people, your legitimate calls get filtered too.
Most builders don't catch this until they've lost 20-30% of signups to spam traps. By then, the damage to your conversion funnel is real.
Quick Diagnosis: Is It Really Spam, or Something Else?
Before you reconfigure everything, confirm the actual problem. Email failures can happen for multiple reasons, and each has a different fix. Check Supabase's Auth logs first--look for the specific error or success message next to each email send attempt.
Here's how to triage:
| Log Signal | Likely Cause | What to Check |
|---|---|---|
| Email sent=true, user never receives | Spam filtering or delivery failure | User's spam folder; sender reputation via MXToolbox |
| "Email address not authorized to send" | SMTP auth config error | Verify credentials in Supabase > Auth > SMTP Configuration |
| Rate limit error (429) | Free tier limit (2 emails/hour) or quota exceeded | Upgrade to Pro or stagger email sends |
| Link in email fails or redirects wrong | Email client link stripping | Check redirect URLs in email template; verify format |
| User gets email but can't click link | Mismatched redirect domain in Supabase | Verify Auth > URL Configuration matches deployed domain |
If you don't see an obvious error message in the logs, assume it's the spam folder. That's the most common issue.
To confirm: send a test email from Supabase's Auth Emulator in your local dev environment. Then trigger a test auth email from your production app. If the production one lands in spam while the local one doesn't, you've confirmed the issue is reputation-based, not a configuration error.
Why Supabase's Default Email Fails Production
Supabase offers a built-in email provider as part of its Auth system. It works great for development and testing. For production, it fails because of three compounding problems.
First, the default provider sends from shared infrastructure (domains like notifications.supabase.co). Every Supabase app uses the same pool of sender IPs and domains. If one builder sends spam, all builders get flagged. This is like how ISP email (comcast.net, verizon.net) gets filtered more aggressively than dedicated email providers--bad neighbors hurt the whole neighborhood.
Second, your app lacks domain authentication. Your app lives at myapp.com, but the email comes from Supabase's infrastructure. Major email providers distrust this pattern. If you want to send from support@myapp.com, you must prove you own myapp.com by adding SPF/DKIM/DMARC DNS records. Supabase's default provider doesn't support this. Your emails appear to come from a Supabase domain, not your domain, and email filters see this as a red flag.
Third, new senders trigger volume-based spam filters. A brand-new sender domain that immediately sends thousands of emails in the first day looks suspicious. Legitimate senders "warm up" new domains by gradually increasing volume over 1-2 weeks. The default Supabase provider doesn't warm up; it just starts sending. Gmail, Outlook, and corporate email filters flag this pattern as spammy behavior.
The fix is simple in theory: switch to a custom SMTP provider. In practice, it requires three steps: configuring SMTP in Supabase, adding DNS records, and potentially choosing a new email provider.
The 3 Required Fixes
All three must be in place. Two out of three is not enough. Missing even one will still cause spam filtering.
Fix 1: Configure Custom SMTP in Supabase
Go to Supabase Dashboard > Auth > Email Templates > SMTP Configuration. You'll need four pieces of information:
- SMTP host (e.g., smtp.resend.com, smtp.sendgrid.net, smtp.postmark.io)
- SMTP port (usually 587 for TLS, sometimes 465 for SSL)
- SMTP username and password (usually an API key)
- From email address (e.g., noreply@yourdomain.com)
Popular providers for Supabase apps:
- Resend ($20/month, good for small apps; integrates well with Vercel/Next.js)
- Postmark ($10-50/month, excellent deliverability; recommended for high-volume apps)
- SendGrid (tiered, $15-120/month; industry standard with most integrations)
- Brevo (free tier up to 300 emails/day, good for bootstraps testing before scaling)
Pick one, grab the SMTP credentials from their dashboard, paste them into Supabase, and test using Supabase's built-in email test tool in the same UI.
Fix 2: Add SPF/DKIM/DMARC Records to Your Domain
This tells email providers you authorized this SMTP provider to send on your behalf. You'll add three DNS TXT records. Each provider publishes their exact records in their documentation; here's what the records look like:
# SPF record (example for Resend)
v=spf1 include:sendgrid.net ~all
# DKIM record (example; varies by provider)
default._domainkey.yourdomain.com TXT v=DKIM1; k=rsa; p=MIGf...
# DMARC record (goes on all domains)
_dmarc.yourdomain.com TXT v=DMARC1; p=quarantine; rua=mailto:admin@yourdomain.com
DNS propagation takes 5-30 minutes. Most DNS providers (Namecheap, GoDaddy, Route53, Cloudflare) have a UI for adding TXT records. Your SMTP provider will have copy-paste-ready records in their dashboard or documentation.
To verify the records are live, use MXToolbox (mxtoolbox.com). Search your domain and check the SPF/DKIM/DMARC tabs. All three should show "pass" or "valid."
Fix 3: Use a Branded From-Address
In Supabase's Email Templates section, set the from-address to your domain (e.g., noreply@myapp.com). This must match your domain's SPF/DKIM/DMARC records. If your DNS records authorize noreply@myapp.com, use exactly that; don't use support@myapp.com if it's not in the records.
This signals to email providers that you're a real organization, not a fly-by-night sender. It's a small change with outsized impact on deliverability.
How to Test Your Fix Before Rolling Out
Before you send password-reset emails to all users, confirm your configuration works on a small sample and passes authentication checks.
Step 1: Send a test email from Supabase
In the Email Templates section of Supabase Auth, hit "Send Test Email" to your own email address. Wait 2-5 minutes. Check your spam folder if it doesn't appear in your inbox. This confirms basic SMTP connectivity works.
Step 2: Verify authentication headers
Open the email in Gmail and click the three dots > Show Original. In Outlook, right-click the message > Message > Message Properties. Look for a line like:
Authentication-Results:... spf=pass dkim=pass dmarc=pass
If all three are "pass," your DNS records are working correctly. If one or more say "fail," you need to revisit your DNS setup and ensure the records exactly match your provider's documentation.
Step 3: Test with a spam checker
Paste the email headers into MailTester (mail-tester.com). It'll score your sender reputation on a 0-10 scale. Above 8/10 is safe for production. Below 6/10 means your configuration still has issues--go back and verify SPF/DKIM records match your provider's spec.
Step 4: Roll out to a small cohort
Once your test email passes all checks, configure your production app to use the new SMTP settings for a subset of users (10-20 signups). Monitor their confirmation emails for 24 hours. If they all arrive in inboxes, scale to 100% of users.
Common Errors and Quick Fixes
These are the most frequent issues builders hit while configuring SMTP.
| Error Message | Root Cause | Fix |
|---|---|---|
| "SMTP authentication failed" | Wrong username/password or API key | Copy-paste SMTP credentials directly from your provider's dashboard. Avoid typos. |
| "Connection refused on port 587" | Firewall blocking or unsupported port | Try port 465 (SSL) instead of 587 (TLS). Check your SMTP provider's docs for supported ports. |
| "Relay access denied" | From-address doesn't match authorized domain | Ensure from-address in Supabase matches the domain you added SPF/DKIM records for. |
| "Email sent" but still lands in spam | DNS records not live or incomplete | Wait 30 minutes for DNS propagation. Verify all three records (SPF/DKIM/DMARC) using MXToolbox. |
| Emails send but delivery slows | Provider rate limit or quota hit | Upgrade your SMTP plan or stagger email sends over time. Resend and Postmark handle burst traffic better than budget providers. |
When to Stop Configuring and Start Using Managed Hosting
Configuring SMTP, debugging DNS records, and monitoring deliverability is complex and time-consuming. If this process takes you more than an hour or feels like unproductive yak-shaving, there's a simpler path.
Ship (Opsily's managed platform for Lovable apps) handles all of this out of the box. You deploy your app, Ship assigns you a branded domain, provisions DNS records, and configures email authentication automatically. No SMTP credentials to paste. No DNS TXT records to debug. No email provider to select and integrate.
If you're building a Lovable or Bolt.new app, Ship's migration guide covers moving your project off Lovable Cloud with DNS and email pre-configured. If you're already running on custom infrastructure and comfortable with email config, stay with your SMTP setup. The tradeoff is simple: Ship costs EUR 10/month flat rate plus hosting. DIY custom SMTP costs $10-50/month (varies by provider) plus your time. Pick the one that feels less painful.
Frequently Asked Questions
Can I disable email auth and use OAuth-only instead?
Yes. If email delivery is too much trouble, switch to OAuth-only (Google, GitHub, Discord login). But email-based signup remains useful for password resets and account recovery, even if login is OAuth-only. Most production apps use both.
How long does it take for emails to stop going to spam?
DNS records propagate in 5-30 minutes. Email provider reputation filters (Gmail, Outlook) take 1-7 days to recognize your new sender. Full warmup to trusted-sender status typically takes 2 weeks. Be patient with the timeline.
Will changing SMTP providers break existing user sessions?
No. Changing your SMTP config only affects new emails going forward. Existing sessions and password-reset links remain valid. You can switch providers without downtime or user impact.
Is Resend, SendGrid, or Postmark better for Supabase?
All three work. Resend is simplest for small apps. Postmark has the best deliverability (consistently 99.9%+). SendGrid is the industry standard with most integrations. Pick one, test it with Supabase, and switch if needed. There's no penalty for testing multiple providers.
What if I'm on a free domain (myapp.vercel.app or myapp.netlify.app)?
Email filters distrust these domains more aggressively. SPF/DKIM/DMARC records may not help much if your root domain is a platform's domain, not a custom domain. Buy a cheap domain ($10/year). It'll improve deliverability and look more professional to users.
Can I see which emails bounced or landed in spam?
Your SMTP provider's dashboard will show delivery status. Resend, Postmark, and SendGrid all have bounce reports, complaint reports, and delivery logs. Check there for diagnostics.
Is a custom domain required for email authentication?
Yes. Email filters require proof that you own the domain your email comes from. Free subdomains (vercel.app, netlify.app) can't be authenticated. Buy a custom domain to unlock SPF/DKIM/DMARC setup.
The Bottom Line
Supabase's default email provider works for MVP and local testing. For production, you need three things: custom SMTP, DNS authentication, and a branded from-address. This guide walks through each step.
If you're seeing silent signup loss (emails disappearing into spam), the fix is 1-2 hours of configuration. If you're running on Ship, it's already done. For Lovable app owners moving to independent hosting, Ship's setup guide includes DNS and email configuration for agency-to-client handoffs. Pick the tradeoff that makes sense for your stage and move on.