Configuration DKIM SPF DMARC pour les e-mails transactionnels

Ce que sont DKIM, SPF et DMARC dans l'authentification des e-mails

Lorsqu'un e-mail transactionnel quitte votre système, il ne doit pas seulement être envoyé. Il doit prouver qu'il appartient à l'endroit où il prétend appartenir. C'est le rôle de DKIM, SPF et DMARC : trois normes qui travaillent ensemble pour aider les serveurs de messagerie récepteurs à décider si un message est légitime.

SPF, ou Sender Policy Framework, indique au monde quels serveurs sont autorisés à envoyer des e-mails au nom de votre domaine. C'est une liste blanche basée sur DNS. Si votre message provient d'une adresse IP d'envoi approuvée, SPF peut passer. S'il provient d'ailleurs, il peut échouer.

DKIM, ou DomainKeys Identified Mail, adopte une approche différente. Il ajoute une signature cryptographique à l'en-tête du message. Le serveur destinataire vérifie cette signature par rapport à une clé publique publiée dans DNS. Si la signature correspond, le serveur sait que le message n'a pas été altéré en transit et qu'il a été signé par un domaine autorisé.

DMARC, ou Domain-based Message Authentication, Reporting and Conformance, se situe au-dessus de SPF et DKIM. Il indique aux serveurs récepteurs quoi faire si un message échoue à l'authentification, et il vérifie l'alignement : en termes simples, si le domaine utilisé dans l'adresse visible de l'expéditeur correspond au domaine validé par SPF ou DKIM. DMARC est la couche de politique qui relie le tout.

Utilisés ensemble, ces protocoles donnent aux systèmes récepteurs un signal plus fort que votre message est réel. Cela compte car un e-mail transactionnel n'est pas juste un autre envoi marketing. Un réinitialisation de mot de passe, un reçu de commande ou une alerte de sécurité arrivent souvent lorsque l'utilisateur s'y attend immédiatement. Si l'authentification est faible ou mal configurée, ces messages peuvent atterrir dans les spams, être signalés comme suspects ou ne pas arriver du tout.

Pourquoi les e-mails transactionnels ont besoin d'une authentification appropriée

Les e-mails transactionnels portent les moments pratiques d'une relation client. Ils incluent les réinitialisations de mot de passe, les messages de vérification de compte, les factures, les notifications d'expédition, les confirmations de reçu et les alertes de connexion. Ce sont les messages que les gens recherchent en premier lorsque quelque chose nécessite une attention.

C'est pourquoi une mauvaise authentification est plus qu'un simple désagrément technique. Si un reçu n'arrive pas, le client peut penser que le paiement a échoué. Si une alerte de sécurité est filtrée, l'utilisateur peut manquer une véritable menace. Si une réinitialisation de mot de passe va dans les spams, les tickets de support commencent à s'accumuler. En d'autres termes, la délivrabilité fait partie de l'expérience produit.

Il y a aussi un problème de confiance. Les filtres anti-spam et les fournisseurs de boîtes aux lettres sont prudents par conception, et ils traitent souvent les mails non authentifiés comme risqués. Même lorsque le contenu est parfaitement légitime, une réputation d'expéditeur faible ou une configuration d'authentification défaillante peuvent rendre le message peu fiable. Pour les mails transactionnels, cela est particulièrement douloureux car les utilisateurs s'attendent généralement à une livraison rapide et fiable.

Si vous pensez déjà à l'image globale de la délivrabilité, il peut être utile de regarder la chaîne complète plutôt qu'un paramètre isolé. L'authentification, la réputation de l'expéditeur, la qualité du contenu et la gestion des rebonds affectent tous le placement dans la boîte de réception. Pour une vue plus complète, consultez les outils de test de délivrabilité des e-mails.

Comment fonctionnent les enregistrements SPF et comment les configurer

Le SPF fonctionne en publiant un enregistrement DNS qui liste les serveurs autorisés à envoyer des mails pour votre domaine. Lorsqu'un serveur destinataire reçoit un message, il vérifie l'IP d'envoi par rapport à cet enregistrement. Si l'IP est incluse, le SPF peut passer. Sinon, le serveur peut traiter le message comme non autorisé.

