Emails de réinitialisation jamais reçus : la dérive SPF, DKIM et DMARC

Votre fournisseur d'emails dit "livré", vos utilisateurs ne voient rien

Un ticket de support arrive : "Je n'ai jamais reçu l'email de réinitialisation du mot de passe." Puis trois autres. Le tableau de bord du fournisseur d'envoi affiche chaque message comme livré, les logs applicatifs montrent des envois réussis, et aucune alerte ne s'est déclenchée. Pourtant, les messages n'arrivent pas, ou atterrissent en spam. Voici comment ce genre de panne silencieuse se produit, et comment s'en prémunir dans une application Laravel ou Symfony.

Le scénario : une limite SPF franchie sans prévenir

L'article de Muhammad Ali Mughal sur DEV Community décrit un cas très parlant. Deux semaines avant les premiers tickets, l'équipe marketing avait ajouté un nouvel outil de newsletter à l'enregistrement SPF du domaine. L'enregistrement nécessitait alors onze résolutions DNS, alors que la limite est fixée à dix.

La conséquence est mécanique :

• le contrôle SPF retourne une erreur permanente (permerror) au lieu d'un résultat exploitable ;
• DMARC échoue pour tous les messages qui ne passent pas aussi l'alignement DKIM ;
• un grand fournisseur de boîtes mail se met à classer les emails transactionnels en spam.

Le point important est que rien, côté application, ne signale le problème : l'envoi a bien eu lieu, le serveur du destinataire a accepté le message, et c'est ensuite son filtrage qui décide du sort de l'email. "Envoyé" ne veut pas dire "reçu".

Pourquoi la configuration dérive avec le temps

SPF, DKIM et DMARC ne sont pas des réglages que l'on pose une fois pour toutes. Ils vivent dans la zone DNS, qui est modifiée par d'autres personnes que les développeurs : marketing, support, administrateurs système, prestataires. Chaque nouvel outil qui envoie des emails au nom du domaine (newsletter, CRM, outil de facturation, helpdesk) demande généralement un include: supplémentaire dans le SPF.

Or SPF impose un plafond de dix résolutions DNS par évaluation, et chaque include: peut lui-même en consommer plusieurs en cascade. Il suffit d'un ajout apparemment anodin pour basculer au-dessus de la limite. De la même façon, une clé DKIM peut être renouvelée côté fournisseur sans que l'enregistrement DNS correspondant soit mis à jour, ou une politique DMARC peut être durcie sans que tous les expéditeurs légitimes aient été alignés.

Ce phénomène de dérive explique pourquoi un système qui fonctionnait parfaitement peut se dégrader sans qu'aucun déploiement n'ait eu lieu côté code.

Comment détecter ces pannes avant vos utilisateurs

La défense tient en deux chantiers : surveiller la configuration DNS, et exploiter les retours de la chaîne d'envoi.

Surveiller les enregistrements DNS

Planifiez une vérification régulière (par exemple une commande Artisan ou une commande Symfony Console lancée par cron) qui, pour chaque domaine d'expédition :

• récupère l'enregistrement SPF et compte les résolutions DNS nécessaires, avec une alerte avant d'atteindre dix ;
• vérifie la présence et la validité des sélecteurs DKIM attendus ;
• contrôle que l'enregistrement DMARC existe et que sa politique correspond à ce qui est prévu ;
• compare l'état courant à une version de référence, et alerte à toute modification inattendue.

Ce contrôle est peu coûteux et transforme une panne invisible en alerte exploitable. Pensez à superviser aussi l'exécution de ce contrôle lui-même, faute de quoi vous reproduisez le problème des tâches planifiées qui ne tournent plus, évoqué dans le reste de la série.

Traiter les rebonds comme un flux de données

Les fournisseurs d'envoi renvoient des événements : rebonds durs et mous, plaintes pour spam, rejets. Branchez-les sur un webhook de votre application, stockez-les, et agissez :

• suppression automatique des adresses en rebond dur de vos listes d'envoi ;
• suivi du taux de rebond et de plainte par domaine destinataire ;
• alerte lorsqu'un grand fournisseur de messagerie voit son taux de rejet grimper d'un coup.

Un pic de rejets concentré sur un seul fournisseur est souvent le signe d'un problème d'authentification, plutôt que d'un problème d'adresses. Pensez aussi à tester régulièrement un flux complet (envoi d'un vrai email de réinitialisation vers des boîtes de test chez plusieurs fournisseurs) pour vérifier ce que voit réellement le destinataire.

Ce que ça change pour vous

Vos clients peuvent ne plus recevoir vos emails importants (réinitialisation de mot de passe, factures, confirmations) sans qu'aucun de vos outils ne vous prévienne. La cause est souvent un simple changement fait ailleurs, par exemple l'ajout d'un nouvel outil de newsletter à la configuration de votre nom de domaine. Demandez à votre prestataire technique de vérifier cette configuration, puis de mettre en place une surveillance qui vous alerte dès qu'elle change. C'est une vérification rapide, qui évite des clients perdus et des demandes de support inexpliquées.

En résumé

Un email accepté par le serveur du destinataire n'est pas un email lu, et la configuration d'authentification de votre domaine évolue au fil des outils que vous ajoutez. Surveiller le nombre de résolutions SPF, la validité DKIM, la politique DMARC et le flux des rebonds permet de repérer ces dérives avant que les premiers tickets n'arrivent.