Supabase "Email Rate Limit Exceeded": due limiti, un solo codice

Stai provando il modulo di registrazione prima di condividere l'app. Ti registri con il tuo indirizzo, poi con tu+2@gmail.com, poi ancora una volta per vedere se l'email di conferma ha un bell'aspetto. Uno di quei tentativi si ferma qui:

AuthApiError: email rate limit exceeded

Supabase "Email Rate Limit Exceeded" significa che il tuo progetto ha esaurito la sua quota di email per l'ora, quindi Supabase Auth, la parte di Supabase che fa accedere le persone, si è rifiutato di inviarne un'altra. Con il servizio email con cui parte ogni progetto, quella quota è di due email all'ora per l'intero progetto.

Ecco la parte che è facile capire al contrario: il codice d'errore copre due limiti diversi. L'elenco dei codici d'errore di Auth di Supabase descrive over_email_send_rate_limit come "Too many emails have been sent to this email address." È vero per uno dei due. Lo stesso codice torna anche quando l'intero progetto è a secco, chiunque fosse il destinatario dell'email, quindi provare un altro indirizzo non cambia nulla. E il consiglio solito, "collega il tuo SMTP", è metà della soluzione, perché Supabase fa partire un server email appena collegato da 30 email all'ora.

Cosa significa "Email rate limit exceeded" in Supabase?

Che il tuo progetto ha già inviato in quest'ora tutte le email che Supabase Auth consente, e la successiva è stata rifiutata.

Pensa alla quota come a un foglio di francobolli. Supabase dà a ogni progetto un numero fisso di francobolli all'ora, e ogni email che Supabase Auth invia ne usa uno, qualunque tipo di email sia e chiunque sia il destinatario:

• il link di conferma dopo che qualcuno si registra
• un magic link o un codice monouso per accedere
• una reimpostazione della password
• un invito che mandi dalla pagina Users
• la conferma quando qualcuno cambia indirizzo email

Quando il foglio è vuoto, Supabase Auth risponde con HTTP 429, che significa "troppe richieste", il codice over_email_send_rate_limit e il messaggio email rate limit exceeded. Queste parole vengono dal codice stesso del server di Supabase Auth.

Con il mittente integrato, il servizio email con cui parte un progetto nuovo, il foglio ha due francobolli all'ora. È il numero della pagina dei limiti di Supabase quando l'abbiamo letta il 20 ottobre 2026, e la guida SMTP di Supabase dice che "can change without notice". A due all'ora, una registrazione e una reimpostazione della password sono l'intera quota dell'ora.

Se nessuno riesce più ad accedere, o l'intera app è vuota, il problema è un altro, e Supabase è giù o è la tua app? è da dove partire.

Due limiti condividono un codice d'errore

Il messaggio ti dice quale limite hai raggiunto. Il codice è lo stesso per entrambi:

Entrambi rispondono HTTP 429 con over_email_send_rate_limit. L'elenco dei codici d'errore di Auth di Supabase ti chiede di riconoscere gli errori dal codice e "not string matching on error messages". Per il codice della tua app è giusto, e qui lascia un buco: solo il messaggio dice quale limite hai raggiunto. Quindi leggi il messaggio per capire cosa è successo, e lascia che la tua app reagisca al codice.

Se la tua app dice solo "qualcosa è andato storto", il messaggio esatto è nella risposta alla richiesta fallita, nella scheda Rete degli strumenti per sviluppatori del browser. Un codice over_request_rate_limit è un terzo limite, sulle richieste da uno stesso indirizzo IP, e l'elenco di Supabase dice che può indicare un bug nella tua app che ne invia troppe.

Perché dice "you can only request this after 0 seconds"?

Perché dell'attesa restava meno di un secondo. Il limite per indirizzo consente un'email di ogni tipo allo stesso indirizzo ogni 60 secondi: una conferma di registrazione, una reimpostazione della password, un magic link o un codice. Se la richiedi prima, Supabase Auth calcola quanto manca e lo scrive nel messaggio.