Un enregistrement SPF est généralement stocké en tant qu'enregistrement TXT dans le DNS. Il commence souvent par v=spf1, suivi de mécanismes tels que ip4, ip6, ou include, et se termine par un qualificateur tel que -all ou ~all. La structure exacte dépend de votre infrastructure et de votre fournisseur.

Pour une configuration d'email transactionnel, vous devez généralement identifier chaque service qui envoie des mails en votre nom. Cela peut inclure votre serveur d'application, votre plateforme de livraison d'emails, votre service d'assistance, ou un outil de facturation. Chacun doit être pris en compte dans l'enregistrement SPF s'il envoie depuis votre domaine.

Une configuration simple pourrait autoriser un fournisseur d'email via une déclaration d'inclusion. Une configuration plus complexe pourrait lister une IP d'envoi dédiée et un ou plusieurs services tiers. L'important est de ne pas deviner. N'autorisez que les systèmes que vous utilisez réellement.

Il y a quelques règles pratiques à retenir :

• Publiez uniquement un enregistrement SPF par domaine.
• Gardez l'enregistrement aussi concis que possible.
• Assurez-vous que les IP d'envoi et les déclarations d'inclusion sont correctes et à jour.
• Utilisez le bon qualificateur à la fin, en fonction de la manière dont vous souhaitez que les mails non autorisés soient traités.

Le temps de propagation compte aussi. Les changements DNS n'apparaissent pas toujours partout immédiatement, donc après avoir mis à jour le SPF, laissez du temps pour que les enregistrements se propagent avant de supposer que la configuration est terminée.

Configuration de DKIM pour les emails transactionnels

DKIM donne à chaque message sortant une signature numérique. Le serveur qui envoie l'email utilise une clé privée pour signer les en-têtes sélectionnés et le corps du message. Le serveur récepteur recherche la clé publique correspondante dans le DNS et vérifie si la signature est valide.

En pratique, cela signifie que vous avez besoin de deux éléments : une clé privée conservée par votre système ou fournisseur d'envoi, et une clé publique publiée dans le DNS. L'enregistrement DNS se trouve généralement sous un sous-domaine spécifique au sélecteur, ce qui vous permet de faire tourner les clés plus tard sans tout casser d'un coup.

La plupart des fournisseurs d'emails transactionnels vous guident à travers cette configuration avec quelques étapes standard :

1. Générez ou demandez une paire de clés DKIM.
2. Ajoutez la clé publique du fournisseur à votre DNS en tant qu'enregistrement TXT.
3. Choisissez le sélecteur qui sera utilisé dans la signature DKIM.
4. Activez la signature dans votre plateforme ou application d'envoi.
5. Envoyer un message de test et confirmer que la signature est présente et valide.

Cela semble simple, et souvent c'est le cas, mais les détails comptent. Si le sélecteur est mal saisi, le serveur récepteur ne trouvera pas la bonne clé publique. Si la clé privée n'est pas active du côté de l'expéditeur, l'email sera envoyé sans signature. Si un autre système modifie le message après qu'il ait été signé, la signature peut échouer.

Une habitude utile est de considérer DKIM comme faisant partie d'une chaîne de conservation. Le message est signé lorsqu'il quitte votre système, et la signature dit : « Cette version vient de moi. » Si un service de pied de page, une passerelle ou un système de transfert modifie l'email plus tard, la signature peut se briser. Cela ne signifie pas toujours que le message est malveillant, mais cela peut affecter la façon dont les fournisseurs de boîtes aux lettres le traitent.

Pour les fournisseurs transactionnels, l'objectif habituel est de signer tous les courriers sortants du domaine ou sous-domaine concerné et de maintenir un comportement de signature cohérent à travers chaque type de message. Les réinitialisations de mot de passe et les reçus ne devraient pas être traités comme des cas spéciaux à moins que votre architecture ne l'exige.

Configurer DMARC pour protéger votre domaine

DMARC est l'endroit où l'authentification devient une politique. Il indique aux serveurs récepteurs comment gérer les messages qui échouent à SPF ou DKIM, et il vous permet également de recevoir des rapports sur les mails envoyés avec votre domaine.

