Envoyer des e-mails depuis son MVP : domaine, SPF, DKIM et DMARC expliqués

Introduction

Votre première version est en ligne. Un utilisateur s'inscrit, et le message de confirmation n'arrive jamais. Ou il arrive, mais dans les courriers indésirables. Ou encore, vous testez avec vos propres adresses et tout fonctionne, puis le premier vrai client ne reçoit rien. Ce scénario est l'un des plus fréquents au lancement d'un MVP, et il n'a rien à voir avec votre code : il tient à la manière dont les e-mails sont envoyés.

Ce guide explique, sans jargon inutile, comment envoyer des e-mails depuis un MVP : à quoi servent les e-mails transactionnels, pourquoi il faut un domaine à vous, et ce que signifient SPF, DKIM et DMARC. Il ne remplace pas la documentation de votre outil d'envoi, mais il vous dit quoi vérifier et quoi demander.

E-mail transactionnel ou e-mail marketing : deux usages distincts

Un e-mail transactionnel est déclenché par une action d'un utilisateur dans votre application : confirmation d'inscription, lien de connexion, réinitialisation de mot de passe, reçu de paiement, notification de commande. Un e-mail marketing est un envoi que vous décidez d'adresser à une liste : newsletter, annonce, relance commerciale.

La distinction compte pour une raison pratique : l'un est attendu immédiatement par la personne, l'autre est une communication que vous initiez. Resend, par exemple, recommande d'envoyer depuis un ou plusieurs sous-domaines plutôt que depuis le domaine principal, ce qui permet de séparer les e-mails marketing des e-mails transactionnels et d'isoler la réputation d'envoi.

Pour un MVP, commencez par le transactionnel : c'est lui qui conditionne l'inscription, la connexion et le paiement. La newsletter peut attendre.

Pourquoi l'envoi par défaut ne suffit pas

Beaucoup d'outils proposent un envoi d'e-mails prêt à l'emploi pour démarrer. C'est pratique pour tester, pas pour lancer. La documentation de Supabase est explicite : son service d'e-mails par défaut est fourni en « best-effort », pour l'exploration et les démonstrations, et non pour la production. Elle précise que les messages ne sont délivrés qu'aux adresses faisant partie de l'équipe du projet, que le quota est très bas (2 messages par heure à la date de consultation) et qu'il n'y a aucune garantie de livraison ni de disponibilité.

Concrètement : vos tests avec votre équipe fonctionnent, et le premier utilisateur extérieur ne reçoit rien. La documentation recommande de configurer un serveur d'envoi (SMTP) personnalisé pour tout usage hors tests. Avec un SMTP personnalisé, le débit initial est de 30 messages par heure, réglable ensuite.

Nous avions déjà évoqué ce piège dans l'article sur la connexion utilisateur d'un MVP. Cet article-ci va plus loin : une fois le service d'envoi choisi, comment faire pour que les messages arrivent vraiment.

Un domaine à vous, et un sous-domaine dédié

Un service d'envoi comme Resend envoie les messages depuis un domaine que vous possédez. Sa documentation indique qu'il faut ajouter et vérifier au moins un domaine pour pouvoir envoyer. La vérification rassure les fournisseurs de messagerie sur l'origine des messages.

Deux conséquences pour un fondateur :

• Il vous faut un nom de domaine. Si vous n'en avez pas encore, c'est l'étape à faire avant d'ouvrir les inscriptions. L'article sur la mise en ligne de la première version détaille hébergement et domaine.
• Il vaut mieux envoyer depuis un sous-domaine. Resend conseille par exemple un sous-domaine du type `updates.votredomaine.com` plutôt que le domaine racine, afin d'isoler la réputation d'envoi. Chaque sous-domaine doit être ajouté séparément.

Si vous envoyez déjà depuis une adresse qui a bonne réputation, la documentation recommande de la conserver plutôt que d'en changer sans raison.

SPF, DKIM, DMARC : ce que cela signifie

