SPF, DKIM ou DMARC ne fonctionne plus ? Comment trouver la cause

Une authentification qui passait depuis deux ans peut échouer un mardi sans aucun message d'erreur et sans changement dont vous vous souveniez. Les e-mails quittent toujours vos serveurs. Ils arrivent simplement en spam, ou sous forme d'échec DMARC dans un rapport que vous n'avez pas ouvert, ou pas du tout. Ce guide explique ce qui casse le plus souvent SPF, DKIM et DMARC après qu'ils ont fonctionné, comment trouver la cause en quelques minutes avec quelques requêtes DNS, et comment apprendre la prochaine régression avant que votre taux de rebond ne le fasse.

La réponse en bref#

Quand une authentification qui fonctionnait se met à échouer, quelque chose a changé dans le DNS ou chez l'expéditeur. Vérifiez dans cet ordre : a-t-on changé d'hébergeur DNS ou de serveurs de noms récemment, y a-t-il exactement un enregistrement SPF, le sélecteur DKIM du message en échec renvoie-t-il encore une clé, y a-t-il exactement un enregistrement DMARC sur _dmarc, et un nouvel outil d'envoi s'est-il mis à envoyer en votre nom ? Ces cinq questions expliquent la plupart des régressions. Lisez d'abord l'en-tête Authentication-Results d'un message en échec, car il vous dit lequel de SPF, DKIM ou DMARC a échoué et pour quel domaine. L'analyseur d'en-têtes d'e-mail affiche ces verdicts, et le vérificateur SPF, DKIM et DMARC montre ce que dit le DNS à l'instant.

Lisez d'abord le message en échec#

Ne devinez pas quel protocole a cassé. Ouvrez les en-têtes complets d'un message qui a échoué et repérez la ligne Authentication-Results ajoutée par le serveur destinataire.

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.example.com;
  dkim=fail header.d=example.com header.s=mail;
  dmarc=fail header.from=example.com

Trois détails comptent. spf= et dkim= indiquent quel contrôle a échoué. header.s est le sélecteur DKIM utilisé, qui vous donne le nom DNS exact à interroger. Et smtp.mailfrom ou header.d montrent quel domaine chaque contrôle a évalué, ce qui compte quand le message passe SPF pour un autre domaine que celui de l'en-tête From.

Interrogez ensuite les enregistrements en ligne de commande. Cela fonctionne sur macOS et Linux.

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Remplacez mail par le sélecteur de l'en-tête. Si vous ne le connaissez pas, comment trouver un sélecteur DKIM vous guide. Si la requête ne renvoie rien, l'enregistrement a disparu. Si elle renvoie quelque chose, lisez-le attentivement, car la section suivante explique comment un enregistrement peut exister et pourtant être cassé.

Cause 1 : une migration DNS a supprimé ou abîmé des enregistrements#

Passer à un nouvel hébergeur DNS, un nouveau registrar ou une nouvelle plateforme de site web est le déclencheur le plus courant. L'outil d'import copie ce qu'il comprend, en général les enregistrements A, CNAME et MX, et ignore ou réécrit discrètement les enregistrements TXT. Les symptômes : un domaine sans SPF, sans DMARC, ou avec un sélecteur DKIM qui ne se résout plus, le tout à partir de la date de migration.

Vérifiez trois choses après tout déménagement : les serveurs de noms pointent bien où vous le pensez, chaque enregistrement d'authentification existe chez le nouvel hébergeur, et les longues valeurs TXT sont arrivées intactes. Les longues clés DKIM sont la victime habituelle : certains hébergeurs les tronquent ou ajoutent des espaces parasites, et une clé coupée échoue à la vérification même si l'enregistrement « existe » (pourquoi les longues clés doivent être découpées). Les guides par fournisseur pour Cloudflare et Route 53 montrent comment chacun les gère, et changer de fournisseur de messagerie aborde le même piège côté messagerie.

Cause 2 : deux enregistrements SPF, ou deux enregistrements DMARC#

Un domaine ne peut publier qu'un seul enregistrement SPF et qu'un seul enregistrement DMARC. Cela casse discrètement quand la page de configuration d'un nouvel outil dit « ajoutez cet enregistrement TXT » et que quelqu'un ajoute une seconde entrée v=spf1 au lieu de modifier la première.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

Avec deux enregistrements comme ceux-ci, les destinataires renvoient une erreur permanente pour SPF : SPF échoue donc pour chaque message, y compris ceux des outils listés. La solution est de les fusionner en un seul enregistrement avec les deux includes avant ~all. La même règle s'applique à _dmarc : deux enregistrements DMARC, et les destinataires ignorent les deux. Gardez un œil sur le budget de lookups pendant la fusion, car chaque include: ajouté coûte des lookups DNS et la limite est de 10. SPF : trop de lookups DNS explique comment compter.

Cause 3 : une clé DKIM a été renouvelée, déplacée ou supprimée#

DKIM signe chaque message avec une clé privée et publie la moitié publique sur selector._domainkey.yourdomain.com. Si l'enregistrement DNS disparaît alors que l'expéditeur signe toujours avec ce sélecteur, tous les messages échouent à DKIM.

Cela arrive de plusieurs façons. Un fournisseur passe à un nouveau sélecteur et vous nettoyez l'ancien enregistrement trop tôt. Quelqu'un supprime des entrées _domainkey « inutilisées » lors d'un grand ménage du DNS. Un CNAME qui pointe vers une clé hébergée chez le fournisseur cesse de se résoudre parce que le fournisseur l'a modifiée ou que vous avez quitté le service. Ou la clé a été révoquée, ce qui se publie par une valeur p= vide.

