Compte gratuit

Gardez vos requêtes sous contrôle

Créez un compte en moins de 30 secondes pour conserver 6 mois d'historique, partager vos requêtes et déclencher des alertes email ou webhook sur chaque diff.

  • Historique consultable 6 mois
  • Alertes diff email & webhook
  • Surveillance des pics de latence
S'inscrire

Vérificateur de syntaxe DMARC

Comprendre la syntaxe d'un enregistrement DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) combine les résultats SPF et DKIM pour définir une politique de traitement côté destinataire. L'enregistrement TXT placé sur _dmarc.<domaine> publie cette politique. Cette page détaille les balises interprétées par le validateur et explique comment lire les diagnostics renvoyés par l'API.

Exemple d'enregistrement DMARC

Un enregistrement DMARC est une liste de balises séparées par des points-virgules. Chaque balise comporte un nom court, un signe égal et une valeur. Les espaces superflus sont tolérés, mais les noms de balise doivent rester en ASCII et uniques.

v=DMARC1; p=quarantine; rua=mailto:reports@example.com; ruf=mailto:forensics@example.com; adkim=s; aspf=s; pct=100

Balises obligatoires à publier

  • v — la version. DMARC1 est la seule valeur reconnue à ce jour.
  • p — la politique appliquée aux messages non alignés (none, quarantine ou reject).

Sans ces balises, le validateur considère l'enregistrement comme invalide et les serveurs destinataires l'ignoreront.

Balises optionnelles utiles

  • rua — destinations (URI mailto:) des rapports agrégés. Fortement recommandée pour suivre l'effet de la politique.
  • ruf — destinataires des rapports médico-légaux. À réserver à des boîtes surveillées et protégées.
  • sp — politique appliquée aux sous-domaines si différente de p.
  • adkim / aspf — modes d'alignement DKIM et SPF (r pour relaxed, s pour strict).
  • pct — pourcentage de messages sur lesquels la politique s'applique (100 par défaut).
  • fo — options de remontée des échecs (par exemple 1, d, s).
  • ri — intervalle souhaité entre rapports agrégés en secondes (86400 par défaut).
  • rf — formats de rapport attendus (afrf, iodef).

Le validateur affiche ces balises lorsqu'elles sont présentes pour visualiser exactement ce que renverra le DNS.

Pièges de syntaxe détectés par l'outil

  1. Balises inconnues ou dupliquées. Chaque nom doit être unique ; les doublons sont signalés.
  2. URI de rapport invalides. Les valeurs rua et ruf doivent être des URI valides (mailto: ou https:).
  3. Politique absente ou vide. Sans p, la politique ne s'applique pas.
  4. Pourcentage hors bornes. pct doit être compris entre 1 et 100.
  5. Alignement ou options invalides. Les valeurs autres que r/s pour adkim ou aspf, ou hors spécifications pour fo, déclenchent des erreurs.

Ce que contrôle le validateur

  • Enveloppe de l'enregistrement — chaînes vides, guillemets résiduels ou enregistrements sans v=DMARC1/p= sont marqués invalides (empty_record, record_trailing_quote, not_dmarc_record).
  • Syntaxe des balises — balises dupliquées ou inconnues, séparateurs incorrects et noms vides génèrent invalid_tag_syntax, empty_tag_name ou duplicate_tag.
  • Politique et alignement — balises de politique manquantes ou vides, valeurs non supportées pour p, sp, adkim ou aspf et pourcentage en dehors de 1–100 sont signalés explicitement.
  • Destinations de rapport — URIs rua/ruf mal formés, intervalles ou formats de rapport incohérents lèvent des diagnostics dédiés pour corriger les adresses mailto/HTTPS avant la production.
  • Résolution DNS — absence de TXT, absence de DMARC ou multiples politiques conflictuelles apparaissent comme lookup_no_txt, lookup_no_dmarc ou lookup_multiple_dmarc afin de distinguer publication et erreurs de syntaxe.

Bonnes pratiques avant mise en production

  • Commencez par p=none avec une balise rua valide pour observer les flux sans perturber la délivrabilité.
  • Analysez les rapports et augmentez progressivement vers p=quarantine puis p=reject lorsque SPF et DKIM sont alignés.
  • Utilisez sp uniquement si les sous-domaines doivent suivre une politique différente.
  • Documentez les adresses rua/ruf, leur capacité de stockage et la personne en charge de leur traitement.
  • Testez la valeur finale avec ce vérificateur, puis résolvez _dmarc.<domaine> pour confirmer la publication et la propagation.

Une vérification systématique réduit les erreurs de syntaxe, sécurise le déploiement de la politique DMARC et fournit des diagnostics précis aux équipes délivrabilité.