Vérificateur d’enregistrement DMARC

Comprendre la structure d’un enregistrement DMARC

Un enregistrement DMARC (Domain-based Message Authentication, Reporting, and Conformance) est une chaîne de caractères publiée sous forme d’enregistrement DNS TXT pour un domaine donné. Cet enregistrement indique aux serveurs de messagerie destinataires comment traiter les courriels qui échouent aux vérifications SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail).

Pour être valide, un enregistrement DMARC doit impérativement commencer par la balise de version v=DMARC1. Cette valeur est sensible à la casse et doit obligatoirement se situer en toute première position de la chaîne. Si cette balise est absente, mal positionnée ou écrite différemment, les serveurs de messagerie ignoreront l’enregistrement. Le format général se compose de paires clé-valeur séparées par des points-virgules.

Les politiques DMARC et leur hiérarchie: p, sp et np

Le cœur d’un enregistrement DMARC réside dans la définition de ses politiques de traitement des messages non alignés. Ces politiques s’articulent autour de trois balises principales:

• La politique du domaine principal (p): Elle détermine l’action à appliquer pour le domaine principal. Si aucune balise p n’est présente dans l’enregistrement, la politique du domaine bascule par défaut sur none. Une politique p=none permet uniquement de surveiller les échecs de livraison sans demander aux destinataires de mettre en quarantaine ou de rejeter les messages non conformes.
• La politique des sous-domaines (sp): Elle définit le comportement à adopter pour les sous-domaines du domaine principal.
• La politique des sous-domaines non existants (np): Elle cible spécifiquement le traitement des messages provenant de sous-domaines qui n’existent pas réellement dans le DNS.

En l’absence de balises spécifiques pour les sous-domaines, un mécanisme de repli automatique s’applique. Les politiques des sous-domaines héritent des valeurs supérieures selon la hiérarchie suivante: la configuration bascule de np vers sp, puis de sp vers p lorsqu’une balise plus spécifique fait défaut.

De plus, l’utilisation de la balise de test t=y modifie temporairement la sévérité des politiques appliquées par les destinataires. Durant cette phase de test, la politique quarantine est abaissée à none, et la politique reject est abaissée à quarantine.

Alignement des identifiants et configuration des rapports

DMARC s’appuie sur l’alignement des identifiants SPF et DKIM pour valider l’authenticité d’un expéditeur. L’alignement vérifie que le domaine visible dans l’en-tête "From" correspond aux domaines validés par SPF et DKIM.

Le système permet également de configurer des retours d’information via deux types de rapports:

• Les rapports agrégés (rua): Ils fournissent des données statistiques globales sur les volumes de messages et les statuts d’authentification. Si aucune adresse rua valide n’est spécifiée, les rapports agrégés ne sont pas demandés.
• Les rapports d’échec (ruf): Ils fournissent des détails techniques sur les messages spécifiques qui ont échoué aux tests d’authentification.

La balise fo (options de rapport d’échec) est directement liée à la présence de destinataires pour ces rapports. Ainsi, la balise fo est ignorée si aucune adresse de rapport d’échec ruf valide n’est configurée dans l’enregistrement. Par ailleurs, le suffixe historique !size qui permettait de limiter la taille des rapports sur une URI est désormais obsolète et doit être ignoré par les serveurs de messagerie actuels.

Balises historiques et évolutions des standards

Les spécifications DMARC ont évolué, entraînant le passage de certaines balises au statut historique. C’est le cas de la balise de pourcentage pct. Conçue initialement pour appliquer progressivement une politique DMARC à une fraction seulement des messages, la valeur pct est aujourd’hui considérée comme historique. Elle ne limite la couverture de la politique que pour les serveurs de messagerie destinataires qui suivent encore les anciennes spécifications DMARC.

Les systèmes de réception modernes qui appliquent les standards actuels peuvent ignorer ces balises historiques ainsi que d’autres paramètres obsolètes pour se concentrer uniquement sur les règles actives.

Analyse des erreurs de syntaxe courantes

La configuration manuelle d’un enregistrement DNS TXT expose fréquemment les administrateurs à des erreurs de syntaxe qui neutralisent la protection DMARC. Les anomalies les plus courantes incluent:

• Un mauvais positionnement de la version: Placer une autre balise avant v=DMARC1.
• Des doublons: Déclarer plusieurs fois la même balise au sein d’un unique enregistrement.
• Un formatage incorrect: Omettre les points-virgules de séparation ou ne pas respecter la structure clé=valeur.
• Des valeurs vides ou invalides: Déclarer une balise sans lui associer de valeur, ou y insérer des caractères non pris en charge.
• Des URI de rapport mal formées: Saisir des adresses de destination pour rua ou ruf qui ne respectent pas la syntaxe requise.

Fonctionnement du vérificateur d’enregistrement DMARC

Cet outil analyse la valeur d’un enregistrement TXT DMARC que vous fournissez afin d’en vérifier la structure, les politiques, les paramètres d’alignement, les adresses de rapport et les éventuelles valeurs de pourcentage héritées. Il accepte les chaînes de caractères d’une longueur inférieure à 20 000 caractères. Si votre enregistrement DNS est segmenté, les fragments TXT entourés de guillemets sont automatiquement détectés et réunis avant de lancer l’analyse.

Le traitement de vos données s’effectue localement dans votre navigateur web. L’outil ne téléverse pas votre enregistrement DMARC et ne l’enregistre sur aucun serveur externe. Aucune requête réseau n’est émise pour analyser la chaîne saisie.

L’interface affiche les résultats sous plusieurs sections:

• Analyse DMARC: Le panneau principal présentant les conclusions de l’évaluation.
• Résumé DMARC: Un aperçu des paramètres clés, notamment la politique de domaine (p), la politique de sous-domaine (sp), la politique pour les sous-domaines non existants (np), l’alignement des identifiants, le nombre d’adresses de rapport configurées et la valeur de pourcentage héritée (pct).
• Destinations des rapports: Le détail des adresses configurées pour recevoir les rapports agrégés (rua) et les rapports d’échec (ruf).
• Termes analysés: Un tableau récapitulatif listant chaque terme trouvé, sa valeur ou son qualificatif, ainsi que son type (qui peut être RFC 9989, RFC 7489, Inconnu ou ✕ DMARC).
• Remarques sur la syntaxe et la politique: La liste des anomalies, des avertissements de sécurité ou des recommandations structurelles identifiés lors de l’analyse.

FAQ

Remarques sur la syntaxe et la politique: p / sp / np? La balise p définit la politique du domaine principal. En son absence, elle prend la valeur par défaut none. La balise sp s’applique aux sous-domaines et np aux sous-domaines non existants. Si np n’est pas configurée, elle hérite de la valeur de sp, qui elle-même hérite de p en cas d’absence. La balise de test t=y réduit temporairement la sévérité des politiques: reject devient quarantine, et quarantine devient none.

RFC 9989: pct / rf / ri? Selon les normes récentes, les balises comme pct sont désormais classées comme historiques (RFC 7489). Les balises actives selon la RFC 9989 incluent notamment np, psd et t. Les serveurs de messagerie modernes peuvent ignorer les paramètres historiques lors du traitement des courriels.

Un résultat sans problème prouve-t-il que ma configuration DMARC fonctionne? Non. Cette page vérifie uniquement le texte que vous collez. Elle n’interroge pas DNS, ne développe pas les enregistrements des fournisseurs, ne teste pas l’IP d’un expéditeur et ne confirme pas la réponse d’un serveur de messagerie destinataire. Elle valide uniquement la syntaxe et la cohérence théorique de la chaîne de caractères fournie.