Vérificateur SPF, DKIM & DMARC

SPF, DKIM et DMARC sont les trois enregistrements DNS qui décident si le courrier se réclamant de votre domaine est accepté ou rejeté. Ils fonctionnent en ensemble : SPF indique quels serveurs peuvent envoyer pour le domaine, DKIM signe le message par cryptographie pour qu’il ne puisse pas être altéré en transit, et DMARC relie les deux à l’adresse d’expéditeur visible et dit aux destinataires quoi faire lorsqu’une vérification échoue. S’il en manque un, les deux autres en font moins que vous ne le croyez : les usurpateurs se glissent dans l’interstice, et le courrier légitime finit en indésirable.

Ce vérificateur interroge les trois d’un coup depuis nos serveurs et vous répond en langage clair. Il analyse votre enregistrement SPF et compte les requêtes DNS qu’il déclenche par rapport à la limite stricte de dix, lit votre clé publique DKIM et estime sa longueur en bits, et évalue votre politique DMARC, de la simple surveillance au rejet complet. Un domaine en entrée, trois verdicts en sortie. Sans inscription, et rien concernant votre domaine n’est conservé.

SPF : quels serveurs peuvent envoyer pour votre domaine

Un enregistrement SPF est un unique enregistrement TXT sur votre domaine, commençant par v=spf1 et listant les hôtes autorisés à envoyer du courrier en votre nom. Chaque terme nomme des sources directement (ip4:, ip6:) ou renvoie ailleurs (include:_spf.google.com importe les plages de votre fournisseur, a et mx autorisent vos propres hôtes A/MX). Un serveur destinataire parcourt cette liste et vérifie si l’IP qui se connecte y figure. L’enregistrement se termine par un mécanisme all qui attrape tout ce qui n’a pas déjà été apparié, et le qualificateur de ce all résume toute la politique en un caractère.

Les qualificateurs, du plus strict au plus faible : -all (échec strict) demande aux destinataires de rejeter tout ce qui provient d’une source non listée ; ~all (échec souple) dit de traiter le message comme suspect tout en l’acceptant, choix pragmatique tant que vous n’êtes pas certain que votre liste est complète ; ?all (neutre) n’exprime aucun avis et ne vous apporte rien ; et +all autorise explicitement l’internet entier à envoyer en votre nom, ce qui relève presque toujours d’une erreur de configuration et annule l’intérêt de l’enregistrement. La plupart des domaines bien tenus se situent à ~all ou -all.

Le piège qui casse plus d’enregistrements SPF que tout autre est la limite de dix requêtes. Chaque terme include, a, mx, ptr, exists et redirect impose au destinataire une requête DNS, et ces requêtes s’imbriquent : un include peut contenir ses propres includes. La RFC 7208 plafonne le total à dix sur l’ensemble de la chaîne, et le dépassement provoque un permerror qui fait échouer tout l’enregistrement, en silence. C’est pourquoi les gros expéditeurs publient des enregistrements « aplatis » qui intègrent directement les plages d’IP au lieu d’enchaîner les includes. Le vérificateur compte votre total réel et récursif de requêtes, pour que vous sachiez combien de marge il vous reste avant de basculer.

DKIM : une signature qui prouve que le message est intact

DKIM ajoute une signature cryptographique à chaque message sortant. Votre serveur de messagerie détient une clé privée et signe chaque message ; la clé publique correspondante est publiée dans le DNS, et le destinataire s’en sert pour vérifier que les parties signées du message n’ont pas été modifiées après leur départ. Une signature valide prouve deux choses à la fois : le message provient bien d’un système détenant votre clé, et ses en-têtes et son contenu sont arrivés intacts.

La clé publique réside à un sélecteur : une étiquette que vous choisissez et qui donne à la clé son propre espace de noms dans le DNS, publiée à <selector>._domainkey.<domain>. Les sélecteurs existent pour que vous puissiez exploiter plusieurs clés à la fois (une par service d’envoi) et les renouveler sans interruption : publiez un nouveau sélecteur, basculez la signature dessus, puis retirez l’ancien. Le nom du sélecteur n’est pas secret, mais il ne se déduit pas du seul domaine ; vous le trouvez dans les instructions DNS de votre fournisseur de messagerie (Google utilise google, Microsoft 365 utilise selector1/selector2, beaucoup de plateformes d’envoi ont le leur) ou en lisant l’en-tête DKIM-Signature d’un message déjà reçu, où il apparaît comme le tag s=. Cet outil peut aussi sonder une liste de sélecteurs courants pour vous si vous l’ignorez.

