Die Details unten stammen aus der Doku von Supabase vom 23. Oktober 2026. Prüfe sie auf aktuelle Limits und Einstellungen. Für die Grundlagen, also deine ersten Test-E-Mails senden und einen Absender einrichten, beginne mit Supabase Auth-E-Mails testen.
Die E-Mail kommt nie an
Der eingebaute Absender schickt keine E-Mails an deine Tester. Der eigene E-Mail-Dienst von Supabase liefert nur an Mitglieder des Teams deines Projekts, höchstens 2 E-Mails pro Stunde. Bei dir klappt es, weil du im Team bist; alle anderen lehnt er mit „Email address not authorized“ ab. Richte eigenes SMTP unter Authentication, Emails ein.
Dein SMTP-Anbieter ist noch in seiner Sandbox. Ein neues Resend-Konto sendet nur an deine eigene Adresse, bis du eine Domain verifizierst, und Amazon SES nur an Adressen, die du verifiziert hast. Supabase übergibt die E-Mail, und der Anbieter verwirft sie stillschweigend.
Du hast zu früh erneut angefragt. Standardmäßig kann jeder Nutzer alle 60 Sekunden eine Bestätigungs-, Magic-Link-, Code- oder Reset-E-Mail bekommen, und jede IP-Adresse kann 30 Registrierungs- und Anmeldeanfragen alle 5 Minuten stellen. Ein Test, der schnell wiederholt, oder eine Suite auf einer einzigen CI-Maschine stößt daran und bekommt einen 429. Erhöhe die Werte für dein Staging-Projekt unter Authentication, Rate Limits.
Die Adresse hat bereits ein Konto. Um nicht zu verraten, wer registriert ist, beantwortet Supabase eine Registrierung für eine bestätigte Adresse, als wäre sie gelungen, mit einem Nutzer ohne Identities, und sendet keine E-Mail. Ein Test, der eine Adresse wiederverwendet, wartet auf eine E-Mail, die nie kommt. Nutze für jeden Lauf eine frische Adresse.
„Confirm email“ ist ausgeschaltet. Dann meldet die Registrierung den Nutzer sofort an und sendet nichts. Prüfe Authentication, Sign In / Providers, Email. Oft wird es während der Entwicklung ausgeschaltet und nie wieder eingeschaltet.
Der Link gilt als ungültig oder abgelaufen
Du klickst den Link und landest in deiner App mit error_code=otp_expired („Email link is invalid or has expired“) in der Adresszeile.
- Er wurde schon benutzt. Links funktionieren einmal und gelten standardmäßig eine Stunde. Eine weitere angeforderte E-Mail ersetzt den früheren Link, also nutze den neuesten.
- Ein Scanner hat ihn zuerst geöffnet. Manche E-Mail-Dienste und Sicherheitstools von Firmen, etwa Link-Scanner, öffnen jeden Link in einer neuen E-Mail, um ihn zu prüfen. Das verbraucht einen Einmal-Link, bevor die Person klickt. Supabase empfiehlt, stattdessen einen 6-stelligen Code zu senden (
{{ .Token }}in der Vorlage) oder auf eine eigene Seite zu verlinken, auf der die Person zur Bestätigung einen Button drückt. Proxy Mail QA öffnet nie Links; wenn ein Link also in deinem Test funktioniert, bei echten Nutzern aber scheitert, ist wahrscheinlich ein Scanner die Ursache.
Der Link öffnet sich, aber niemand ist angemeldet
Er wurde in einem anderen Browser geöffnet. Beim PKCE-Flow, den die serverseitigen Helfer von Supabase nutzen, speichert der Browser, der die Registrierung gestartet hat, ein Geheimnis, das der Link braucht. Öffnest du den Link in einem anderen Browser, einem privaten Fenster oder auf einem anderen Gerät, scheitert der Austausch, oft mit „both auth code and code verifier should be non-empty“. Tester sollten den Link in dem Browser öffnen, in dem sie sich registriert haben. Für Links, die überall funktionieren, baue sie aus {{ .TokenHash }} und verifiziere sie auf deinem Server mit verifyOtp.
Nichts schließt die Anmeldung ab. Der Link landet in deiner App mit einem code (oder einem Token) in der Adresse, und irgendeine Seite muss ihn gegen eine Session tauschen. Fehlt diese Route, sieht die Person deine Startseite, abgemeldet. Prüfe, ob die Zielseite des Links exchangeCodeForSession aufruft oder verifyOtp mit dem Token-Hash.
Der Server sieht die Session nicht. Der Standardlink setzt die Session hinter ein # in der Adresse, das nur der Browser lesen kann. Serverseitig gerenderte Apps brauchen den Token-Hash-Link von oben.
Links führen zu localhost oder in die falsche Umgebung
Die Site URL ist anfangs http://localhost:3000, und jede redirectTo, die nicht in der Liste der Redirect URLs steht, fällt darauf zurück. Setze die Site URL auf die deployte App und trage jede Umgebung ein. Mehr unter warum E-Mails auf localhost verlinken; Proxy Mail QA markiert solche Links in der Zeile der Adresse.
Registrierung scheitert mit „Database error saving new user“
Etwas in der Datenbank hat den neuen Nutzer abgelehnt, fast immer ein Trigger auf auth.users, etwa einer, der eine Zeile in profiles anlegt. Häufige Ursachen: Die Tabelle oder eine Spalte, in die er schreibt, existiert nicht, die Funktion ist nicht security definer und kann daher nicht in public schreiben, oder eine Spalte, die sie füllt, ist not null und die Registrierung hat sie nicht mitgeschickt. Die Auth- und Postgres-Logs von Supabase zeigen den echten Fehler.
Teste auch mit unbequemen Werten: Ein Name mit Apostroph, einer anderen Schrift oder 255 Zeichen kann eine Profilspalte zerbrechen, die normale Testdaten nie erreichen. Ungewöhnliche Namen und Passwörter hat eine Liste zum Ausprobieren.
Die Reset-E-Mail kommt an, aber das Passwort ändert sich nicht
Ein Reset-Link meldet die Person mit einer Recovery-Session an und löst das Ereignis PASSWORD_RECOVERY aus. Deine App muss das bemerken, ein Formular für das neue Passwort zeigen und damit updateUser aufrufen. Tut sie das nicht, ist die Person einfach angemeldet, mit ihrem alten Passwort. Bei PKCE muss der Link außerdem in dem Browser geöffnet werden, der ihn angefordert hat. Mehr unter Passwort-Reset-E-Mails testen.
Captcha blockiert deine automatisierten Tests
Mit aktivem Captcha-Schutz (Authentication, Attack Protection) braucht jede Registrierung und Anmeldung ein Captcha-Token, also kommt ein automatisierter Browser nicht durch. Nutze in deinem Staging-Projekt die Testschlüssel deines Captcha-Anbieters, die immer bestehen, und behalte die echten Schlüssel für die Produktion.
Es funktioniert mit lokalem Supabase, aber nicht im gehosteten Projekt
Die Supabase CLI fängt lokale E-Mails in ihrem eigenen Mail-Viewer ab (meist unter localhost:54324) und liest Vorlagen aus supabase/config.toml. Das gehostete Projekt nutzt die Vorlagen, den Absender und die Rate Limits aus dem Dashboard. Teste vor dem Launch in einem gehosteten Staging-Projekt, mit echten E-Mails an eine Adresse, die sie empfängt.
Alles in einem Durchgang prüfen
- Erstelle für jedes Szenario eine frische Proxy Mail QA-Adresse: neuer Nutzer, bestehender Nutzer, Passwort-Reset, Magic Link.
- Geh den Ablauf in deiner App durch. Der Code oder Link erscheint innerhalb von Sekunden in der Zeile der Adresse.
- Sieh dir die Zeile an: Ein Link auf localhost wird markiert, und der Posteingang zeigt, ob die E-Mail sagt, wann ihr Link abläuft.
- Öffne den Link im selben Browser, in dem du dich registriert hast, und prüfe, dass du auf der richtigen Website angemeldet bist.
Mit Lovable, Bolt oder v0 gebaut? Probleme bei Registrierung und Login in vibe-codierten Apps behandelt, was solche Apps zusätzlich meist falsch machen.