Dépassez les 2 emails/heure de Supabase avec Resend

2 emails par heure, c'est une blague ?

C'est la limite officielle du plan gratuit Supabase. Pour un test en solo sur votre machine, ça peut passer. Pour un projet réel avec de vraies personnes, c'est bloquant dès le premier jour.

Cette limite ne concerne pas uniquement les inscriptions. Elle s'applique à tous les emails envoyés par Supabase Auth : confirmations de compte, liens de connexion magiques, réinitialisations de mot de passe, changements d'adresse email. N'importe lequel de ces flux peut se retrouver silencieusement bloqué sans que votre code retourne la moindre erreur.

Pourquoi ne pas se contenter du SMTP intégré à Supabase ?

Supabase intègre bien un serveur d'envoi par défaut, mais il n'est pas conçu pour un usage en production. Outre la limite de 2 emails par heure, les emails partent depuis un domaine générique Supabase, ce qui pose deux problèmes concrets.

Le premier est la délivrabilité : un email envoyé depuis un domaine partagé par des milliers de projets a plus de chances d'atterrir en spam, parce que la réputation de l'expéditeur n'est pas la vôtre. Le second est l'image : vos utilisateurs voient une adresse noreply@mail.supabase.io au lieu d'une adresse liée à votre projet. C'est un détail qui trahit un produit non fini.

Supabase le sait et le documente lui-même : le serveur intégré est explicitement présenté comme un outil de développement, pas comme une solution de production.

Pourquoi ne pas configurer directement son propre SMTP ?

Techniquement, vous pouvez brancher n'importe quel serveur SMTP sur Supabase : celui de votre hébergeur, un serveur Postfix que vous gérez vous-même, ou même Gmail via un mot de passe d'application. C'est possible. C'est rarement une bonne idée.

Gérer un serveur SMTP, c'est gérer la délivrabilité, les listes noires, les enregistrements SPF, DKIM et DMARC, les rebonds, les plaintes. C'est un métier à part entière. Les services comme Resend s'occupent de tout ça pour vous : leur infrastructure est déjà configurée pour maximiser les chances que vos emails arrivent en boîte de réception plutôt qu'en spam.

Quant à Gmail, son SMTP est limité à 500 emails par jour et n'est pas prévu pour un usage applicatif. Si Google détecte un usage automatisé, le compte peut être bloqué. Ce n'est pas un risque qui vaut la peine d'être pris pour un projet en production.

Pour sortir proprement de cette impasse, la solution consiste à connecter Resend comme SMTP externe. Voici la configuration pas à pas, avec votre propre nom de domaine.

Étape 1 : créer un compte Resend et vérifier votre domaine

Rendez-vous sur resend.com et créez un compte gratuit. Une fois connecté, allez dans la section Domains et ajoutez votre nom de domaine. Resend vous donnera plusieurs enregistrements DNS à ajouter chez votre registrar : un enregistrement MX, un TXT pour SPF, et un CNAME pour DKIM.

Ajoutez ces enregistrements dans l'interface de gestion DNS de votre hébergeur ou registrar (OVH, Gandi, Cloudflare, etc.), puis cliquez sur Verify dans Resend. La vérification peut prendre quelques minutes selon la propagation DNS.

Étape 2 : récupérer les identifiants SMTP de Resend

Resend expose un accès SMTP en plus de son API REST. Pour obtenir les identifiants, allez dans API Keys et créez une nouvelle clé avec les permissions Full access (ou Sending access si vous préférez limiter les droits). Notez-la soigneusement, elle ne s'affichera qu'une seule fois.

Les paramètres SMTP de Resend sont fixes :

Étape 3 : configurer le SMTP dans Supabase

Dans votre tableau de bord Supabase, rendez-vous dans Project Settings → Authentication, puis faites défiler jusqu'à la section SMTP Settings. Activez l'option Enable Custom SMTP.

Remplissez les champs avec les informations suivantes :

L'adresse dans le champ Sender email doit appartenir au domaine que vous avez vérifié sur Resend. Si vous avez vérifié votredomaine.com, vous pouvez utiliser n'importe quelle adresse sur ce domaine : noreply@votredomaine.com, hello@votredomaine.com, etc.

Étape 4 : tester l'envoi

Supabase ne propose pas de bouton "Envoyer un email de test" depuis l'interface. La façon la plus simple de vérifier que tout fonctionne est de déclencher un vrai flux : tentez une inscription avec une adresse email que vous contrôlez, ou utilisez la fonction de réinitialisation de mot de passe.

Si l'email arrive rapidement et depuis votre domaine, la configuration est correcte. En cas de problème, consultez les logs dans Resend (section Emails) : chaque tentative d'envoi y est tracée avec le statut et l'éventuelle erreur. C'est nettement plus utile que les logs Supabase pour diagnostiquer un problème de délivrabilité.

Et la limite de Rate Limit côté Supabase Auth ?

Configurer un SMTP externe lève la limite d'envoi côté infrastructure email, mais Supabase Auth applique aussi ses propres rate limits sur les endpoints d'inscription et de connexion, indépendamment du SMTP. Ces limites sont configurables dans Project Settings → Authentication → Rate Limits.

Pour la plupart des projets en démarrage, les valeurs par défaut sont raisonnables. Mais si vous organisez un lancement avec un fort afflux d'inscriptions, c'est un paramètre à vérifier en même temps que la configuration SMTP.