Les e-mails de votre application partent-ils en spam ?

Pourquoi vos e-mails peuvent être rejetés

Quand votre application envoie un e-mail « de la part de » votre domaine, la messagerie qui le reçoit (Gmail, Outlook, Orange…) vérifie que l'expéditeur a bien le droit d'utiliser ce domaine. Sans preuve, l'e-mail part en spam, ou il est refusé. Depuis février 2024, Gmail et Yahoo exigent au minimum SPF ou DKIM de tout expéditeur, et les trois (SPF, DKIM et DMARC) de ceux qui envoient plus de 5 000 e-mails par jour ; Microsoft applique des règles comparables depuis mai 2025.

Ces preuves sont trois enregistrements dans la zone DNS de votre nom de domaine, chez votre hébergeur DNS, souvent votre registraire (OVH, Gandi, Cloudflare…) :

• SPF : la liste des serveurs autorisés à envoyer pour votre domaine ;
• DKIM : une signature ajoutée à chaque e-mail par votre service d'envoi ;
• DMARC : la consigne donnée aux messageries quand SPF ou DKIM échouent.

Vérification 1 : de quelle adresse partent vos e-mails ?

Envoyez-vous un e-mail depuis votre application (une confirmation de commande, une réinitialisation de mot de passe), puis regardez l'expéditeur.

Si l'adresse n'est pas à votre nom de domaine, mais quelque chose comme onboarding@resend.dev, noreply@mail.app.supabase.io ou l'adresse par défaut d'un outil, c'est un réglage de démonstration resté en production. C'est le constat D de notre diagnostic de Studio Kerelune. Ces adresses de démonstration sont très limitées : certaines n'écrivent qu'à l'adresse du titulaire du compte ou aux membres du projet, avec quelques e-mails par heure. Vos clients ne reçoivent alors rien du tout.

Vérification 2 : vos trois enregistrements

Ouvrez un outil de vérification en ligne gratuit (par exemple MXToolbox, avec ses recherches « SPF Record », « DKIM » et « DMARC » ; pour DKIM, il demande un « sélecteur », que votre service d'envoi vous indique), ou, si vous êtes à l'aise avec un terminal :

dig +short TXT votre-domaine.fr              # SPF : une ligne qui commence par v=spf1
dig +short TXT _dmarc.votre-domaine.fr       # DMARC : une ligne qui commence par v=DMARC1

Ce qu'il faut trouver :

• un seul enregistrement SPF (deux SPF sur un même domaine les rendent tous deux invalides), qui inclut chaque service qui envoie depuis votre domaine principal : votre messagerie (Google, Microsoft…), votre hébergeur s'il envoie aussi. Pour un service d'envoi transactionnel (Resend, Brevo, Mailgun…), ajoutez exactement les enregistrements qu'il vous donne : certains, comme Resend, utilisent un sous-domaine dédié ;
• une signature DKIM activée dans chacun de ces services : elle s'active dans leur interface, qui vous donne l'enregistrement à ajouter ;
• un enregistrement DMARC, même prudent pour commencer : v=DMARC1; p=none; rua=mailto:vous@votre-domaine.fr. Il vous envoie des rapports qui montrent qui envoie en votre nom.

Vérification 3 : le test d'envoi

Un service comme mail-tester.com vous donne une adresse de test : faites envoyer un e-mail de votre application à cette adresse, puis consultez la note obtenue. Elle détaille ce qui manque : SPF, DKIM, DMARC, contenu, liens. En dessous de 8 sur 10, une partie de vos clients ne reçoit probablement pas vos e-mails.

Vérification 4 : les rebonds

Quand une adresse n'existe pas ou refuse vos e-mails, votre service d'envoi le signale (on parle de rebond). Si votre application continue d'écrire à ces adresses, votre réputation d'expéditeur se dégrade, et ce sont tous vos e-mails qui finissent en spam. Vérifiez que les rebonds sont reçus, et surtout lus : une table qui les enregistre sans que rien ne s'en serve ne protège rien.

Vérifiez aussi ce que votre application affiche quand l'envoi échoue : « e-mail en cours d'envoi » alors qu'il n'est jamais parti laisse le client dans le doute.

Si vous avez trouvé un problème

Dans l'ordre : passer l'expéditeur sur votre propre domaine, corriger le SPF (un seul enregistrement sur votre domaine principal, et exactement les enregistrements que chaque service d'envoi vous donne), activer DKIM dans chaque service, ajouter un DMARC en p=none, puis refaire le test d'envoi. Les changements DNS prennent de quelques minutes à quelques heures. Quand les rapports DMARC sont propres pendant quelques semaines, vous pouvez durcir la consigne (p=quarantine).

Ce que cette vérification ne couvre pas

Le contenu des e-mails (des liens raccourcis ou un texte trop commercial peuvent aussi déclencher les filtres), les envois en masse et les désinscriptions, et ce qui se passe dans le reste de votre application quand un e-mail ne part pas. C'est ce que couvre l'axe « exploitation » de notre diagnostic.