Conta in secondi interi e scarta il resto. La funzione del server di Auth che scrive questo messaggio (errors.go) divide il tempo rimasto per un secondo, quindi 0,8 secondi diventano 0. Riprova un attimo dopo e passa, purché al tetto orario del progetto resti un francobollo.

Questa attesa fa quello per cui esiste. È ciò che impedisce a un pulsante di reinvio, premuto venti volte, di mandare venti email. Lasciala a 60 secondi e fai in modo che il tuo modulo la spieghi.

Il tetto orario, e a chi è destinato

Il mittente integrato serve per provare Supabase, e Supabase lo dice nella sua guida SMTP. La guida elenca a cosa è destinato il servizio: "Exploring and getting started with Supabase Auth", "Setting up and testing email templates with the members of the project's team" e "Building toy projects, demos or any non-mission-critical application". Viene anche con "No SLA guarantee on message delivery or uptime".

La stessa guida ha una seconda regola, ed è quella che decide chi vede quale errore. Finché non colleghi il tuo server email, Supabase Auth "will refuse to deliver messages to addresses that are not part of the project's team". Un cliente che si registra con il proprio indirizzo viene respinto prima ancora che si conti un francobollo, con un altro messaggio:

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

È HTTP 400 con il codice email_address_not_authorized, e nel codice del server di Auth questo controllo viene prima di entrambi i limiti. Se la registrazione funziona quando la provi tu e fallisce per tutti gli altri, il motivo è questo.

Quindi, con il mittente integrato, email rate limit exceeded tocca soprattutto a te e al tuo team, mentre provate. Quando il server di Auth controlla se un indirizzo è del tuo team, ignora tutto quello che sta tra un + e la @. Così tu+test1@gmail.com e tu+test2@gmail.com contano entrambi come te, e ogni registrazione di prova usa uno degli stessi due francobolli.

Come alzo il limite di email di Supabase?

Collega il tuo provider email e poi alza il limite che Supabase gli mette. Sono due passi separati, ed è il secondo quello che si dimentica.

1. Scegli un servizio di invio e prendi i suoi dati SMTP. La guida di Supabase nomina Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail e Brevo, e dice che funziona qualsiasi servizio che supporti SMTP. Ti servono host, porta, nome utente e password, più un indirizzo mittente come no-reply@tuodominio.it.
2. Attiva l'SMTP personalizzato nelle impostazioni Authentication del tuo progetto e inserisci questi dati. Da lì in poi Supabase invia a qualsiasi indirizzo.
3. Alza il limite di email nella pagina Rate Limits, sempre sotto Authentication. La guida dice che un server appena collegato riceve "a low rate-limit of 30 messages per hour" per proteggerne la reputazione, e che lo cambi lì. Impostalo su quello che il tuo provider consente e su quello che serve alla tua ora più trafficata.

Altre tre cose della stessa guida vanno con questa modifica:

• Configura DKIM, DMARC e SPF per il tuo dominio di invio, presso il tuo provider. Supabase dice che questo "will significantly increase the deliverability of your messages".
• Attiva il CAPTCHA sulle registrazioni. La guida indica i bot che registrano elenchi di indirizzi come "a common source of abuse", e ognuna di quelle registrazioni è un'email presa dalla tua ora. Chiama il CAPTCHA "the most effective way" per fermarli.
• Controlla che i tuoi utenti non vengano disconnessi. Secondo la guida, le sessioni brevi costringono "active users to sign in frequently, increasing the number of messages", e se i tuoi utenti accedono con un link via email, ogni disconnessione inattesa costa un francobollo. Perché gli utenti di Supabase vengono disconnessi ne spiega le cause.

Per gli altri limiti in cui incappa un progetto gratuito, vedi cosa include il piano gratuito di Supabase.

Gestire l'errore nel modulo di registrazione