Un enregistrement DMARC est également publié dans le DNS sous forme d'enregistrement TXT, généralement sous _dmarc.votredomaine.com. Il inclut une valeur de politique qui peut commencer en mode de surveillance et évoluer vers l'application. Les options de politique courantes sont :

• aucun — surveiller le trafic et collecter des rapports sans bloquer le courrier.
• quarantaine — suggérer que le courrier échouant doit être traité avec suspicion, souvent livré dans le spam.
• rejeter — demander que le courrier échouant soit bloqué complètement.

DMARC dépend également de l'alignement. SPF ou DKIM peuvent passer techniquement, mais si le domaine authentifié ne s'aligne pas avec le domaine visible de l'expéditeur, DMARC peut toujours échouer. C'est pourquoi les expéditeurs tiers et les sous-domaines nécessitent une configuration soigneuse. Un message de billing@votredomaine.com doit être authentifié d'une manière qui se connecte à votredomaine.com, et non à un domaine d'envoi non lié.

La plupart des équipes commencent par une politique de surveillance afin de voir comment le courrier se comporte avant de prendre des mesures. C'est sensé. Les rapports vous aident à découvrir des outils oubliés, des anciennes plateformes qui envoient encore du courrier, et des erreurs de configuration qui resteraient autrement cachées. Une fois que vous êtes sûr que le courrier légitime s'authentifie correctement, vous pouvez passer à la quarantaine ou au rejet.

Les rapports DMARC peuvent sembler denses au début, mais ils sont extrêmement utiles. Ils montrent qui envoie du courrier pour votre domaine, si SPF et DKIM passent, et où l'alignement échoue. Si vous essayez d'améliorer la santé globale de votre configuration d'expéditeur, c'est l'un des endroits les plus clairs à examiner.

Erreurs courantes de configuration DKIM SPF DMARC

Même une configuration bien intentionnée peut mal tourner de petites manières mais dommageables. Les erreurs les plus courantes ne sont généralement pas dramatiques. Ce sont les erreurs de configuration silencieuses qui persistent jusqu'à ce que la délivrabilité commence à diminuer.

• Publier plusieurs enregistrements SPF pour le même domaine au lieu d'un enregistrement consolidé.
• Oublier d'inclure un service d'envoi qui est activement utilisé pour le courrier transactionnel.
• Utiliser le mauvais sélecteur DKIM ou copier la clé publique dans le mauvais nom DNS.
• Permettre la désactivation de la signature DKIM sur certains types de messages mais pas d'autres.
• Définir une politique DMARC avant de vérifier que tout le courrier légitime s'aligne correctement.
• Changer de fournisseur sans mettre à jour les références SPF, DKIM et DMARC dans l'ensemble de la pile.

Les erreurs d'alignement méritent une attention particulière. Il est facile de croire que l'authentification « fonctionne » parce qu'un outil de test indique que SPF a réussi ou que DKIM a réussi. Mais DMARC vérifie si ces réussites sont alignées avec le domaine From. C'est là que de nombreuses configurations échouent dans la réalité.

Un autre problème courant apparaît lorsque les équipes ajoutent des outils de transfert, de routage ou de traitement des messages qui modifient les en-têtes. Parfois, l'email arrive toujours, mais les résultats d'authentification changent. Si vous remarquez un changement soudain dans le placement dans la boîte de réception, il vaut la peine de vérifier si quelque chose dans le chemin de livraison réécrit ou relaie le message.

Et oui, les erreurs DNS se produisent plus souvent que les gens ne l'admettent. Une citation manquante, un sélecteur copié avec le mauvais label, ou une déclaration d'inclusion périmée peuvent suffire à casser l'authentification. L'approche la plus sûre est de vérifier chaque changement après sa publication plutôt que de supposer que le tableau de bord reflète instantanément la réalité.

Tester et Vérifier Votre Configuration d'Authentification

Une fois les enregistrements en place, le test est l'endroit où la théorie rencontre la boîte de réception. Envoyez un message transactionnel réel et inspectez les en-têtes du message. Vous voulez voir des résultats clairs de réussite pour SPF, DKIM et DMARC, ainsi que les domaines qui ont été évalués.