Le test est simple : prenez le sélecteur du header.s du message en échec, interrogez selector._domainkey.yourdomain.com et vérifiez qu'il y a une valeur p= avec de vraies données de clé. Si le sélecteur est faux parce que l'expéditeur est passé à un nouveau, publiez le nouvel enregistrement que le fournisseur vous donne. Une rotation bien faite fait coexister l'ancienne et la nouvelle clé, comme le décrit le guide des sélecteurs.

Cause 4 : un nouvel expéditeur s'est mis à envoyer en votre nom#

Parfois vos enregistrements sont bons et c'est l'expéditeur qui a changé. Une équipe active un CRM, un helpdesk, un outil de facturation ou une plateforme de newsletters, et chacun commence à envoyer avec votre domaine dans l'adresse From. Si personne n'a ajouté ce service à SPF ni configuré sa clé DKIM, ses e-mails échouent à l'alignement SPF, peuvent ne rien passer du tout, et apparaissent comme des échecs dans les rapports DMARC.

Vous ne le verrez pas en regardant le DNS, puisqu'il n'a pas changé. Vous le verrez en regardant qui envoie réellement. C'est à cela que servent les rapports agrégés DMARC : une nouvelle source avec un faible taux de réussite en est la signature. Pour chacune de ces sources, soit vous l'authentifiez correctement (include dans SPF le cas échéant et, plus important, signature DKIM avec votre propre domaine), soit vous l'empêchez d'envoyer en votre nom.

Cause 5 : un enregistrement associé expiré ou modifié#

Quelques pannes se situent à côté de l'authentification plutôt qu'en son sein.

• Une cible CNAME a changé. De nombreux fournisseurs demandent de pointer un enregistrement vers leur nom d'hôte. S'ils le retirent ou si vous supprimez le CNAME, la clé ou le domaine de retour (return-path) cesse de se résoudre.
• Un hôte MX a perdu son adresse. Le courrier vers votre domaine se met à rebondir alors que l'authentification sortante est parfaite, parce que l'hôte nommé dans le MX n'a pas d'enregistrement A ou AAAA.
• La politique MTA-STS et le DNS ne sont plus synchronisés. L'enregistrement TXT _mta-sts est toujours là, mais le fichier de politique HTTPS ne liste plus vos hôtes MX actuels, ou le certificat d'un serveur de messagerie a expiré. Les expéditeurs qui détiennent une politique en mode enforce différent alors ou refusent les e-mails, tandis que ceux qui n'ont aucune politique en cache retombent simplement sur une livraison en clair, de sorte que les dégâts sont inégaux. Voir MTA-STS et TLS-RPT.
• DMARC a été durci. Quelqu'un est passé de p=none à quarantine ou reject. Des échecs qui existaient depuis toujours, comme un outil non authentifié ou du courrier transféré, vous coûtent désormais de la délivrabilité. L'échec n'était pas nouveau. La conséquence, si.

Détecter la prochaine régression tôt#

L'essentiel est détectable depuis le DNS seul, avant le moindre rebond, car l'état cassé est un enregistrement absent ou mal formé. L'exception, c'est tout ce qui se trouve derrière l'enregistrement DNS, comme un fichier de politique MTA-STS. Vérifiez, par ordre d'urgence :

1. MX est présent et chaque hôte se résout.
2. Exactement un enregistrement SPF, de syntaxe valide, avec 10 lookups ou moins.
3. Chaque sélecteur DKIM dont vous dépendez renvoie une clé avec une valeur p=.
4. Exactement un enregistrement DMARC avec une politique valide et une adresse rua=.

Vous pouvez le faire à la main après chaque modification DNS, et vous le devriez. Le défaut du contrôle manuel, c'est que la régression qui vous préoccupe survient quand personne ne regarde. La surveillance de la santé du domaine répète ces contrôles chaque jour sur chaque domaine couvert et vous envoie un e-mail quand un problème apparaît et de nouveau quand il disparaît. Les codes de problème correspondent à cette liste : SPF absent ou multiple, SPF au-delà de la limite de lookups, un include SPF qui ne publie aucun enregistrement, un sélecteur DKIM configuré sans clé ou révoqué, DMARC absent ou invalide, et problèmes de MX. Un article de référence, la surveillance de la santé du domaine e-mail, explique la vue d'ensemble et la fréquence de contrôle.

Deux détails méritent d'être connus. Vous indiquez vous-même les sélecteurs DKIM à surveiller, car un sélecteur manquant ne peut être signalé que s'il a été nommé. Et un délai dépassé du DNS produit « impossible à vérifier », pas une alerte : un résolveur capricieux ne vous réveille donc pas.

Ce que la surveillance ne détectera pas#

La surveillance DNS lit uniquement le DNS public. Elle ne peut pas savoir qu'un nouveau CRM s'est mis à envoyer en votre nom, qu'un enregistrement SPF valide oublie un expéditeur, ou qu'un fournisseur a renouvelé une clé que vous ne lui aviez pas indiquée. Les rapports agrégés DMARC montrent qui envoie réellement en votre nom, et le test de délivrabilité e-mail montre comment un vrai message s'authentifie. La liste complète des limites figure dans le guide de la surveillance de la santé du domaine.

Une authentification qui fonctionne prouve que vos e-mails sont bien les vôtres, pas que votre liste vaut la peine d'être contactée. Quand vous serez prêt à examiner la liste elle-même, l'offre gratuite de la page des tarifs vous donne 100 crédits qui lancent la vérification complète. Des enregistrements corrects ont encore besoin d'une liste saine derrière eux.