Custom SMTP settings show success but do not persist after reload

[MNDZALV]

Hi Supabase community,

I am configuring Custom SMTP for Supabase Auth in a development project using
a Mailtrap Email Sandbox.

Observed behavior

1. Open Authentication → Emails → SMTP Settings.
2. Enable Custom SMTP.
3. Complete all required fields:
   • SMTP sandbox host;
   • port 587;
   • username and password;
   • sender email and sender name;
   • minimum interval of 60 seconds.
4. Click Save changes.
5. The dashboard displays a success confirmation.
6. Reload the page.

After the reload, Custom SMTP is disabled again and all fields are empty. This
was reproduced twice on 2026-07-30. No validation error was displayed.

Because the SMTP configuration does not persist, the dashboard also prevents
editing the Magic Link or OTP email template.

Environment

• Supabase hosted project
• Region: Frankfurt
• Plan: Free
• Authentication email configuration
• SMTP provider: Mailtrap Email Sandbox

Safety note

This report intentionally excludes the project reference, SMTP password, API
keys, OTPs, tokens and user data.

Question

Is this a known dashboard or Auth configuration issue? Is there another
supported way to persist the Custom SMTP configuration, or a project setting I
should verify?

Support ticket: SU-435404.

[GaryAustin1]

Maybe this: https://status.supabase.com/incidents/w5pc099bpkdc

[kaminagakur4]

Retry the save now, and check the result with the Management API instead of reloading the page. The reload is what misled you the first time. The incident @GaryAustin1 linked is "Management API Performance Degradation", and it was open while you were reproducing this, both times. The SMTP form has no store of its own. It writes through the same auth config path as every other Auth setting, so a degraded Management API gives you exactly what you saw: the request looks fine, the toast fires, nothing gets saved, and no validation error appears because nothing was rejected. It's been fixed for over two weeks. So re-enter the settings, save, then run this with a personal access token:

curl -s -H "Authorization: Bearer $PAT" \
  "https://api.supabase.com/v1/projects/$REF/config/auth" \
  | jq '{smtp_host, smtp_port, smtp_user, smtp_admin_email, smtp_sender_name}'

What comes back is what the platform actually stored. If those fields have values, it worked. The same endpoint takes a PATCH with the same field names, so you can configure it that way and skip the dashboard entirely. That answers your question about another supported way.

One thing so you don't misread the output. The password box is always blank on load. The form rebuilds host, user, sender name and admin email from the saved config, but hardcodes the password to an empty string. An empty password field is normal even on a working setup. The other fields coming back empty is what made your case a real failure.

If it still fails today, it isn't the incident. Get the response body of the failing request from the network tab, not just the status code. The form only shows the error message in a toast and throws the rest away, and that body plus the GET output is what makes SU-435404 actionable.