L’authentification d’expéditeur a un mode de défaillance inhabituel : les enregistrements sont bons, les vérificateurs en ligne confirment qu’ils sont bons, et le message est quand même traité comme non authentifié. Cela tient au fait que les vérificateurs contrôlent ce que vous avez publié, tandis que le destinataire contrôle la relation entre cette publication et le message. Ce sont deux questions distinctes. Voici quatre façons dont nous avons vu la seconde recevoir une réponse négative alors que la première recevait une réponse positive, observées en configurant tout cela sur des domaines qui ne nous appartiennent pas.
01Ce qui est vérifié, c’est l’alignement, pas l’enregistrement
Un enregistrement SPF publié prouve qu’un serveur donné peut émettre pour un domaine donné. Une signature DKIM valide prouve qu’une clé a signé le message. Ni l’un ni l’autre n’indique que le domaine concerné est celui que le destinataire voit dans l’en-tête From, et c’est la seule chose que DMARC évalue.
Il y a donc deux domaines dans chaque message, et la plupart des outils ne vous en montrent qu’un. Le domaine From visible est ce que lit le destinataire. Le domaine du Return-Path, celui contre lequel SPF est réellement vérifié, est fixé par celui qui expédie, et par défaut c’est votre prestataire. Un message peut passer SPF parfaitement sur un nom d’hôte du prestataire pendant que DMARC enregistre un échec, parce que SPF a réussi pour un domaine qui n’est pas le vôtre.
DMARC n’a besoin que d’un des deux alignements, et c’est la partie à retenir. L’alignement SPF via un Return-Path personnalisé, ou l’alignement DKIM via une signature portant votre domaine : l’un ou l’autre suffit. C’est pourquoi un domaine peut afficher un SPF au vert et échouer quand même, et pourquoi corriger DKIM résout souvent un problème qui ressemblait à un problème de SPF.
02Le CNAME proxifié qui répond la mauvaise adresse
C’est celle qui nous a coûté le plus de temps, et elle produit le faux succès le plus convaincant des quatre. Les enregistrements d’authentification sont en général des CNAME vers la zone d’un prestataire. Chez un hébergeur DNS avec proxy, un CNAME peut être marqué pour faire passer le trafic par le proxy, et un enregistrement proxifié ne répond pas la cible. Il répond les adresses du réseau de diffusion, puisque c’est précisément sa raison d’être.
Pour un site web, c’est le comportement attendu et la raison pour laquelle on utilise ces services. Pour un sélecteur DKIM, c’est fatal d’une manière très précise : la résolution réussit. Le nom se résout, quelque chose répond, aucune erreur n’est signalée. Ce qui revient est un enregistrement d’adresse là où une clé était attendue, si bien que le vérificateur ne trouve aucune clé et considère le message comme non signé. Rien dans cette séquence ne ressemble à une erreur de configuration vue de l’extérieur.
Si cela se reproduit sans cesse, c’est que la valeur par défaut est pensée pour le cas courant. La plupart des enregistrements ajoutés à une zone concernent un site, et l’interface propose le proxy parce que c’est en général ce que l’on veut. Les enregistrements d’authentification sont l’exception, et ils sont ajoutés par quelqu’un qui suit des instructions ne disant rien d’une option inventée par son hébergeur DNS.
03Le sélecteur qu’on vous a donné est déjà utilisé
Un sélecteur DKIM est une étiquette qui permet à un même domaine de porter plusieurs clés à la fois. Les prestataires choisissent une valeur par défaut et la réutilisent sur tous les comptes qu’ils ont jamais ouverts, ce qui ne pose aucun problème jusqu’au jour où un domaine entretient deux relations avec le même prestataire.
L’un des domaines que nous authentifions en est un exemple vivant. Son prestataire attribue s1 et s2 par défaut, et les deux y sont déjà publiés au titre d’un compte antérieur au nôtre. Si nous avions accepté la valeur par défaut, nos enregistrements seraient entrés en collision avec des enregistrements en service sur un domaine que nous ne contrôlons pas, et la panne serait arrivée sous la forme de courrier cassé pour quelqu’un d’autre. Nous utilisons un sélecteur distinct pour exactement cette raison.
Il y a un second piège à l’intérieur du premier, et il ne se révèle qu’à l’émission de la deuxième clé. Les prestataires dérivent couramment le second sélecteur en ajoutant un chiffre au premier. Choisissez un sélecteur se terminant déjà par un chiffre et la paire obtenue n’est pas celle que vous attendiez. Nous avons retenu un nom sans chiffre final après avoir vérifié ce comportement sur l’API en production plutôt que dans la documentation.
- Interrogez les sélecteurs par défaut du prestataire sur le domaine avant d’ajouter quoi que ce soit. Des enregistrements existants signalent une relation existante dont personne ne vous a parlé.
- Ne supposez jamais qu’un domaine n’a qu’un prestataire de messagerie. Marketing, transactionnel, support et un contrat hérité, cela fait quatre relations et souvent quatre fournisseurs.
- Choisissez un sélecteur qui identifie l’expéditeur, pas l’année ni le numéro d’ordre. Il deviendra lisible dans le DNS pour quiconque auditera cette zone plus tard.
04Pointer vers le nom d’hôte du fournisseur en fait son enregistrement, pas le vôtre
Celle-ci n’est pas une panne du jour même, c’est une panne dix-huit mois plus tard, et c’est la raison pour laquelle nos enregistrements ne ressemblent pas à ceux que distribuent la plupart des services.
Un prestataire vous donne des CNAME vers sa propre zone, et le réflexe est de les transmettre tels quels au client. Cela fonctionne immédiatement. Cela place aussi un nom d’hôte du fournisseur dans une zone que vous ne contrôlez pas, une fois par client. Changer de prestataire revient alors à demander à chaque client de modifier son DNS, ce qui signifie en pratique qu’une partie d’entre eux ne le fera jamais et cessera discrètement de s’authentifier.
Nous faisons donc pointer les enregistrements des clients vers nos propres noms d’hôte, lesquels pointent vers le prestataire. Le saut supplémentaire coûte une résolution et transforme une migration en trois enregistrements dans une zone qui nous appartient, au lieu d’un courrier de masse. Une chaîne réelle se lit ainsi : le sélecteur du client, puis notre alias, puis la cible du prestataire, soit exactement ce que fait tout CNAME de fournisseur avec une indirection ajoutée au seul endroit où elle sert.
Le prix de cette conception est une nouvelle façon de se tromper, et mieux vaut la nommer que la cacher. Les cibles des prestataires contiennent des identifiants attribués et non garantis, dont un identifiant de pool susceptible de changer. S’il change, nos alias pointent vers quelque chose d’inutile et tous les clients cessent de s’authentifier d’un coup, sans bruit, parce que les enregistrements se résolvent toujours. Nous surveillons cette dérive de façon périodique, pour la même raison que nous surveillons tout le reste : la panne est invisible de l’intérieur.
05Le clic unique est une décision de prestataire, pas une norme
Demander à un client d’ajouter trois enregistrements, c’est là que l’intégration s’enlise, et la réponse standard s’appelle Domain Connect : le client est envoyé chez son propre hébergeur DNS, celui-ci l’authentifie, lui montre les enregistrements et les écrit s’il accepte. Personne ne confie d’identifiant à personne.
Ce qui prête facilement à confusion, c’est ce que publier un modèle vous apporte réellement. Le faire fusionner dans le dépôt public de modèles est nécessaire et non suffisant, car les prestataires intègrent les modèles un par un. Un modèle peut être public et correct pendant des années sans qu’un hébergeur DNS donné ne l’ait jamais servi.
Le modèle d’un fournisseur d’envoi bien connu est fusionné en amont depuis 2022. L’interroger aujourd’hui chez un grand hébergeur DNS renvoie un 404, ce qui veut dire que tous les clients de cet hébergeur ajoutent encore ces enregistrements à la main. Nous avons vérifié avant de supposer, parce que supposer aurait voulu dire montrer aux clients un bouton qui ne mène nulle part.
C’est la forme générale de tout ce qui précède. Demandez au prestataire s’il sert le modèle avant de proposer le bouton. Résolvez l’enregistrement et lisez son type avant de croire l’interface. Interrogez le sélecteur sur le domaine avant d’accepter une valeur par défaut. Dans chaque cas la vérification tient en une résolution, et s’en passer produit un système qui annonce une réussite sans rien délivrer.
En résumé, l’authentification est une relation entre un message et un domaine, et chacune des pannes ci-dessus est une rupture de cette relation plutôt qu’une erreur dans un enregistrement. Voilà pourquoi les enregistrements semblent corrects. Ils le sont. Ils ne sont simplement pas reliés à ce qui est vérifié, et le seul moyen fiable de s’en apercevoir est de résoudre ce que vous avez publié et de lire ce qui revient réellement.