Deux enregistrements SPF = PermError : le piège du doublon

La sanction exacte : permerror, et ce que DMARC en fait

Un permerror n'est pas un simple échec : c'est le verdict « configuration ininterprétable », réservé aux erreurs permanentes qu'une nouvelle tentative ne corrigera pas — par opposition au temperror d'un DNS momentanément injoignable. Ce que recouvre exactement ce verdict et ses autres causes possibles mérite un article entier ; retenons ici sa traduction opérationnelle : SPF ne produit plus jamais de « pass » pour le domaine, quelle que soit la source émettrice.

Côté DMARC, la conséquence est mécanique. DMARC valide un message si SPF ou DKIM produit un résultat positif aligné avec le domaine visible de l'expéditeur. Le permerror n'étant pas un pass, la jambe SPF de DMARC disparaît purement et simplement : toute l'authentification repose désormais sur DKIM seul. Les flux qui signent DKIM avec un domaine aligné survivent ; tous les autres — outil transactionnel non signé, serveur applicatif, copieur multifonction — basculent en échec DMARC complet. Sous p=quarantine ou p=reject, cela signifie mise en spam ou rejet pur et simple, et certains destinataires pénalisent en outre le permerror en tant que tel, indépendamment de DMARC.

Le plus insidieux : le doublon casse rétroactivement. Le second enregistrement ne s'ajoute pas au premier, il l'annule aussi — les autorisations historiques cessent d'être lues en même temps que les nouvelles. À p=none, rien de visible ne se produit et seuls les rapports trahissent le problème ; à p=reject, c'est un incident de production immédiat sur tous les flux qui ne tenaient que par SPF.

Le diagnostic en deux minutes : dig, puis les rapports

Le contrôle de première intention tient en une commande :

dig +short TXT exemple.fr
"v=spf1 include:spf.protection.outlook.com -all"
"v=spf1 include:sendgrid.net ~all"

Le décompte fait le diagnostic : deux lignes commençant par v=spf1, c'est le doublon, et chaque vérification du domaine retourne permerror. Une seule ligne : la piste est ailleurs. Sous Windows, nslookup -type=TXT exemple.fr rend le même service. La méthode complète de vérification d'un enregistrement SPF détaille les variantes de la commande et les pièges de lecture.

Les rapports agrégés DMARC offrent le second angle, précieux quand le doublon apparaît par intermittence ou a déjà été corrigé : un permerror SPF qui frappe toutes les sources en même temps est la signature d'un problème de domaine, pas d'un expéditeur particulier. L'historique donne même la date exacte de la bascule — le jour où toutes les lignes passent de pass à permerror est le jour où le deuxième enregistrement a été publié. Un détail de patience, enfin : après correction, les caches DNS continuent de servir les deux enregistrements jusqu'à expiration du TTL ; un diagnostic lancé juste après la modification peut mentir pendant quelques heures.

La fusion correcte : un seul enregistrement, un seul all

La réparation ne consiste pas à choisir un enregistrement et à supprimer l'autre — les deux contiennent généralement des autorisations légitimes — mais à les fusionner en un seul. La méthode : inventorier les mécanismes des deux enregistrements (include:, ip4:, ip6:, a, mx), les réunir derrière un unique v=spf1 de tête, dédupliquer, puis clore par un seul all. Sur l'exemple précédent, l'enregistrement consolidé devient :

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Trois règles de fusion évitent les mauvaises surprises. D'abord, le all final est unique et termine l'évaluation : tout ce qui suit le premier all rencontré est ignoré par les vérificateurs — un include placé après serait lettre morte. Ensuite, si les deux enregistrements se terminaient différemment (-all d'un côté, ~all de l'autre), le choix du qualificateur doit être délibéré : ~all pendant une phase d'observation, -all quand l'inventaire des sources est mûr. Enfin, l'ordre des mécanismes se lit de gauche à droite ; placer en tête les sources qui émettent le plus gros volume épargne quelques résolutions inutiles à chaque vérification.

