How to Set Up Custom SMTP for Supabase

Supabase's default email service is limited to 2 emails per hour and team-only delivery--fine for testing, but insufficient for production. To fix this, you need custom SMTP. This guide walks you through the exact steps: choosing a provider, enabling custom SMTP in your Supabase dashboard, obtaining SMTP credentials, adding domain authentication, and testing everything end-to-end before go-live.

Why Supabase's Default Email Isn't Enough for Production

Supabase includes a built-in email service that supports 2 emails per hour. It works for sending password reset links and confirmation emails during development and testing. But it only delivers to team members you've invited--not real users. For production apps, you need a real SMTP provider that has no artificial limits and guarantees delivery to everyone.

The problem is twofold: speed and reach. With Supabase's default service, you can't send emails to arbitrary users--only to Supabase team members. Once you enable custom SMTP, you get 30 emails per hour from Supabase directly, plus the actual limits of whatever SMTP provider you choose. A serious production app will exceed both thresholds quickly.

There's also no SLA. Supabase's built-in email is best-effort. If something goes wrong, you have no recourse. Custom SMTP providers back their delivery with uptime guarantees, logs you can inspect, and support teams you can contact when mail isn't getting through.

The fix is simple: connect a real SMTP provider and tell Supabase to use it. You'll get reliable, scalable email delivery. Your app will work. Your users will see confirmation links in their inboxes.

Choosing an SMTP Provider

Supabase supports any standard SMTP host. That means Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail, Brevo, or even a self-hosted mail server. So which one do you pick?

Start with Resend if you want the simplest integration. Resend is built for developers, integrates natively with Supabase, and costs $20/month for 5,000 emails. The per-message cost is bundled into the flat fee, so you never worry about overage charges.

AWS SES is the pick if you need rock-bottom pricing at scale. You pay roughly $0.10 per 1,000 emails after a small monthly quota. At high volumes, it's the cheapest option. The downside: setup is fiddly, and you need an AWS account.

Postmark and Twilio SendGrid are enterprise-grade middle grounds. Both offer managed infrastructure, spam detection, and detailed logs. Postmark is $15/month for 10,000 emails. SendGrid charges per recipient starting at $10/month. Both excel at deliverability.

Mailtrap and ZeptoMail are smaller but solid. Mailtrap is $29/month for 200 emails per day (6,000 per month) and includes inbox testing. ZeptoMail (by Zoho) is $9/month for 10,000 emails.

Brevo (formerly Sendinblue) bundles SMS and email for $20/month starting at 20,000 emails per month.

For most teams, Resend or AWS SES will do. Resend wins on simplicity. AWS SES wins on price if you're sending more than 100,000 emails per month. Pick one now; switching later takes 15 minutes.

Step-by-Step: Enable Custom SMTP in Supabase Dashboard

This is the core operation. It takes five minutes.

1. Log in to your Supabase console and navigate to your project.
2. Go to Authentication (left sidebar) > Emails.
3. Scroll down to SMTP Settings and toggle "Use custom SMTP" on.
4. Fill in the form:
   • Sender Email: The email address your app will send from (e.g., noreply@yourapp.com).
   • Sender Name: What appears in the "From" field (e.g., "Your App").
   • Host: Your SMTP provider's server address (e.g., smtp.resend.com).
   • Port: Usually 587 (StartTLS) or 465 (implicit TLS). Check your provider's docs.
   • Username: Your SMTP account username.
   • Password: Your SMTP account password or API token.
   • Encrypt: Leave as "tls" unless your provider specifies otherwise.
5. Click Save. Supabase will test the connection immediately.

That's it. Your Supabase instance is now configured to use custom SMTP.

Getting SMTP Credentials from Your Provider

Where you find these credentials depends on your SMTP provider. Each one publishes them in a different place.

Resend: Go to API Keys in your Resend dashboard. You'll see your SMTP password listed there. Host: smtp.resend.com. Port: 587. Username: default.

AWS SES: You need to create an SMTP user via IAM. Go to AWS SES console > Account dashboard > SMTP settings. Generate SMTP credentials. AWS gives you a username and password. Host varies by region (e.g., email-smtp.us-east-1.amazonaws.com).

Postmark: Open Servers in your Postmark dashboard. Click into your server. Under Credentials, you'll find Host, Port, and your API token (use as password). Username: postmark.

SendGrid: Go to Settings > API Keys. Create an API key. Use "apikey" as the username and your API key as the password. Host: smtp.sendgrid.net. Port: 587.

Mailtrap: Open Settings in your Mailtrap project. Your SMTP credentials are visible. Mailtrap assigns a username and password; the host is smtp.mailtrap.io.

