Pourquoi valider la syntaxe DMARC avant publication ?
Un enregistrement DMARC mal formaté est silencieusement ignoré par Gmail, Outlook, Yahoo et tous les serveurs destinataires. Aucune alerte n'est remontée. Vos emails restent sans protection contre l'usurpation d'identité et le phishing.
Le validateur lit votre enregistrement avant publication DNS, contrôle chaque balise et vérifie les URIs de rapport. Vous corrigez les erreurs immédiatement, sans attendre 24 à 48 heures de propagation pour découvrir qu'un détail empêche la politique d'être appliquée.
Balises DMARC selon la RFC 7489
La RFC 7489 définit chaque balise autorisée dans un enregistrement DMARC. Le validateur vérifie le nom, l'ordre et la valeur de chaque balise.
| Balise | Rôle | Exemple |
|---|---|---|
| v | Version du protocole, toujours en première position | v=DMARC1 |
| p | Politique appliquée au domaine racine | p=quarantine |
| sp | Politique propre aux sous-domaines | sp=reject |
| adkim | Mode d'alignement DKIM, r (relâché) ou s (strict) | adkim=s |
| aspf | Mode d'alignement SPF, r ou s | aspf=r |
| pct | Pourcentage de messages soumis à la politique, 1 à 100 | pct=50 |
| rua | Destinations des rapports agrégés (URI mailto) | rua=mailto:dmarc@captaindns.com |
| ruf | Destinations des rapports forensiques (URI mailto) | ruf=mailto:forensic@captaindns.com |
| fo | Conditions de génération des rapports forensiques | fo=1 |
Les balises v et p sont obligatoires. Les autres balises héritent de valeurs par défaut si omises (adkim=r, aspf=r, pct=100).
Exemples de correction avant et après
Le validateur signale chaque erreur de syntaxe avec sa position. Voici trois cas fréquents repérés sur les enregistrements publiés.
URI rua mal formé :
- v=DMARC1; p=reject; rua=reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com
Le préfixe mailto: est obligatoire selon la RFC 7489.
Politique p invalide :
- v=DMARC1; p=monitor; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com
Seules les valeurs none, quarantine et reject sont acceptées.
Pourcentage pct hors bornes :
- v=DMARC1; p=quarantine; pct=150; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@captaindns.com
La valeur pct doit être un entier entre 1 et 100.
Diagnostics courants du validateur
Le validateur retourne un code court par anomalie détectée. Les codes ci-dessous sont les plus fréquents.
| Code | Cause | Action |
|---|---|---|
| missing_version_tag | Balise v=DMARC1 absente | Ajouter v=DMARC1 en première position |
| unsupported_version | Valeur v= autre que DMARC1 | Remplacer par v=DMARC1 |
| missing_policy | Balise p= absente | Ajouter p=none, p=quarantine ou p=reject |
| invalid_policy | Valeur p= hors none/quarantine/reject | Corriger la valeur |
| invalid_subdomain_policy | Valeur sp= invalide | Utiliser none, quarantine ou reject |
| invalid_alignment | Valeur adkim= ou aspf= autre que r/s | Corriger en r ou s |
| invalid_percent | pct= hors plage 1-100 | Définir une valeur entière entre 1 et 100 |
| invalid_rua_uri | URI rua mal formé | Utiliser mailto:adresse@domaine |
| invalid_ruf_uri | URI ruf mal formé | Utiliser mailto:adresse@domaine |
| invalid_failure_option | Valeur fo= non reconnue | Utiliser 0, 1, d ou s |
| duplicate_tag | Balise déclarée deux fois | Conserver une seule occurrence |
| unknown_tag | Nom de balise non reconnu | Vérifier l'orthographe selon RFC 7489 |
| record_trailing_quote | Chaîne TXT terminée par un guillemet | Retirer le guillemet final |
Les codes en avertissement (policy_none, pct_less_than_100, subdomain_policy_none) signalent une configuration valide mais à surveiller : la protection reste partielle tant que la politique reste sur none ou que pct est inférieur à 100.
FAQ - Questions fréquentes
Quelle progression adopter pour la politique p= ?
Commencez toujours par p=none pour observer le trafic via les rapports agrégés (rua). Une fois SPF et DKIM alignés sur toutes vos sources légitimes, passez à p=quarantine, puis à p=reject. Évitez de sauter directement à p=reject : les rapports rua de la phase d'observation révèlent presque toujours des flux légitimes oubliés.
Faut-il configurer ruf en plus de rua ?
Non, pas au début. Les rapports rua (agrégés, quotidiens) sont essentiels pour piloter votre déploiement. Les rapports ruf (forensiques, par message en échec) génèrent un volume important et peuvent contenir des données personnelles. Activez-les uniquement si vous disposez d'un pipeline d'analyse et d'un avis juridique sur la collecte de ces données.
Faut-il configurer la balise sp= sur les sous-domaines ?
Par défaut, les sous-domaines héritent de la politique p. Configurez sp= uniquement si la politique des sous-domaines doit différer du domaine racine. Vérifiez que SPF et DKIM sont alignés sur chaque sous-domaine émetteur avant de durcir sp=.
Le validateur applique-t-il les règles DMARCbis ?
Cette version applique les règles de la RFC 7489. Pour anticiper la transition vers DMARCbis (suppression de pct, ri, rf, ajout de np, psd, t), utilisez le DMARCbis Checker ou l'outil de migration DMARCbis.
Outils complémentaires
| Outil | Utilité |
|---|---|
| DMARC Checker | Vérifier la publication et résoudre l'enregistrement DMARC depuis le DNS |
| Générateur DMARC | Créer un enregistrement DMARC conforme |
| Validateur SPF | Valider la syntaxe SPF associée à votre domaine |
| Validateur DKIM | Valider la syntaxe d'une clé DKIM |
| DMARCbis Migration | Migrer un enregistrement DMARC vers le nouveau standard |