La longueur de la clé compte. Une clé RSA de 1024 bits était la valeur par défaut historique et est désormais jugée faible : elle est à portée d’un attaquant déterminé et certains fournisseurs ont commencé à s’en méfier. 2048 bits est la référence actuelle et ce que vous devriez publier ; certaines installations utilisent des clés ed25519, courtes mais robustes. Renouvelez les clés périodiquement quelle que soit leur longueur, car une clé qui ne change jamais est une clé dont on ne se remet jamais en cas de fuite. Le vérificateur lit votre clé publiée et en estime la taille, pour distinguer d’un coup d’œil une clé moderne de 2048 bits d’une clé héritée de 1024 bits.

DMARC : alignement, politique et rapports

DMARC est l’enregistrement qui fait que SPF et DKIM aboutissent à quelque chose. Il réside à _dmarc.<domain> sous forme d’enregistrement TXT commençant par v=DMARC1 et remplit trois rôles : il exige l’alignement, le domaine ayant validé SPF ou DKIM doit correspondre au domaine d’expéditeur visible, ce qui referme la faille par laquelle un message valide SPF pour un domaine sans rapport tout en usurpant le vôtre ; il déclare une politique qui indique aux destinataires quoi faire quand un message échoue ; et il demande des rapports pour que vous voyiez qui envoie en votre nom.

La politique tient dans le tag p= et c’est une échelle que l’on gravit, pas un interrupteur que l’on bascule. p=none relève de la seule surveillance : les destinataires continuent de délivrer le courrier en échec mais vous envoient des rapports, et c’est exactement là que tout déploiement devrait commencer, pour observer le trafic sans rien casser. p=quarantine demande aux destinataires de traiter le courrier en échec comme suspect, généralement en le rangeant dans les indésirables. p=reject leur demande de le refuser purement et simplement, et constitue l’état final qui met vraiment fin à l’usurpation. Deux autres tags règlent le déploiement : pct= n’applique la politique qu’à un pourcentage du courrier (une façon de monter en puissance sur reject à partir de 10%), et un pct inférieur à 100 signifie que la majeure partie du courrier en échec passe encore.

Le tag rua= indique où envoyer les rapports agrégés : des résumés XML quotidiens des destinataires listant chaque source qui envoie sous votre domaine, lesquelles réussissent ou échouent, et comment. Sans rua, vous appliquez une politique à l’aveugle ; avec lui, vous pouvez repérer chaque expéditeur légitime avant de durcir vers reject, pour ne pas bloquer par accident vos propres factures ou newsletters. Un enregistrement DMARC sans adresse de rapport est la raison la plus fréquente pour laquelle un déploiement reste bloqué à p=none indéfiniment.

Déployer les trois dans le bon ordre

L’ordre compte parce que chaque enregistrement dépend des précédents. Faites d’abord passer et aligner SPF et DKIM, superposez ensuite DMARC en mode surveillance, puis durcissez. Se précipiter vers p=reject avant d’avoir confirmé que chaque expéditeur légitime est aligné, c’est la façon de bloquer son propre courrier.

Un point de départ minimal et correct ressemble aux enregistrements ci-dessous : un enregistrement SPF qui autorise votre fournisseur et fait échouer le reste en souplesse, une clé DKIM publiée au sélecteur de votre fournisseur, et un enregistrement DMARC en mode surveillance avec une adresse de rapport, pour observer avant d’appliquer.

• Publiez SPF en premier : listez chaque source d’envoi et terminez par ~all, par exemple v=spf1 include:_spf.google.com ~all. Revérifiez que le nombre de requêtes reste sous dix.
• Ajoutez DKIM : activez la signature chez votre fournisseur de messagerie et publiez la clé publique au sélecteur qu’il vous donne (par exemple google._domainkey.example.com). Privilégiez une clé de 2048 bits.
• Ajoutez DMARC en mode surveillance : v=DMARC1; p=none; rua=mailto:reports@example.com. Collectez les rapports pendant quelques semaines et confirmez que tous les vrais expéditeurs passent.
• Durcissez progressivement : passez de p=none → p=quarantine → p=reject, éventuellement en montant en puissance avec pct=, seulement une fois que les rapports montrent que chaque source légitime est alignée.