ZeptoMail (Zoho): In your ZeptoMail dashboard, go to Settings > SMTP. Copy the username and password. Host: smtp.zoho.com (or your region's variant).

Treat these credentials like passwords. Don't commit them to Git. Store them in environment variables or your password manager. Supabase encrypts them on its servers, but that's not an excuse to be careless.

Domain Authentication (SPF/DKIM/DMARC)

Once custom SMTP is running, your emails will arrive. But some might land in spam. The fix is domain authentication: adding DNS records that prove you own the domain and you trust the SMTP provider to send mail on your behalf.

Add three records to your domain's DNS:

SPF (Sender Policy Framework): This record tells email servers which hosts are allowed to send mail from your domain. Your SMTP provider gives you the exact SPF record to add. It looks like: v=spf1 include:_spf.resend.com ~all. Add this as a TXT record.

DKIM (DomainKeys Identified Mail): This is a cryptographic signature. Your SMTP provider generates a public key; you add it as a DNS TXT record with a specific name (usually something like default._domainkey). Email servers verify that messages came from you.

DMARC (Domain-based Message Authentication): This is the policy layer. It says what to do if SPF or DKIM fails. A basic DMARC record looks like: v=DMARC1; p=none; rua=mailto:admin@yourapp.com. Add this as a TXT record at _dmarc.yourapp.com.

None of this is optional. Gmail, Outlook, and other major providers check these records. If they're missing or wrong, your emails hit spam.

Each SMTP provider has a guide showing exactly which records to add to which domain registrar (GoDaddy, Namecheap, Route 53, etc.). Follow that guide step-by-step. Then wait a few hours for DNS to propagate. Most providers have a verification button in their dashboard; click it to confirm the records were added correctly.

Testing Your Configuration

You've enabled custom SMTP, added credentials, and authenticated your domain. Now verify it works before you rely on it in production.

1. In your Supabase console, go to Authentication > Users.
2. Find any user and click the three-dot menu. Select "Send Confirmation Email" or "Send Password Reset Email" (whichever option appears).
3. Supabase will send an email using your custom SMTP provider. Check your inbox.
4. If it arrives immediately, great. If it lands in spam, your domain authentication isn't set up yet (wait longer for DNS propagation).
5. For a deeper test, check your SMTP provider's email logs. Log into your Resend, SendGrid, or Mailtrap dashboard. Look for the email you just sent. The log will show delivery status, bounce reasons, and click-through tracking if enabled.

Test from your live app next. If your app triggers a magic link or password reset, that email should also use custom SMTP. It will go through the same path as the test. If it arrives, you're done.

Common Issues and How to Fix Them

Emails aren't arriving at all:

First, double-check your SMTP credentials. Log into your provider's dashboard and confirm the username and password you copied are current. Next, verify the host and port are correct for your provider (587 vs. 465 matters). Then, toggle custom SMTP off in Supabase, wait 30 seconds, and toggle it back on to reconnect. If the issue persists, check your provider's status page--they might have an outage.

Emails are arriving but going to spam:

This is a domain authentication problem. Your SPF, DKIM, or DMARC records are missing or incorrect. Go to your DNS provider and verify all three records are present. Use a free tool like MXToolbox to check SPF and DKIM validity. Then wait 24 hours for Gmail and Outlook to re-evaluate your domain. If emails still land in spam after a day, contact your SMTP provider's support--they can debug authentication issues.

"Connection refused" or timeout errors:

Your port or host is wrong. If you're using port 587, try 465. If you're using implicit TLS (465), Supabase's "Encrypt" setting should be "tls". If that's not the issue, check whether your network blocks outbound SMTP (corporate firewalls sometimes do). Try using a different network to test.

Hitting rate limits:

Supabase sets a default of 30 emails per hour for custom SMTP. If you exceed that, emails queue and retry later. Check how many emails your app is actually sending. If you're legitimately exceeding 30 per hour, go to Authentication > Rate Limits in your Supabase dashboard and raise the threshold. Your SMTP provider might also have its own limits--check their docs.

Confirmation links are broken or not tracking:

Some email tracking tools (like link-shortening services) interfere with Supabase's confirmation links. Disable any link tracking or click-through tracking in your SMTP provider's settings, then re-send the test email.

Next: Hosting Your App with Predictable Email Costs

Custom SMTP solves your email delivery problem. Your app will now reliably send emails to all users, not just team members.

The next challenge is infrastructure. If you're running your app on a platform that charges per message or per month with variable usage, email costs become unpredictable. You've just solved certainty on the email side--now solve it on the hosting side.

Opsily's managed Ship hosting lets you host your full-stack application (frontend, backend, database) with a flat monthly fee. No per-email charges, no surprise overages. Your email cost is bundled into your hosting cost. You know what you'll pay next month.

Check out Opsily's managed Ship hosting for your next deployment, or explore self-hosted PaaS alternatives if you want more control.

Frequently Asked Questions

How do I configure SMTP email settings?

Log into your Supabase console, go to Authentication > Emails, toggle on "Use custom SMTP," and fill in your provider's host, port, username, and password. Supabase will test the connection. If the test passes, you're configured.

How can I set up a custom SMTP server?

You can use a managed provider like Resend, AWS SES, or Postmark (each has its own dashboard), or run your own mail server on a VPS. A managed provider is simpler; a self-hosted server is cheaper but requires Linux sysadmin skills.

Can Supabase send emails?

Yes. Supabase's built-in email service sends 2 emails per hour. With custom SMTP enabled, it sends 30 emails per hour, plus whatever your SMTP provider supports. Most apps should use a managed SMTP provider like Resend or AWS SES for better scaling.

Can I set up my own SMTP server?

Yes, but it's rarely worth it. Running a reliable mail server requires deliverability expertise, IP reputation management, and handling bounces and complaints. For most teams, a managed provider costs less than the DevOps time to maintain a self-hosted server.

Is SMTP used anymore?

Yes. SMTP is the industry standard for transactional email (password resets, confirmations, notifications). It's not going anywhere. API-based approaches (like Resend's REST API) are alternatives, but they're built on SMTP under the hood.

Can I get a free SMTP server?

Some providers offer free tiers: Mailtrap offers 100 emails per day free. ZeptoMail includes 10,000 emails per month free. AWS SES charges $0.10 per 1,000 emails after a tiny monthly allowance. For small apps, these free tiers are enough to get started.

The Bottom Line

Supabase's default email service works for testing. For production, custom SMTP is not optional: it gives you reliability, real user delivery, and proper scaling.

The setup takes 15 minutes: pick an SMTP provider, grab your credentials, paste them into Supabase, add domain authentication records, and test. Everything works.

Your app will send emails reliably from day one. Get started by exploring managed hosting that bundles predictable infrastructure with your email delivery.