Analyse et structure d’un enregistrement DMARC
Un enregistrement DMARC est une chaîne de caractères publiée sous forme d’enregistrement DNS TXT pour un domaine donné. Il permet aux administrateurs de serveurs de messagerie de définir la manière dont les destinataires doivent traiter les courriels qui échouent aux vérifications SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail).
Pour être valide, l’enregistrement doit impérativement débuter par la balise v=DMARC1. Cette valeur est sensible à la casse et doit obligatoirement occuper la première position de la chaîne. Si cette balise est absente ou mal positionnée, les systèmes de réception ignorent l’enregistrement. Le format global repose sur une série de paires nom-valeur séparées par des points-virgules.
Les politiques DMARC et leur hiérarchie (p, sp, np)
La politique de domaine constitue le cœur de la configuration DMARC. Elle détermine l’action demandée aux serveurs de réception face aux messages non alignés.
- Politique de domaine principal (
p): Si aucune balisepn’est définie, la politique du domaine applique par défaut un repli ànone. Une politiquep=nonepermet uniquement de surveiller les échecs de livraison et de recevoir des rapports, sans demander aux destinataires de rejeter ou de placer en quarantaine les messages suspects. - Politique de sous-domaine (
sp): Elle définit le comportement applicable aux sous-domaines du domaine principal. - Politique pour les sous-domaines inexistants (
np): Cette balise cible spécifiquement les sous-domaines qui n’existent pas dans le DNS.
En l’absence d’une balise spécifique, le système applique un mécanisme de repli hiérarchique: la politique pour les sous-domaines inexistants (np) se replie sur la politique de sous-domaine (sp), qui se replie à son tour sur la politique générale du domaine (p).
L’activation du mode de test via la balise t=y modifie temporairement l’application de ces politiques. Lorsqu’elle est active, elle réduit la sévérité des règles: une politique reject est abaissée à quarantine, et une politique quarantine est abaissée à none.
Alignement des identifiants et configuration des rapports
L’alignement DMARC vérifie la cohérence entre le domaine visible dans l’en-tête « From » du message et les domaines validés par SPF et DKIM. Les balises aspf et adkim configurent le niveau de flexibilité de cet alignement (strict ou détendu).
La réception de rapports d’activité est essentielle pour ajuster sa politique de sécurité. DMARC prévoit deux types de flux de rapports:
- Rapports agrégés (
rua): Ils fournissent des statistiques globales sur les volumes de messages et les statuts d’authentification. Si aucune adresseruavalide n’est configurée, aucun rapport agrégé n’est demandé. - Rapports d’échec (
ruf): Ils transmettent des détails individuels sur les messages ayant échoué aux vérifications. La balisefo(options de rapport d’échec) est ignorée si aucune adresse de rapport d’échecrufvalide n’est présente.
Les anciennes spécifications permettaient d’ajouter un suffixe de taille limite aux adresses de rapport (par exemple !size). Ce suffixe est désormais obsolète et doit être ignoré par les serveurs de réception actuels.
Évolution des normes et balises historiques
Les standards DMARC évoluent pour simplifier le traitement des messages. Certaines balises couramment utilisées sous l’ancienne norme RFC 7489 sont désormais considérées comme historiques ou obsolètes sous la norme RFC 9989.
La balise de pourcentage pct est un exemple de paramètre historique. Conçue à l’origine pour appliquer progressivement la politique DMARC à une fraction des messages, elle limite aujourd’hui la couverture de la politique uniquement pour les serveurs de réception qui suivent encore l’ancienne spécification. Les systèmes modernes appliquant les standards récents peuvent ignorer ces balises historiques. Le vérificateur identifie ces éléments obsolètes afin de vous aider à nettoyer vos enregistrements DNS.
Fonctionnement du Vérificateur d’enregistrement DMARC
Cet outil analyse la valeur textuelle d’un enregistrement DMARC afin d’en valider la syntaxe, d’identifier les erreurs de configuration et de lister les politiques actives.
Traitement des données et confidentialité
L’analyse s’exécute localement. Votre enregistrement DMARC reste dans votre navigateur. BroBroGo ne le téléverse pas et ne le sauvegarde pas. Aucune donnée n’est écrite dans le stockage du navigateur et aucune requête externe n’est émise pour analyser le texte.
Analyse des entrées et limites
L’outil accepte une chaîne de caractères représentant la valeur TXT de l’enregistrement DMARC, d’une longueur maximale de 20 000 caractères. Si l’enregistrement DNS copié contient des fragments de texte entourés de guillemets, l’outil les réunit automatiquement avant de procéder à l’évaluation.
Résultats de l’analyse
L’interface affiche les sections suivantes après validation:
- Résumé DMARC: Présente de manière synthétique la politique de domaine (
p), la politique de sous-domaine (sp), la politique pour les sous-domaines inexistants (np), l’alignement DKIM / SPF, le nombre d’adresses de rapport configurées (rua / ruf) et le pourcentage historique (pct). - Destinations des rapports: Liste les adresses de destination pour les rapports agrégés (
rua) et de panne (ruf). - Termes analysés: Un tableau récapitulatif affichant chaque balise détectée avec sa valeur, associée à un statut: RFC 9989 (actif), RFC 7489 (historique), Inconnu ou ✕ DMARC (invalide).
- Remarques sur la syntaxe et la politique: Liste les anomalies, les avertissements de sécurité ou les configurations par défaut appliquées en raison de balises manquantes.
Erreurs de syntaxe et avertissements fréquents
Le tableau suivant répertorie les messages d’erreur et les avertissements de politique que l’outil peut générer lors de l’analyse d’un enregistrement:
| Type de retour | Message d’erreur ou avertissement affiché |
|---|---|
| Saisie vide | Collez d’abord un enregistrement DMARC. |
| Taille excessive | Cet enregistrement est anormalement volumineux. Limitez-le à 20 000 caractères. |
| Version manquante | L’enregistrement doit commencer par v=DMARC1. |
| Mauvaise position | Terme ‹position›: v=DMARC1 doit être le premier terme. |
| Doublon | ×2: ‹tag› (‹position›) |
| Syntaxe incorrecte | name=value ✕ (‹position›) |
| Valeur vide | ‹tag›=∅ (‹position›) |
| Valeur invalide | ‹tag›=‹detail› ✕ (‹position›) |
| URI invalide | URI ✕: ‹tag› (‹position›) |
| Balise inconnue | Inconnu: ‹tag› (‹position›) |
| Balise historique | RFC 7489 → RFC 9989: ‹tag› (‹position›) |
| Politique absente | p → none |
| Politique d’observation | p=none |
| Mode test actif | t=y: reject → quarantine; quarantine → none |
| Rapports absents | rua=∅ |
| Option fo inutile | fo → ∅ (ruf=∅) |
| Pourcentage historique | pct=‹detail›% (RFC 7489) |
| Suffixe obsolète | !size → ∅ (RFC 9989) |
FAQ
Remarques sur la syntaxe et la politique: p / sp / np?
La balise p définit la politique du domaine principal. Si elle est absente, elle prend la valeur par défaut none. La balise sp s’applique aux sous-domaines et np aux sous-domaines inexistants. En cas d’absence de ces balises spécifiques, le traitement des sous-domaines se replie selon la logique suivante: np hérite de sp, qui hérite de p. L’utilisation de t=y indique un mode de test qui réduit la sévérité des politiques appliquées (reject devient quarantine, et quarantine devient none).
RFC 9989: pct / rf / ri?
Sous la norme actuelle RFC 9989, les balises comme pct (pourcentage), rf (format de rapport) et ri (intervalle de rapport) sont considérées comme historiques ou obsolètes. Les serveurs de réception modernes peuvent choisir de les ignorer. En revanche, les balises np (politique pour les sous-domaines inexistants), psd (domaines de partage de services) et t (mode de test) font partie des paramètres actifs de la norme.
Un résultat sans problème prouve-t-il que ma configuration DMARC fonctionne?
Non. Cette page vérifie seulement 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 courriel destinataire. Elle sert uniquement à valider la structure et la cohérence théorique de votre enregistrement avant sa publication.