Firebase & Supabase auth emails: verify the verification

Auth emails are the most expensive email a product sends. A marketing email in Promotions is annoying. A verification email in Spam is a lost signup — the user hit submit, got no email, and churned before you noticed. Firebase Auth and Supabase Auth both ship with default email templates and default sending infrastructure. Both defaults are functional for a prototype and not good enough for a real product.

Firebase Auth: the default sender

Out of the box, Firebase Auth sends verification and password reset email from noreply@<your-project>.firebaseapp.com. That is a hosted Google domain, so:

• SPF / DKIM / DMARC are Google's, and they pass.
• The From line reads "noreply @ some Firebase project you've never heard of" — Gmail recognises it, but Outlook, Yahoo, and corporate gateways may not.
• Many users see the sender and genuinely do not realise it belongs to your product. They mark it as spam.

The result: reasonable authentication, mediocre brand trust, and a small-but-real rate of spam-folder placement that you can't see because Firebase shows you "email sent" and nothing else.

Firebase Auth: swap to custom SMTP

In the Firebase console under Authentication → Templates → SMTP settings, plug in your own SMTP host. The wizard wants:

1. SMTP host (e.g. smtp.sendgrid.net)
2. Port (587 STARTTLS or 465 SSL)
3. Username / API key / password
4. Sender name and sender address on your domain (e.g.hello@yourdomain.com)

Before you switch, make sure your own domain has SPF, DKIM, and DMARC set for the ESP you chose:

; SPF — one record, merged
yourdomain.com.  TXT  "v=spf1 include:sendgrid.net ~all"

; DKIM — provided by the ESP
s1._domainkey.yourdomain.com.  CNAME  s1.domainkey.u12345.wl.sendgrid.net.
s2._domainkey.yourdomain.com.  CNAME  s2.domainkey.u12345.wl.sendgrid.net.

; DMARC
_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

After the switch, verification emails carry your brand, your domain reputation, and DMARC alignment with the rest of your product email — which is good for the signup rate and also good for your DMARC reports.

Supabase Auth: the default sender

Supabase Auth on the free tier sends from a Supabase-owned address through a shared mail pool. Same class of problem as Firebase, plus one specific one: the shared pool is explicitly documented as rate-limited and not intended for production. Supabase's own docs tell you to plug in SMTP before you ship.

Practical signals that you are hitting the default:

• Verification emails take 10-30 seconds to arrive (shared-pool queue).
• Some users never receive them and your auth.userstable fills up with unverified accounts.
• Your Supabase dashboard shows rate-limit warnings.

Supabase Auth: swap to custom SMTP

In the Supabase dashboard under Authentication → Settings → SMTP Provider:

1. Enable custom SMTP.
2. Enter SMTP host, port, username, password / API key.
3. Sender email on your domain, sender name set to your product name.
4. Save and test with a real signup against a seed address.

For the ESP choice: Postmark is strongest for transactional placement, SES is cheapest at scale, Mailgun and SendGrid are broadly fine. For auth email specifically, I'd pick Postmark if budget allows — the transactional-only stance means their shared IPs stay cleaner.

Template hygiene that actually matters

Even after the SMTP swap, the template itself affects placement. The things that move the needle on auth mails:

• Plain text alt body, not just HTML. Gmail downgrades HTML-only transactional mail.
• One primary link, not twelve. Verification emails with marketing footers, social links, and "check out our blog" CTAs land in Promotions more often.
• No tracking pixels on the verification email. It triggers Promotions classification and privacy filters.
• Reply-To that works. Some users reply to the verification email with questions. Make sure that address is monitored.
• Token freshness. Long expiry is a soft anti-pattern from a spam-filter perspective because users sometimes resend and the old token is still valid — leading to duplicate email and engagement splits.

Seed-test a real signup

1. Sign up a seed mailbox for each provider you care about — Gmail, Outlook, Yahoo, Mail.ru, GMX, ProtonMail, iCloud.
2. Complete the signup flow so verification email fires naturally.
3. Check the landing folder per provider. Auth email should be inbox in >95% of cases. If it isn't, something is wrong.
4. Read the headers: DKIM should align with your root domain, SPF should pass, DMARC verdict should be pass.
5. Repeat for the password reset flow — same infrastructure, different template, sometimes different results.

# What a healthy auth email header looks like
From: YourProduct <hello@yourdomain.com>
Authentication-Results: mx.google.com;
  dkim=pass header.d=yourdomain.com;
  spf=pass smtp.mailfrom=bounces.yourdomain.com;
  dmarc=pass header.from=yourdomain.com
List-Unsubscribe: <mailto:unsubscribe@yourdomain.com>
X-Entity-Ref-ID: auth-verification-abc123

After go-live, monitor

• Signup → verified conversion in your analytics. A sudden drop is almost always an email problem, not a product problem.
• DMARC aggregate reports. Gmail, Microsoft, and Yahoo send daily aggregate data. Pipe it into a dashboard.
• Seed tests weekly for the first month after launching custom SMTP, then monthly.
• Bounce and complaint rates at the ESP. Anything above 0.3% complaint on auth mail means your sender reputation is degrading.

FAQ