Intercettalo dal codice e di' alla persona cosa fare, in parole semplici. Il client JavaScript di Supabase mette il codice del server sull'errore che restituisce, come error.code, quindi il controllo è una riga:

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

if (error?.code === 'over_email_send_rate_limit') {
  // mostra: "Non siamo riusciti a inviare la tua email in questo momento. Riprova tra un minuto."
}

Chiedi al tuo strumento, che sia Lovable, Bolt, v0, Cursor, Claude Code o Replit, tre cose:

• lo stesso controllo in ogni modulo che invia email: registrazione, "password dimenticata", accesso con link via email e "invia di nuovo"
• un messaggio che chieda alla persona di riprovare a breve, al posto dell'errore grezzo o di un modulo che non fa niente in silenzio
• il pulsante di reinvio disattivato per 60 secondi dopo ogni invio, così nessuno può premerlo dentro l'attesa per indirizzo

Lascia perdere i tentativi automatici. Finché il foglio è vuoto ogni tentativo viene rifiutato, e le richieste di registrazione sono limitate anche per indirizzo IP, a 30 ogni 5 minuti per impostazione predefinita. Un ciclo di tentativi può far scattare anche quel limite, che risponde con over_request_rate_limit.

Cosa non cambiare mentre le registrazioni sono bloccate

La conferma via email, e il punto da cui partono le email. Due scorciatoie fanno sparire l'errore e ti lasciano messo peggio.

Lascia attiva la conferma via email. Disattivare "Confirm email" fa sì che le registrazioni non inviino più nulla, quindi l'errore sparisce. La guida SMTP di Supabase mette "Do not disable email confirmations under pressure" tra le sue difese, perché senza conferma qualcuno può creare un account a nome di un'altra persona.

Tieni le email fuori dal browser. Chiedi a un assistente di "mandare la conferma con Resend e basta" e può mettere la chiave API del provider nel codice frontend della tua app, dove ogni visitatore può leggerla e mandare posta a nome tuo. Invia le email tramite le impostazioni SMTP di Supabase o una funzione lato server, mai con una chiave nella pagina. Se non sei sicuro che non ne sia scivolata dentro una, la nostra scansione gratuita legge il codice che la tua app online invia a ogni visitatore e segnala le chiavi segrete che ci trova. Ci mette circa 20 secondi e non chiede un account: scansiona la tua app.

Tenere d'occhio l'app mentre cambi l'invio delle email

Due cose possono andare storte mentre rifai l'invio delle email: una chiave finisce nel codice della tua app, e un messaggio che dice "nessuno riesce a registrarsi" ti manda a cercare un guasto.

Reeve Monitor continua a controllare dall'esterno:

• se la tua app risponde, controllato ogni minuto, così sai subito se una lamentela sulla registrazione è un guasto o qualcosa di più circoscritto
• il controllo di sicurezza completo ogni ora, su un massimo di tre app, comprese le chiavi segrete nel codice che la tua app invia ai visitatori
• un messaggio quando un risultato cambia, così una chiave uscita con un deploy successivo ti raggiunge senza che tu debba andare a guardare
• un report mensile, in linguaggio semplice, di quello che ha visto

Reeve Care conserva una copia del tuo database Supabase:

• una copia cifrata secondo una pianificazione, sullo storage di Reeve nell'UE, fuori dal tuo account Supabase
• lo schema auth, dove vive ogni account che è riuscito a registrarsi
• ogni copia verificata prima di contare, contando le righe di ogni tabella
• anche i tuoi file caricati, appena colleghi una credenziale di Storage
• un ripristino con un clic, preceduto da una copia di sicurezza dello stato attuale
• tutto ciò che fa Monitor

Cosa fare adesso

Parti dal messaggio nella risposta fallita, perché ti dice quale dei due limiti hai raggiunto. Poi, quando le email partono dal tuo provider, scansiona la tua app per controllare che non sia arrivata anche una chiave.