Ces trois sigles décrivent des enregistrements que vous ajoutez dans la configuration DNS de votre domaine (l'endroit où vous gérez votre nom de domaine). Leur rôle est de prouver qu'un message envoyé en votre nom l'est bien par vous ou par un service que vous avez autorisé.

• SPF liste les serveurs autorisés à envoyer des e-mails pour votre domaine.
• DKIM ajoute une signature à chaque message, que le destinataire peut vérifier à l'aide d'une clé publiée dans votre DNS.
• DMARC indique aux serveurs de messagerie quoi faire quand un message échoue aux contrôles SPF ou DKIM. Selon la documentation de Resend, un message est considéré comme authentifié s'il réussit SPF ou DKIM, pas nécessairement les deux.

Bonne nouvelle : en pratique, votre service d'envoi vous fournit les valeurs à copier. Vous n'avez pas à les écrire vous-même. Votre travail consiste à les coller dans votre gestionnaire de domaine, puis à cliquer sur « vérifier ».

Pourquoi c'est devenu incontournable

Google impose depuis le 1er février 2024 des exigences à tous les expéditeurs qui écrivent à des comptes Gmail : configurer l'authentification SPF ou DKIM pour les domaines d'envoi, utiliser une connexion TLS, et maintenir un taux de spam inférieur à 0,3 % dans Postmaster Tools. Pour les expéditeurs de plus de 5 000 messages par jour, s'ajoutent DMARC, l'alignement du domaine d'expédition et la désinscription en un clic pour les messages marketing.

Un MVP n'approche pas ces volumes, mais l'authentification de base s'applique dès le premier message vers Gmail. Google précise aussi qu'envoyer vers des comptes Gmail personnels demande une clé DKIM d'au moins 1 024 bits, et recommande 2 048 bits si votre fournisseur de domaine le permet.

Démarrer DMARC en mode surveillance

DMARC propose trois politiques : `none` (les messages sont acceptés, les échecs sont seulement surveillés), `quarantine` (les messages en échec vont en spam) et `reject` (ils sont refusés). Resend recommande de démarrer par `p=none` pour ne pas casser involontairement vos envois, puis de durcir seulement après avoir vérifié que tous vos messages réussissent DMARC.

Un enregistrement de départ ressemble à ceci, dans un enregistrement TXT nommé `_dmarc` : `v=DMARC1; p=none; rua=mailto:adresse-de-rapports@votredomaine.com;`. L'adresse `rua` reçoit des rapports agrégés sur les messages envoyés en votre nom.

Choisir son service d'envoi pour un MVP

Il en existe plusieurs : Resend, Brevo, Postmark, Mailgun, Amazon SES, ou le module d'e-mails de votre outil no-code. Nous avons vérifié les conditions d'un seul, Resend, et ne chiffrons donc que celui-là. À la date de consultation, son plan gratuit comprenait 3 000 e-mails par mois, avec une limite de 100 par jour et 3 domaines ; le plan Pro de départ était à 20 $ par mois pour 50 000 e-mails. Pour un MVP à ses débuts, c'est largement suffisant. Ces conditions peuvent évoluer : consultez la page tarifaire avant de décider.

Quel que soit le service, voici les critères qui comptent vraiment au lancement :

• Vérification de domaine claire, avec les enregistrements à copier.
• Intégration simple avec votre outil : vérifiez qu'il propose une connexion SMTP ou un connecteur pour votre plateforme.
• Journaux d'envoi visibles, pour savoir si un message a été envoyé, rejeté ou retardé.
• Plafonds compatibles avec votre usage, notamment le plafond quotidien.

Les messages eux-mêmes comptent aussi

L'authentification est nécessaire, pas suffisante. Quelques réflexes simples améliorent la réception :

• Un expéditeur reconnaissable : un nom et une adresse qui disent qui vous êtes, plutôt qu'une adresse « no-reply » anonyme.
• Un objet clair qui décrit l'action : « Confirmez votre inscription », pas un message promotionnel.
• Un seul appel à l'action par message transactionnel.
• Le suivi des clics désactivé pour les messages transactionnels, si votre outil l'active par défaut. Resend cite justement l'activation du suivi des clics pour le marketing seulement comme exemple de séparation des usages.
• Une montée en charge progressive : les documentations parlent de « warm-up » pour éviter les pics de volume sur un domaine neuf. N'envoyez pas des centaines de messages le premier jour.

Tester avant d'ouvrir les inscriptions

Le test le plus utile est aussi le plus simple : créez des comptes de test avec des adresses que vous ne contrôlez pas via votre équipe, sur plusieurs messageries (Gmail, Outlook, une adresse professionnelle). Déclenchez chaque e-mail de l'application et notez où il arrive.

Ce que vous cherchez : le message arrive-t-il, dans la boîte principale ou en spam ? Le lien fonctionne-t-il ? L'expéditeur est-il affiché correctement ? Consultez ensuite les journaux de votre service d'envoi pour confirmer que le statut est « délivré ». Pour une connexion par lien magique ou par code, testez aussi la situation où l'utilisateur redemande un lien plusieurs fois.

Gardez enfin une adresse de réponse surveillée : certains utilisateurs répondent aux e-mails automatiques pour signaler un problème. Les premiers utilisateurs sont précieux, comme le montre l'article sur la recherche de ses 100 premiers utilisateurs.

Check-list avant le lancement

• Un nom de domaine à vous et un sous-domaine dédié à l'envoi.
• Le service d'envoi relié à votre application (SMTP personnalisé ou connecteur).
• Le domaine vérifié chez le service, avec SPF et DKIM en statut « valide ».
• Un enregistrement DMARC en `p=none` avec une adresse de rapports.
• Tous les e-mails de l'application déclenchés et reçus sur au moins trois messageries.
• Les journaux d'envoi consultés, sans rejet ni retard inexpliqué.
• Les plafonds d'envoi du plan relus et jugés suffisants.
• Une adresse de réponse lue par un humain.

Les erreurs fréquentes

• Tester uniquement avec son équipe et conclure que tout fonctionne alors que le service par défaut ne livre qu'aux membres du projet.
• Ne pas relire ses DNS après un changement d'hébergeur de domaine.
• Passer DMARC en `reject` trop vite, avant d'avoir vérifié que tous les envois légitimes réussissent.
• Mélanger newsletter et e-mails de connexion sur le même sous-domaine.

Questions fréquentes

Faut-il savoir coder pour configurer SPF, DKIM et DMARC ?

Non. Votre service d'envoi vous donne les enregistrements à copier. Il faut en revanche savoir où se gère votre nom de domaine et pouvoir y ajouter des enregistrements DNS.

Pourquoi mes e-mails de test arrivent mais pas ceux de mes utilisateurs ?

Souvent parce que le service d'envoi par défaut de votre outil ne délivre qu'aux membres de l'équipe du projet. C'est le cas de Supabase d'après sa documentation. Configurez un SMTP personnalisé et testez avec des adresses externes.

Dois-je utiliser mon domaine principal pour l'envoi ?

Resend recommande plutôt un sous-domaine, pour isoler la réputation d'envoi et séparer le marketing du transactionnel.

Un plan gratuit suffit-il pour un MVP ?

Pour démarrer, souvent oui. Le plan gratuit de Resend, par exemple, comprenait 3 000 e-mails par mois avec un plafond de 100 par jour à la date de consultation. Vérifiez les limites de l'offre que vous choisissez avant de lancer une opération qui génère des pics d'inscriptions.

Conclusion

Envoyer des e-mails depuis un MVP n'est pas un chantier technique lourd, mais c'est un point de passage obligé : sans domaine vérifié et sans authentification, vos messages de connexion et de paiement risquent de ne jamais atteindre vos premiers utilisateurs. Le bon réflexe est de s'en occuper avant le lancement, avec un sous-domaine dédié, SPF et DKIM valides, DMARC en surveillance, et des tests sur de vraies boîtes.

Si vous construisez votre première version et voulez la cadrer avec un regard extérieur, la méthode MVP de StartupWeek détaille la démarche, et vous pouvez candidater avec votre projet.

Sources

• Google, « Email sender guidelines » (exigences pour les expéditeurs, en vigueur depuis le 1er février 2024) : https://support.google.com/a/answer/81126
• Resend, « Domains » : https://resend.com/docs/dashboard/domains/introduction
• Resend, « DMARC » : https://resend.com/docs/dashboard/domains/dmarc
• Resend, tarifs (consultés le 08/11/2026) : https://resend.com/pricing
• Supabase, « Send emails with custom SMTP » : https://supabase.com/docs/guides/auth/auth-smtp