Supabase "Email Rate Limit Exceeded": zwei Limits, ein Fehlercode

Du probierst dein Registrierungsformular aus, bevor du die App teilst. Du registrierst dich mit deiner eigenen Adresse, dann mit du+2@gmail.com, dann noch einmal, um zu sehen, ob die Bestätigungsmail gut aussieht. Einer dieser Versuche bleibt hier stehen:

AuthApiError: email rate limit exceeded

Supabase "Email Rate Limit Exceeded" heißt, dass dein Projekt sein Kontingent an E-Mails für diese Stunde aufgebraucht hat. Supabase Auth, der Teil von Supabase, der Leute anmeldet, hat deshalb keine weitere verschickt. Beim E-Mail-Dienst, mit dem jedes Projekt startet, liegt dieses Kontingent bei zwei E-Mails pro Stunde für das ganze Projekt.

Hier liegt der Teil, den man leicht falsch versteht: Der Fehlercode deckt zwei verschiedene Limits ab. Supabases eigene Liste der Auth-Fehlercodes beschreibt over_email_send_rate_limit als "Too many emails have been sent to this email address." Das stimmt für eines davon. Derselbe Code kommt auch zurück, wenn das ganze Projekt am Ende ist, egal an wen die E-Mail ging. Eine andere Adresse zu versuchen ändert also nichts. Und der übliche Rat, "verbinde deinen eigenen SMTP-Server", ist nur die halbe Lösung, denn Supabase startet einen neu verbundenen E-Mail-Server bei 30 E-Mails pro Stunde.

Was bedeutet "Email rate limit exceeded" in Supabase?

Dein Projekt hat in dieser Stunde so viele E-Mails verschickt, wie Supabase Auth erlaubt, und die nächste wurde abgelehnt.

Stell dir das Kontingent als Briefmarkenbogen vor. Supabase gibt jedem Projekt eine feste Zahl Marken pro Stunde, und jede E-Mail, die Supabase Auth verschickt, verbraucht eine, egal welche Art von E-Mail es ist und an wen sie geht:

• der Bestätigungslink, nachdem sich jemand registriert hat
• ein Magic Link oder ein Einmalcode zum Anmelden
• ein Passwort-Reset
• eine Einladung, die du über die Seite Users verschickst
• die Bestätigung, wenn jemand seine E-Mail-Adresse ändert

Ist der Bogen leer, antwortet Supabase Auth mit HTTP 429, was "zu viele Anfragen" bedeutet, mit dem Code over_email_send_rate_limit und der Meldung email rate limit exceeded. Diese Wörter stammen aus dem Code des Supabase-Auth-Servers selbst.

Beim eingebauten Absender, dem E-Mail-Dienst, mit dem ein neues Projekt startet, hat der Bogen zwei Marken pro Stunde. Das ist die Zahl auf Supabases Seite zu den Rate Limits, als wir sie am 20. Oktober 2026 gelesen haben, und Supabases Anleitung zu eigenem SMTP sagt über diese Zahl, sie "can change without notice". Bei zwei pro Stunde sind eine Registrierung und ein Passwort-Reset schon das ganze Kontingent der Stunde.

Kann sich niemand mehr anmelden, oder ist die ganze App leer, hast du ein anderes Problem, und ist Supabase ausgefallen oder deine App ist der richtige Anfang.

Zwei Limits teilen sich einen Fehlercode

Die Meldung sagt dir, welches Limit du erreicht hast. Der Code ist bei beiden derselbe:

Beide antworten mit HTTP 429 und over_email_send_rate_limit. Supabases Liste der Auth-Fehlercodes bittet dich, Fehler an ihrem Code zu erkennen und "not string matching on error messages". Für den Code deiner App ist das richtig, und es lässt hier eine Lücke: Nur die Meldung sagt, welches Limit du erreicht hast. Lies also die Meldung, um zu verstehen, was passiert ist, und lass deine App auf den Code reagieren.

Sagt deine App nur "etwas ist schiefgelaufen", steht die genaue Meldung in der Antwort auf die fehlgeschlagene Anfrage, im Tab Netzwerk der Entwicklertools deines Browsers. Ein Code over_request_rate_limit ist ein drittes Limit, für Anfragen von einer IP-Adresse, und laut Supabases Liste kann er auf einen Fehler in deiner App hinweisen, der zu viele davon schickt.

Warum steht da "you can only request this after 0 seconds"?

Weil von der Wartezeit weniger als eine Sekunde übrig war. Das Limit pro Adresse erlaubt eine E-Mail jeder Art an dieselbe Adresse alle 60 Sekunden: eine Bestätigung nach der Registrierung, ein Passwort-Reset, ein Magic Link oder Code. Fragst du früher erneut an, rechnet Supabase Auth aus, wie lange es noch dauert, und schreibt das in die Meldung.