La plupart des fournisseurs de boîtes aux lettres incluent des détails d'authentification dans la source brute du message. Recherchez des champs qui indiquent si le SPF a réussi, si le DKIM a produit une signature valide et si le DMARC a réussi l'alignement. Si l'un d'eux échoue, l'en-tête donne souvent un indice sur la raison.

Il est également utile de tester depuis plus d'un fournisseur de boîtes aux lettres, car différents systèmes peuvent afficher les résultats d'authentification différemment. Un message qui semble correct dans une boîte de réception peut révéler un problème dans une autre. Ce n'est pas inhabituel, juste ennuyeux.

Lors de la vérification des e-mails transactionnels spécifiquement, testez les messages qui comptent le plus : réinitialisations de mot de passe, confirmations d'inscription, avis de facturation et alertes. Ne vous fiez pas seulement à un simple « e-mail de test » de votre fournisseur, car le système réel peut utiliser des en-têtes différents, un routage différent ou une identité d'expéditeur différente.

Si vous n'êtes pas sûr que votre configuration tienne le coup dans le temps, un examen périodique des en-têtes et des enregistrements DNS vaut l'effort. Vous n'avez pas besoin de le compliquer ; vous avez juste besoin d'une habitude répétable. Pour une vérification pratique, les outils et méthodes couverts dans outils de test de délivrabilité des e-mails peuvent vous aider à confirmer où le message atterrit réellement et comment il est évalué.

Meilleures pratiques pour maintenir l'authentification des e-mails dans le temps

L'authentification n'est pas un projet ponctuel. C'est une tâche de maintenance. Les domaines changent de mains, les fournisseurs sont échangés, de nouveaux produits commencent à envoyer des e-mails, et les anciens systèmes persistent plus longtemps que quiconque ne s'y attend. Si vous ne revisitez pas le SPF, le DKIM et le DMARC périodiquement, un dérive finira par s'installer.

Une bonne routine de maintenance comprend quelques habitudes simples :

• Vérifiez les enregistrements DNS après tout changement de fournisseur ou d'infrastructure.
• Auditer chaque système qui envoie des e-mails depuis votre domaine ou sous-domaine.
• Vérifier les rapports DMARC pour des sources inconnues ou un alignement échouant.
• Vérifier que les clés DKIM sont toujours actives et que les sélecteurs correspondent à la configuration d'envoi.
• Confirmer que le SPF n'est pas devenu un enregistrement long et fragile rempli d'inclusions obsolètes.

Il est également judicieux de documenter qui possède chaque enregistrement et pourquoi il existe. De cette façon, lorsque quelqu'un demande pourquoi un certain service apparaît dans le SPF, vous n'avez pas à rétroconcevoir l'historique de mémoire et d'anciens tickets.

Lorsqu'un nouveau fournisseur d'e-mails est introduit, considérez l'authentification comme faisant partie de l'intégration, et non comme une réflexion après coup. Demandez comment le fournisseur gère l'alignement SPF, DKIM et DMARC. Confirmez s'ils signent des e-mails pour votre domaine, s'ils ont besoin d'un sélecteur personnalisé et si leurs adresses d'envoi correspondent à vos objectifs de politique.

Enfin, gardez un œil sur l'expérience utilisateur. Si les réinitialisations de mot de passe commencent à échouer ou si les reçus deviennent peu fiables, ne supposez pas que le problème vient du contenu ou du design. Vérifiez d'abord la trace d'authentification. Dans les e-mails transactionnels, le plus petit enregistrement DNS peut avoir le plus grand effet pratique.

Pour les équipes qui souhaitent un manuel plus large sur la réputation et le placement dans la boîte de réception, les conseils dans les meilleures pratiques de délivrabilité des e-mails peuvent également être utiles, surtout lorsque l'authentification n'est qu'une partie d'un tableau de délivrabilité plus large.

Bien fait, la configuration DKIM SPF DMARC pour les e-mails transactionnels crée une base solide. Cela indique aux fournisseurs de boîtes aux lettres que votre mail est légitime, aide à protéger les utilisateurs contre le spoofing et donne à votre propre équipe un chemin plus clair pour le dépannage. Le résultat est simple : une livraison plus fiable pour les messages dont les gens ont réellement besoin.