La fusion est aussi le bon moment pour faire le ménage : un include d'un prestataire quitté depuis deux ans n'a rien à faire dans l'enregistrement consolidé. Et une vigilance impérative : additionner deux enregistrements additionne leurs résolutions DNS, or la limite des dix requêtes DNS s'applique à l'enregistrement fusionné — dépasser ce plafond recréerait un permerror par un autre chemin, celui-là même que la fusion venait de fermer.

Plusieurs chaînes dans un même TXT : le faux doublon parfaitement valide

Un affichage dig peut inquiéter à tort :

"v=spf1 include:spf.protection.outlook.com " "include:sendgrid.net -all"

Deux blocs entre guillemets, mais sur la même ligne : il s'agit d'un seul enregistrement TXT, composé de plusieurs chaînes de caractères. Le DNS limite chaque chaîne à 255 octets ; la RFC 7208 prévoit explicitement qu'un enregistrement puisse en contenir plusieurs, que le vérificateur concatène — sans insérer d'espace — avant l'évaluation. C'est le mécanisme standard pour dépasser les 255 caractères, détaillé dans l'article consacré à la limite de longueur d'un enregistrement SPF.

Le distinguo visuel est donc simple : deux lignes commençant par v=spf1, c'est deux enregistrements, donc permerror ; deux chaînes entre guillemets sur une même ligne, c'est un enregistrement, donc parfaitement valide. Seul piège du second cas : la concaténation se faisant sans séparateur, l'oubli d'un espace en fin de chaîne colle deux mécanismes en un jeton absurde (…outlook.cominclude:…) — une erreur de syntaxe qui, elle aussi, finirait en permerror.

La prévention : une revue à chaque nouvel outil

Le doublon étant presque toujours d'origine procédurale, la parade l'est aussi. La règle d'or tient en une phrase : « ajouter un prestataire d'envoi » ne signifie jamais « ajouter un enregistrement », mais toujours « modifier l'enregistrement existant ». Inscrite dans la procédure d'intégration de tout nouvel outil, cette phrase élimine à elle seule la cause numéro un du permerror de doublon.

Trois habitudes complètent le dispositif. Un propriétaire unique de la zone DNS — ou, a minima, une revue systématique des changements — pour que marketing et DSI ne publient plus chacun dans leur coin. Une vérification dig après chaque modification de la zone, dont le coût est de dix secondes. Et une surveillance continue des rapports DMARC : un permerror qui surgit simultanément sur toutes les sources est une alarme de doublon, détectable le jour même plutôt qu'au moment où la délivrabilité s'effondre. Les organisations qui tiennent un inventaire de leurs expéditeurs autorisés — le socle de toute remédiation DMARC sérieuse — interceptent d'ailleurs le doublon avant sa publication : le nouvel outil passe par l'inventaire, et l'inventaire passe par l'enregistrement unique.

En résumé

La RFC 7208 ne tolère qu'un enregistrement SPF par nom de domaine : dès le deuxième v=spf1, toutes les vérifications retournent permerror, SPF cesse d'exister pour le domaine, et DMARC ne tient plus que sur DKIM — avec, sous p=reject, un rejet sec de tous les flux non signés. Le doublon naît presque toujours d'une documentation prestataire suivie au pied de la lettre, d'une migration inachevée ou de deux équipes qui publient sans se concerter. Le diagnostic tient dans un dig TXT — compter les lignes v=spf1 — et dans les rapports, où un permerror simultané sur toutes les sources signe le problème. La réparation est une fusion : un seul enregistrement, mécanismes dédupliqués, un unique all final, et un œil sur le plafond des dix résolutions DNS. Quant aux chaînes multiples à l'intérieur d'un même TXT, elles sont valides — c'est le doublon d'enregistrements qui condamne, pas le découpage en chaînes.

Pour savoir en trente secondes si un domaine porte un doublon — ou tout autre défaut SPF, DKIM ou DMARC —, l'analyse DMARC gratuite rend un verdict immédiat, enregistrements décodés à l'appui. Et pour que le prochain outil branché par le marketing ne repasse pas le domaine en permerror sans que personne ne s'en aperçoive, la création d'un compte met en place la surveillance continue des rapports : le doublon de demain sera détecté le jour même, pas au prochain trou de délivrabilité.