Es zählt in ganzen Sekunden und lässt den Rest weg. Die Funktion im Auth-Server, die diese Meldung schreibt (errors.go), teilt die verbleibende Zeit durch eine Sekunde, also wird aus 0,8 Sekunden eine 0. Versuch es einen Moment später noch einmal, dann geht es durch, solange die Stundengrenze des Projekts noch eine Marke hat.

Diese Wartezeit tut, wofür sie gedacht ist. Sie sorgt dafür, dass ein Knopf zum erneuten Senden, zwanzigmal gedrückt, keine zwanzig E-Mails verschickt. Lass sie bei 60 Sekunden und lass dein Formular sie erklären.

Die Stundengrenze, und für wen sie gedacht ist

Der eingebaute Absender ist zum Ausprobieren von Supabase da, und Supabase sagt das in seiner SMTP-Anleitung. Dort steht, wofür der Dienst gedacht ist: "Exploring and getting started with Supabase Auth", "Setting up and testing email templates with the members of the project's team" und "Building toy projects, demos or any non-mission-critical application". Dazu kommt "No SLA guarantee on message delivery or uptime".

Dieselbe Anleitung hat eine zweite Regel, und sie entscheidet, wer welchen Fehler sieht. Bis du deinen eigenen E-Mail-Server verbindest, gilt: Supabase Auth "will refuse to deliver messages to addresses that are not part of the project's team". Ein Kunde, der sich mit seiner eigenen Adresse registriert, wird abgewiesen, bevor überhaupt eine Marke gezählt wird, mit einer anderen Meldung:

Email address "customer@example.com" cannot be used as it is not authorized

Das ist HTTP 400 mit dem Code email_address_not_authorized, und im Code des Auth-Servers läuft diese Prüfung vor beiden Limits. Wenn die Registrierung bei dir funktioniert und bei allen anderen scheitert, liegt es daran.

Beim eingebauten Absender trifft email rate limit exceeded also vor allem dich und dein Team, beim Testen. Wenn der Auth-Server prüft, ob eine Adresse zu deinem Team gehört, ignoriert er alles zwischen einem + und dem @. Damit zählen du+test1@gmail.com und du+test2@gmail.com beide als du, und jede Test-Registrierung verbraucht eine von denselben zwei Marken.

Wie erhöhe ich das E-Mail-Limit in Supabase?

Verbinde deinen eigenen E-Mail-Anbieter und erhöhe dann das Limit, das Supabase darauf setzt. Das sind zwei getrennte Schritte, und den zweiten übersehen viele.

1. Such dir einen Versanddienst aus und hol dir seine SMTP-Daten. Supabases Anleitung nennt Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail und Brevo und sagt, dass jeder Dienst funktioniert, der SMTP unterstützt. Du brauchst Host, Port, Benutzernamen und Passwort, dazu eine Absenderadresse wie no-reply@deinedomain.de.
2. Schalte eigenes SMTP ein, in den Authentication-Einstellungen deines Projekts, und trag diese Daten ein. Ab dann verschickt Supabase an jede Adresse.
3. Erhöhe das E-Mail-Limit auf der Seite Rate Limits, ebenfalls unter Authentication. Laut Anleitung bekommt ein neu verbundener Server "a low rate-limit of 30 messages per hour", um seinen Ruf zu schützen, und du änderst es dort. Stell es auf das, was dein Anbieter erlaubt und was deine geschäftigste Stunde braucht.

Drei weitere Dinge aus derselben Anleitung gehören zu dieser Änderung:

• Richte DKIM, DMARC und SPF ein, für deine Absenderdomain, bei deinem Anbieter. Supabase sagt, das "will significantly increase the deliverability of your messages".
• Schalte CAPTCHA für Registrierungen ein. Die Anleitung nennt Bots, die Listen von Adressen registrieren, "a common source of abuse", und jede dieser Registrierungen ist eine E-Mail aus deiner Stunde. CAPTCHA nennt sie "the most effective way", sie zu stoppen.
• Prüf, ob deine Nutzer abgemeldet werden. Laut Anleitung zwingen kurze Sitzungen "active users to sign in frequently, increasing the number of messages", und wenn sich deine Nutzer per E-Mail-Link anmelden, kostet jede unerwartete Abmeldung eine Marke. Warum Supabase-Nutzer abgemeldet werden erklärt die Ursachen.

Für die anderen Grenzen, an die ein kostenloses Projekt stößt, siehe was der kostenlose Supabase-Plan enthält.

Den Fehler im Registrierungsformular abfangen

Fang ihn an seinem Code ab und sag der Person in klaren Worten, was sie tun soll. Der JavaScript-Client von Supabase hängt den Code des Servers als error.code an den Fehler, den er zurückgibt, also ist die Prüfung eine Zeile:

const { error } = await supabase.auth.signUp({ email, password })

if (error?.code === 'over_email_send_rate_limit') {
  // anzeigen: "Wir konnten deine E-Mail gerade nicht senden. Bitte versuch es in einer Minute erneut."
}

Bitte deinen Builder, ob das Lovable, Bolt, v0, Cursor, Claude Code oder Replit ist, um drei Dinge:

• dieselbe Prüfung in jedem Formular, das E-Mails verschickt: Registrierung, "Passwort vergessen", Anmeldung per E-Mail-Link und "erneut senden"
• eine Meldung, die die Person bittet, es gleich noch einmal zu versuchen, an der Stelle des rohen Fehlers oder eines Formulars, das stumm nichts tut
• den Knopf zum erneuten Senden nach jedem Versand 60 Sekunden lang deaktiviert, damit ihn niemand in die Wartezeit pro Adresse hineindrückt

Verzichte auf automatische Wiederholungen. Solange der Bogen leer ist, wird jede Wiederholung abgelehnt, und Anfragen zur Registrierung sind zusätzlich pro IP-Adresse begrenzt, standardmäßig auf 30 alle 5 Minuten. Eine Wiederholungsschleife kann auch dieses Limit auslösen, und das antwortet mit over_request_rate_limit.

Was du nicht ändern solltest, solange Registrierungen hängen

Die E-Mail-Bestätigung, und von wo die E-Mails verschickt werden. Zwei Abkürzungen lassen den Fehler verschwinden und stellen dich schlechter.

Lass die E-Mail-Bestätigung an. Schaltest du "Confirm email" aus, verschicken Registrierungen gar nichts mehr, und der Fehler ist weg. Supabases SMTP-Anleitung führt "Do not disable email confirmations under pressure" unter ihren Schutzmaßnahmen auf, weil ohne Bestätigung jemand ein Konto im Namen einer anderen Person anlegen kann.

Halte die E-Mails aus dem Browser heraus. Bittest du einen Assistenten, "die Bestätigung einfach mit Resend zu verschicken", kann er den API-Schlüssel des Anbieters in den Frontend-Code deiner App schreiben, wo jeder Besucher ihn lesen und in deinem Namen Mails verschicken kann. Verschick E-Mails über die SMTP-Einstellungen von Supabase oder eine serverseitige Funktion, nie mit einem Schlüssel in der Seite. Wenn du nicht sicher bist, ob einer hineingerutscht ist: Unser kostenloser Scan liest den Code, den deine Live-App an jeden Besucher schickt, und meldet die geheimen Schlüssel, die er darin findet. Er dauert etwa 20 Sekunden und braucht kein Konto: scanne deine App.

Ein Auge auf die App, während du den E-Mail-Versand umbaust

Zwei Dinge können schiefgehen, während du den E-Mail-Versand neu verdrahtest: Ein Schlüssel landet im Code deiner App, und eine Nachricht wie "niemand kann sich registrieren" schickt dich auf die Suche nach einem Ausfall.

Reeve Monitor prüft weiter von außen:

• ob deine App erreichbar ist, jede Minute geprüft, damit du sofort weißt, ob eine Beschwerde über die Registrierung ein Ausfall ist oder etwas Engeres
• die vollständige Sicherheitsprüfung jede Stunde, für bis zu drei Apps, einschließlich geheimer Schlüssel im Code, den deine App an Besucher schickt
• eine Nachricht, wenn sich ein Ergebnis ändert, damit dich ein Schlüssel, der mit einem späteren Deploy hinausgeht, erreicht, ohne dass du nachsehen musst
• ein monatlicher Bericht in klarer Sprache über das, was er gesehen hat

Reeve Care bewahrt eine Kopie deiner Supabase-Datenbank auf:

• eine verschlüsselte Kopie nach Zeitplan, auf Reeves eigenem Speicher in der EU, außerhalb deines Supabase-Kontos
• das Auth-Schema, in dem jedes Konto liegt, das sich registrieren konnte
• jede Kopie geprüft, bevor sie zählt, indem die Zeilen jeder Tabelle gezählt werden
• auch deine hochgeladenen Dateien, sobald du einen Storage-Zugang verbindest
• eine Wiederherstellung mit einem Klick, vor der eine Sicherheitskopie des aktuellen Stands angelegt wird
• alles, was Monitor macht

Was du jetzt tun solltest

Fang mit der Meldung in der fehlgeschlagenen Antwort an, denn sie sagt dir, welches der beiden Limits du erreicht hast. Und sobald die E-Mails über deinen eigenen Anbieter rausgehen, scanne deine App, um zu prüfen, dass kein Schlüssel mitgekommen ist.