{"id":437,"date":"2026-09-24T05:20:23","date_gmt":"2026-09-24T10:50:23","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=437"},"modified":"2026-09-24T11:47:32","modified_gmt":"2026-09-24T17:17:32","slug":"replacing-supabase-and-firebase-default-auth-emails-with-custom-smtp","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/replacing-supabase-and-firebase-default-auth-emails-with-custom-smtp\/","title":{"rendered":"Replacing Supabase and Firebase Default Auth Emails with Custom SMTP"},"content":{"rendered":"\n

Everything works during development. Signups confirm, magic links arrive, password resets land in seconds. Then you launch, twenty people sign up in an hour, and the emails stop.<\/p>\n\n\n\n

Nothing is broken. Both Supabase and Firebase ship a built-in email service intended for development, and both rate limit it aggressively. The messages also come from their domain rather than yours, so the ones that do send often land in spam.<\/p>\n\n\n\n

This guide covers moving auth emails onto your own SMTP relay: why the defaults cap out, how to configure custom SMTP in each platform, how to take control of the templates, and how to confirm delivery actually improved.<\/p>\n\n\n\n

Quick Answer: How Do You Set Up Custom SMTP?<\/h2>\n\n\n\n

Supabase:<\/strong> open Project Settings, then Authentication, then SMTP Settings. Enable custom SMTP and enter:<\/p>\n\n\n\n

Sender email:  noreply@yourdomain.com\nSender name:   Your App\nHost:          smtp.photonrelay.com\nPort:          587\nUsername:      your_project_api_user\nPassword:      your_secret_api_key<\/code><\/pre>\n\n\n\n
Firebase:<\/strong> open Authentication, then Templates, then the SMTP settings section, and enter the same connection details.<\/p>\n\n\n\n
Both platforms then send through your relay instead of theirs. The step most teams miss comes next: publishing SPF and DKIM records so your sending domain is authorised. Without those, custom SMTP changes who sends the mail but not whether receiving servers trust it. An authenticated relay such as PhotonConsole<\/a> supplies both the credentials and the DNS records.<\/p>\n\n\n\n
Why the Built-In Email Services Cap Out<\/h2>\n\n\n\n
\"Diagram
The default service sends from the platform’s domain. Custom SMTP sends from yours.<\/figcaption><\/figure>\n\n\n\n
Supabase and Firebase both provide email out of the box so you can build an auth flow without configuring anything. Neither intends that service for production traffic.<\/p>\n\n\n\n
Supabase’s documentation<\/a> is explicit that the built-in service is for testing and development, with a low hourly limit, and recommends custom SMTP before going live. Firebase<\/a> sends from a project subdomain you do not control, which limits what you can do about deliverability.<\/p>\n\n\n\n
Aspect<\/th>Built-in service<\/th>Custom SMTP<\/th><\/tr><\/thead>
Hourly send limit<\/td>Low, intended for testing<\/td>Set by your relay plan<\/td><\/tr>
Sender domain<\/td>The platform’s domain<\/td>Your own domain<\/td><\/tr>
SPF and DKIM alignment<\/td>Not aligned with your domain<\/td>Aligned once DNS is published<\/td><\/tr>
Delivery logs<\/td>Not available to you<\/td>Available in the relay dashboard<\/td><\/tr>
Bounce handling<\/td>Not exposed<\/td>Webhooks available<\/td><\/tr>
Suitable for production<\/td>No<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Rate limits on both platforms change over time, so check the current figures in their documentation rather than relying on a number quoted in any article, including this one.<\/p>\n\n\n\n
Why Auth Emails Fail After Launch<\/h2>\n\n\n\n
1. The Hourly Limit Is Reached<\/h3>\n\n\n\n
A launch, a marketing push, or a batch of test signups can exhaust the built-in allowance quickly. Once the limit is hit, further emails are simply not sent. Your application reports a successful signup because the user record was created \u2014 the email was a separate step that silently failed.<\/p>\n\n\n\n
2. Messages Come From a Domain You Do Not Own<\/h3>\n\n\n\n
Receiving servers check whether the sending domain authorised the message. When mail arrives from a platform subdomain while claiming to represent your product, there is no alignment with your domain, and filters respond accordingly. This matters more than it used to under Google’s sender guidelines<\/a>.<\/p>\n\n\n\n
3. Shared Sending Reputation<\/h3>\n\n\n\n
The default service is shared by many projects on the platform. Poor sending behaviour by other projects affects the reputation of the IPs your mail leaves from, and you have no visibility or control over it.<\/p>\n\n\n\n
4. Time-Critical Mail Arrives Late<\/h3>\n\n\n\n
Magic links and one-time codes expire. A message delayed by rate limiting or filtering is worthless by the time it arrives, and the user simply cannot sign in.<\/p>\n\n\n\n
5. Custom SMTP Configured Without DNS Records<\/h3>\n\n\n\n
This is the most common half-finished migration. The relay is connected, mail sends successfully, and it still lands in spam \u2014 because the sending domain publishes no SPF or DKIM records. Our guide to SPF, DKIM and DMARC<\/a> explains the records, and the free email deliverability checker<\/a> shows what your domain currently publishes.<\/p>\n\n\n\n
Common Mistake<\/p>\n\n\n\n
Connecting custom SMTP and stopping there. The sender address changes to your domain, which is exactly what receiving servers will now check \u2014 and if that domain has no SPF or DKIM records, alignment fails in a way it did not before. Deliverability can get worse rather than better. Publish the DNS records in the same session you connect the relay, never as a follow-up task.<\/p>\n\n\n\n
Setting Up Custom SMTP in Supabase<\/h2>\n\n\n\n
Step 1: Publish DNS Records First<\/h3>\n\n\n\n
TXT    @                    v=spf1 include:relay.photonconsole.com ~all\nCNAME  photon._domainkey    dkim.photonconsole.com<\/code><\/pre>\n\n\n\n
Note<\/p>\n\n\n\n
DNS changes are not instant. SPF and DKIM records can take from a few minutes to 24-48 hours to propagate depending on your registrar and TTL settings. Also check you do not already publish a second SPF record \u2014 two separate TXT records starting with v=spf1<\/code> break authentication entirely.<\/p>\n\n\n\n
Step 2: Enter the SMTP Settings<\/h3>\n\n\n\n
In the Supabase dashboard, open Project Settings, then Authentication, then SMTP Settings. Enable custom SMTP and supply the sender address, host, port and credentials shown in the quick answer.<\/p>\n\n\n\n
The sender address must be on the domain you authenticated in step one. Using a Gmail or Outlook address here defeats the purpose, because that domain has not authorised your relay to send on its behalf.<\/p>\n\n\n\n
Step 3: Raise the Auth Rate Limit<\/h3>\n\n\n\n
Connecting custom SMTP does not automatically lift Supabase’s own auth email rate limit. That is a separate setting under Authentication, then Rate Limits. Teams frequently connect a relay, test successfully, then hit the same wall at launch because this step was missed.<\/p>\n\n\n\n
Step 4: Customise the Templates<\/h3>\n\n\n\n
Under Authentication, then Email Templates, Supabase exposes each auth email \u2014 confirm signup, invite, magic link, change email address, reset password and reauthentication.<\/p>\n\n\n\n
Three things are worth changing from the defaults:<\/p>\n\n\n\n