Pour toute organisation dont le domaine envoie des e-mails
DMARC, SPF et DKIM : quelqu'un peut-il envoyer des e-mails en votre nom ?
Trois enregistrements déterminent si un inconnu peut mettre votre domaine dans le champ « De » d'un message convaincant. Une faille dans l'un d'eux suffit à rendre l'usurpation possible.
Les résultats d'analyse et l'application sont en anglais pour le moment.
SPF, DKIM et DMARC sont les trois enregistrements qui déterminent si quelqu'un peut envoyer des e-mails semblant provenir de votre domaine. Ils fonctionnent ensemble, et une faille dans l'un d'eux suffit à rendre possible une usurpation convaincante. Cette page explique le rôle de chacun, les défaillances courantes et comment les corriger sans perturber votre propre messagerie.
Ce que font réellement les trois enregistrements
Ils répondent à trois questions différentes, c'est pourquoi n'en publier qu'un seul laisse une faille. SPF indique quels serveurs peuvent envoyer pour votre domaine. DKIM ajoute une signature prouvant qu'un message a été autorisé et n'a pas été modifié. DMARC relie les deux à l'adresse que le destinataire voit réellement, et indique aux systèmes destinataires quoi faire lorsque les vérifications échouent.
- SPF : la liste des expéditeurs autorisés
- DKIM : les enregistrements de clés de signature publiés ; l'analyse n'examine pas les signatures des messages
- DMARC : la politique appliquée lorsque SPF et DKIM ne concordent pas
Pourquoi la politique DMARC est l'élément décisif
Un enregistrement DMARC peut demander aux systèmes destinataires de ne rien faire, de traiter les échecs avec méfiance ou de les rejeter purement et simplement. Publier un enregistrement qui ne demande rien est courant et souvent pris pour une protection : l'enregistrement existe, des rapports arrivent peut-être, et pourtant rien n'est réellement bloqué. Une politique publiée plus stricte demande un traitement plus strict aux destinataires ; elle ne garantit pas que l'usurpation soit bloquée. Changer de politique trop vite peut perturber le courrier légitime.
- Une politique de simple surveillance ne protège personne à elle seule : c'est un point de départ, pas une fin
- Avancez par étapes, en surveillant les rapports pour repérer les expéditeurs oubliés
- Lettres d'information, outils de tickets, CRM et logiciels de paie envoient tous en votre nom et doivent tous passer les vérifications
Les défaillances qui piègent les organisations
La plupart des problèmes d'authentification des e-mails n'ont rien d'exotique. Ils viennent d'un enregistrement rédigé il y a des années qui ne correspond plus à la façon dont l'organisation envoie ses e-mails.
- Des enregistrements SPF qui ont dépassé la limite de dix requêtes DNS fixée par la norme : l'enregistrement cesse alors d'être évalué et le courrier légitime commence à échouer
- D'anciens fournisseurs toujours autorisés longtemps après la fin du contrat, élargissant discrètement le cercle de ceux qui peuvent envoyer en votre nom
- DKIM configuré sur la plateforme principale mais pas sur les outils marketing ou de tickets
- Un enregistrement DMARC couvrant le domaine principal alors que les sous-domaines restent ouverts
- Des enregistrements correctement publiés puis défaits par une migration DNS que personne n'a revérifiée
Ce que cette vérification examine
Tout est lu dans le DNS public. Rien n'est envoyé, reçu ni intercepté, et aucune boîte aux lettres n'est touchée.
- La présence d'un enregistrement SPF, et le nombre de requêtes DNS qu'il nécessite
- Si la signature DKIM est configurée et détectable
- La présence d'un enregistrement DMARC et la politique qu'il demande aux destinataires d'appliquer
- MTA-STS, qui demande aux autres systèmes de messagerie d'utiliser une distribution chiffrée vers vous
- Les enregistrements complémentaires qui montrent avec quel soin la messagerie du domaine est gérée
Un ordre raisonnable pour corriger
Publiez d'abord SPF et DKIM et vérifiez que votre courrier authentique passe les deux. Ajoutez ensuite seulement DMARC en mode surveillance, lisez ce que disent les rapports pendant quelques semaines, et durcissez la politique une fois la liste des expéditeurs légitimes complète et conforme. Passer trop vite à l'application est la principale raison pour laquelle des organisations perdent du vrai courrier et font marche arrière.
- Corrigez SPF et DKIM avant de toucher à la politique DMARC
- Attendez-vous à découvrir des expéditeurs que personne ne se souvenait avoir autorisés
- N'oubliez pas les sous-domaines, y compris ceux que vous n'utilisez pas
Questions fréquentes
›DMARC ne concerne-t-il que les grandes organisations ?
Non. L'usurpation est plus facile et plus dommageable pour les petites organisations, car les destinataires réagissent plus volontiers à un e-mail qui semble venir d'une association, d'une école ou d'un fournisseur qu'ils connaissent. Publier ces enregistrements ne coûte rien.
›Nous avons un enregistrement DMARC. Sommes-nous protégés ?
Seulement s'il demande aux systèmes destinataires d'agir. Un enregistrement en simple surveillance rend compte de ce qui se passe et ne bloque rien : c'est une première étape raisonnable, souvent prise à tort pour un travail terminé. C'est la valeur de la politique qui compte.
›Pourquoi nos e-mails légitimes échouent-ils à SPF ?
Les causes les plus fréquentes sont un enregistrement SPF qui a dépassé la limite de dix requêtes DNS fixée par la norme, et un service d'envoi ajouté à la plateforme mais jamais ajouté à l'enregistrement. Les deux se corrigent sans changer votre façon d'envoyer.
›Durcir DMARC va-t-il casser notre messagerie ?
C'est possible, si c'est fait avant que chaque expéditeur légitime passe les vérifications. D'où l'importance de l'ordre : SPF et DKIM d'abord, puis DMARC en mode surveillance, puis l'application une fois les rapports propres. Dans cet ordre, le risque est faible.
›Cette vérification envoie-t-elle des e-mails ?
Non. Elle lit uniquement les enregistrements DNS publics. Rien n'est envoyé, reçu ni intercepté, et aucune boîte aux lettres n'est consultée.
Indicatif uniquement. Il s'agit d'une vérification externe des enregistrements DNS publics. Elle reflète ce que disent ces enregistrements au moment de la vérification et ne peut pas confirmer comment chaque message sera traité par chaque système de messagerie destinataire.
Également utile : vérifier un fournisseur avant de signer.