Les erreurs de syntaxe DMARC les plus courantes (et leurs corrections)
Par Thomas · RSSI virtuel · 24 août 2026
Un enregistrement DMARC tient sur une seule ligne de DNS, et cette ligne concentre une densité d'erreurs remarquable. Une balise déplacée, un mailto: oublié, un point-virgule perdu : chacune de ces broutilles suffit à neutraliser la politique d'un domaine entier. Le terrain s'y prête, car le DNS ne valide rien. Un enregistrement TXT accepte n'importe quelle chaîne de caractères, et un enregistrement DMARC faux se publie exactement aussi bien qu'un enregistrement juste — sans avertissement, sans message d'erreur, sans le moindre voyant rouge.
C'est ce qui rend l'erreur d'enregistrement DMARC si perverse : elle est silencieuse. Le domaine croit avoir « fait DMARC » ; en réalité, les serveurs de réception ignorent l'enregistrement, appliquent une politique plus faible que celle affichée, ou n'envoient jamais les rapports attendus. Les symptômes n'apparaissent que des semaines plus tard — une boîte de collecte désespérément vide, une usurpation qui passe sans encombre, un audit qui découvre que le p=reject affiché n'a jamais existé aux yeux des récepteurs.
Ce guide dresse le bêtisier réel : les erreurs de syntaxe observées partout, avec la correction de chacune. Il signale aussi les fausses erreurs — la casse, les balises modernes — que de vieux validateurs pointent à tort, et se termine par la méthode pour prouver qu'une correction a bien pris. Le tout suppose de savoir à quoi ressemble un enregistrement sain : c'est le point de départ.
L'anatomie d'un enregistrement valide
Un enregistrement DMARC est un enregistrement DNS de type TXT publié à un emplacement précis : le sous-domaine _dmarc du domaine à protéger. Pour exemple.fr, les récepteurs interrogent donc _dmarc.exemple.fr, et nulle part ailleurs. La valeur est une suite de paires balise=valeur séparées par des points-virgules :
_dmarc.exemple.fr. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr"
Trois éléments portent l'essentiel. v=DMARC1 identifie la version et doit ouvrir l'enregistrement, sans exception. p= exprime la politique demandée aux récepteurs : none, quarantine ou reject, rien d'autre. rua= désigne la destination des rapports agrégés, sous forme d'URI mailto:. Autour, des balises optionnelles affinent le comportement : sp pour les sous-domaines, adkim et aspf pour la rigueur d'alignement, fo pour les options de rapport d'échec, et les balises introduites par DMARCbis (np, t, psd), sur lesquelles on reviendra. Des enregistrements complets et commentés, du plus simple au plus avancé, sont rassemblés dans les modèles annotés ; ici, l'attention se porte sur ce qui casse.
v déplacé, p absent : les erreurs qui neutralisent la politique
La règle la plus stricte de toute la syntaxe concerne la balise de version : v=DMARC1 doit être la première paire de l'enregistrement. Un p=reject; v=DMARC1 — fruit d'un réagencement malheureux lors d'une modification — n'est pas un enregistrement « mal rangé » : c'est un enregistrement que les récepteurs écartent entièrement. Le domaine se retrouve sans politique du tout, avec un enregistrement pourtant bien visible dans le DNS. La correction est triviale (remettre v=DMARC1 en tête) ; le diagnostic l'est moins, précisément parce que tout semble en place.
La balise p réserve un piège plus subtil. Absente, ou mal orthographiée — p=rejet, p=quarantaine, p=block se rencontrent réellement sur des domaines en production —, elle ne rend pas toujours l'enregistrement invisible. Le standard prévoit un repli : si la politique est illisible mais qu'une adresse rua exploitable est présente, les récepteurs traitent l'enregistrement comme un p=none. Les rapports continuent d'arriver, le tableau de bord vit, tout paraît normal… sauf que la politique réellement appliquée est la plus permissive qui soit. Un domaine peut afficher un p=reject mal orthographié pendant des mois en se croyant protégé. La correction tient en un mot juste : les seules valeurs admises sont none, quarantine et reject, en anglais, sans variante.
rua= sans mailto: : des rapports qui ne partent jamais
L'adresse de collecte des rapports agrégés n'est pas une adresse e-mail nue : c'est une URI. rua=dmarc@exemple.fr semble limpide, mais aucun générateur de rapports ne l'acceptera — la forme correcte est rua=mailto:dmarc@exemple.fr. L'oubli du préfixe mailto: est probablement l'erreur la plus répandue de tout ce bêtisier, et son symptôme est sans appel : un enregistrement par ailleurs correct, une politique appliquée, et zéro rapport reçu, indéfiniment.
La règle vaut pour chaque destination. Plusieurs adresses se séparent par des virgules, et chacune porte son propre préfixe : rua=mailto:dmarc@exemple.fr,mailto:archive@exemple.fr est correct ; rua=mailto:dmarc@exemple.fr,archive@exemple.fr ne l'est qu'à moitié, la seconde adresse étant ignorée. La même exigence s'applique à ruf, l'adresse des rapports d'échec, quand elle est utilisée.
Points-virgules, guillemets et caractères invisibles
Le point-virgule est le séparateur de balises, et son absence fusionne deux balises en une seule valeur illisible. v=DMARC1; p=none rua=mailto:dmarc@exemple.fr fait de « none rua=mailto:… » la valeur de p : politique invalide, repli silencieux vers p=none dans le meilleur des cas. À l'inverse, les points-virgules surnuméraires (;;, ; ;) sont tolérés par certains analyseurs syntaxiques et rejetés par d'autres : autant s'en tenir à la forme canonique — un point-virgule entre chaque paire, un éventuel point-virgule final sans conséquence.
Les guillemets sont un piège d'interface. Dans un fichier de zone, la valeur TXT s'écrit entre guillemets ; dans l'interface web d'un hébergeur DNS, ils sont presque toujours superflus, l'interface les ajoutant elle-même. Coller "v=DMARC1; p=none" guillemets compris dans un champ qui n'en attend pas produit un enregistrement dont le premier caractère est un guillemet littéral : la balise v n'ouvre plus la valeur, l'enregistrement entier est écarté. Le symptôme se repère à l'interrogation DNS : des guillemets doublés ou échappés autour de la valeur publiée.
Les caractères invisibles, enfin, sont l'ennemi du copier-coller. Un enregistrement rédigé dans un traitement de texte ou récupéré dans un PDF embarque volontiers une espace insécable à la place d'une espace simple, des guillemets typographiques, un tiret long à la place du trait d'union. À l'œil, rien ne distingue ces caractères de leurs équivalents ASCII ; pour l'analyseur syntaxique d'un récepteur, la balise n'existe plus. La parade est simple : ressaisir la valeur dans un éditeur de texte brut plutôt que la coller depuis un document mis en forme.
Le mauvais emplacement et le double enregistrement
Un enregistrement parfait au mauvais endroit ne vaut rien. Posé sur le domaine nu — exemple.fr au lieu de _dmarc.exemple.fr —, il ne sera jamais consulté : les récepteurs n'interrogent que le sous-domaine _dmarc. L'erreur inverse existe aussi : certaines interfaces DNS ajoutent automatiquement le nom de zone, et saisir _dmarc.exemple.fr dans le champ « nom » produit _dmarc.exemple.fr.exemple.fr. Selon l'hébergeur, le champ attend _dmarc seul ou le nom complet ; une vérification de l'état réellement publié tranche en quelques secondes.
Le double enregistrement est plus sournois. Quand deux TXT commençant par v=DMARC1 coexistent sur _dmarc.exemple.fr — un ancien jamais supprimé, un nouveau posé par un autre outil ou une autre équipe —, le standard est sans ambiguïté : les récepteurs n'en choisissent aucun. Deux politiques valent zéro politique, et le domaine régresse à l'état non protégé. Le même piège existe côté SPF, où la duplication produit une erreur permanente ; le mécanisme et sa correction sont détaillés dans le cas des enregistrements SPF multiples.
Cas particulier : quand _dmarc est délégué par CNAME vers un enregistrement géré ailleurs — pratique courante avec les plateformes de supervision —, poser un TXT local à côté est impossible ou conflictuel, et les modifications locales restent sans effet. Le fonctionnement et les limites de cette délégation sont expliqués dans la délégation par alias DNS.
Les fausses erreurs : la casse et les balises DMARCbis
Tout ce qui choque l'œil n'est pas une erreur. La casse, d'abord : la comparaison des balises et de leurs valeurs est insensible aux majuscules. p=REJECT vaut exactement p=reject, et P=Quarantine s'interprète sans difficulté. C'est une erreur de diagnostic très courante : face à un problème de délivrabilité, l'attention se fixe sur des capitales « suspectes », la « correction » ne change rigoureusement rien — et la vraie erreur, un mailto: manquant trois balises plus loin, survit à la relecture. La forme en minuscules (avec DMARC1 en capitales) reste recommandée pour la lisibilité, mais elle relève de la convention, pas de la validité.
Les balises modernes, ensuite. Le standard courant — DMARCbis, publié sous les RFC 9989 à 9991 — a introduit np (politique des sous-domaines inexistants), t (mode test, qui remplace l'ancien pct) et psd (marqueur lié au DNS Tree Walk, successeur de la Public Suffix List). Un enregistrement contenant np=reject ou t=y est parfaitement valide ; pourtant, de vieux validateurs en ligne, jamais mis à jour, le signalent en « balise inconnue ». C'est un faux positif : la syntaxe DMARC est extensible par conception, et une balise inconnue est ignorée, jamais fatale. À l'inverse, un pct=50 hérité d'un ancien déploiement n'invalide rien, mais il n'est plus interprété par les récepteurs modernes : le mode test s'exprime désormais avec t=y.
Le reporting externe : quand rua pointe vers un autre domaine
Dernier cas, à la frontière de la syntaxe : l'enregistrement est irréprochable, la politique s'applique, et les rapports n'arrivent toujours pas. Quand l'adresse rua appartient à un autre domaine que celui qui publie l'enregistrement — exemple.fr qui envoie ses rapports vers dmarc@exemple.org —, les générateurs de rapports exigent une preuve de consentement du destinataire. Le domaine qui reçoit doit publier un enregistrement d'autorisation à l'emplacement exemple.fr._report._dmarc.exemple.org, avec la simple valeur v=DMARC1. Sans cette autorisation, la plupart des générateurs s'abstiennent d'envoyer — silencieusement, comme toujours.
Les plateformes de collecte sérieuses publient cette autorisation d'office, souvent sous forme générique valable pour tous leurs clients ; le problème ne se rencontre donc guère qu'avec une collecte artisanale entre domaines d'une même organisation. La mise en place complète d'une adresse de collecte — autorisation comprise — est déroulée pas à pas dans la configuration de l'adresse rua.
La méthode : corriger, puis prouver la correction
Toute correction commence par une lecture de l'état réel, pas de l'état supposé. La commande dig TXT _dmarc.exemple.fr +short (ou son équivalent nslookup -type=TXT) montre ce que les récepteurs voient effectivement — ce qui peut différer de ce que l'interface de l'hébergeur affiche, à cause d'un cache, d'une zone secondaire désynchronisée ou d'une délégation oubliée.
Sur cette sortie, la relecture suit une liste courte : un seul enregistrement commençant par v=DMARC1 ; v en toute première position ; un p présent, avec l'une des trois valeurs admises ; un mailto: devant chaque adresse de rua et de ruf ; un point-virgule entre chaque paire ; aucun guillemet littéral en tête de valeur ; aucun caractère exotique — le doute se lève en ressaisissant la valeur à la main dans un éditeur brut.
La correction publiée, la patience s'impose : le TTL de l'ancien enregistrement peut maintenir la version fautive en cache plusieurs heures. Une nouvelle interrogation depuis plusieurs résolveurs confirme la propagation. La preuve finale n'est pas syntaxique mais opérationnelle : des rapports agrégés qui arrivent sous 24 à 48 heures attestent que la chaîne complète — emplacement, syntaxe, politique, collecte — fonctionne de bout en bout.
En résumé
Un enregistrement DMARC valide est un TXT unique posé sur _dmarc.<domaine>, ouvert par v=DMARC1, porteur d'un p correctement orthographié et d'un rua en URI mailto:. Les erreurs qui comptent tiennent sur les doigts de deux mains : balise de version déplacée, politique absente ou fautive qui se replie silencieusement sur p=none, mailto: oublié, point-virgule perdu, guillemets collés dans la valeur, enregistrement posé au mauvais endroit, doublon qui annule tout, caractère invisible venu d'un copier-coller. En face, deux fausses erreurs à ne plus « corriger » : la casse, ignorée par les récepteurs, et les balises DMARCbis (np, t, psd) que seuls des validateurs vieillissants prennent pour des fautes. Et un angle mort : l'autorisation de reporting externe, sans laquelle des rapports parfaitement configurés ne partent jamais.
Le plus court chemin du doute à la certitude reste l'outillage : un passage du domaine par l'analyse DMARC gratuite détecte en quelques secondes les erreurs de ce bêtisier — balise déplacée, mailto: manquant, double enregistrement — sans en inventer de fausses sur la casse ou les balises modernes. Une fois l'enregistrement assaini, l'ouverture d'un compte permet de suivre le retour des rapports et de faire monter la politique vers p=reject sur des fondations enfin saines.
Guides liés
- DMARC échoue alors que SPF passe : comprendre l'alignement
Un rapport DMARC peut afficher spf=pass et dmarc=fail pour le même message. L'explication tient en un mot, l'alignement, et change la lecture des rapports.
- Comment lire les en-têtes d'un e-mail
Anatomie des en-têtes d'un message : Authentication-Results, DKIM-Signature, Received, ARC. Où les trouver, comment les lire, ce qu'ils prouvent.
- Quand la redirection d'email casse SPF (et ce que SRS répare)
Un email redirigé repart d'une IP absente du SPF d'origine : échec garanti. Ce que SRS répare, ce que DKIM sauve, et l'effet réel sur DMARC.
À propos de l'auteur
Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.