L’enregistrement DMARC est une seule entrée TXT dans le DNS, mais il contrôle plus de la réputation de votre domaine que presque toute autre ligne de configuration. Mal réglé — mauvaise politique, adresse de rapport manquante, sous-domaines ignorés, pourcentage resté à zéro — et la défaillance est silencieuse. Le courriel continue de couler, mais les destinataires cessent de vous faire confiance, et vous le découvrez un trimestre plus tard quand le taux de rebond grimpe. Le DMARC Lookup & Parser de PortJar tire l’enregistrement, analyse chaque étiquette, et signale les mauvaises configurations que la spécification ne vous force pas réellement à corriger.
Ce que fait l’outil
Il interroge _dmarc.<votre-domaine> par DNS, extrait l’enregistrement TXT, et décompose chaque étiquette (v, p, sp, pct, rua, ruf, adkim, aspf, fo, ri) en explication lisible. Il signale ensuite les configurations faibles : une politique p=none au-delà de la fenêtre d’observation prévue, une adresse rua (rapports agrégés) manquante, une valeur pct sous 100 traînant plus longtemps que voulu, un sp incohérent avec la politique parente. Il confirme aussi que l’enregistrement est syntaxiquement valide — DMARC est tatillon, et un enregistrement avec un point-virgule en trop ou une étiquette mal formée est traité par les destinataires comme aucun enregistrement.
Comment l’utiliser
Ouvrez portjar.com/tools/dmarc-lookup, entrez le domaine (pas le sous-domaine _dmarc — l’outil le préfixe), et soumettez. La sortie est l’enregistrement TXT brut plus un tableau analysé. Lancez-le sur le domaine public, mais aussi sur tout sous-domaine utilisé pour du courriel sortant — facturation, soutien, transactionnel — parce que chacun peut avoir son propre enregistrement DMARC qui prime sur le parent.
Quand l’utiliser
- Avant d’ajouter un nouvel expéditeur. Quand le marketing veut ajouter Mailchimp, le transactionnel ajouter Postmark, ou les ventes ajouter un CRM qui envoie « au nom » de votre domaine, l’état courant de DMARC détermine quelle paperasse d’authentification ils doivent compléter d’abord. Le guide de dépannage PortJar sur SPF PermError couvre la limite connexe des 10 requêtes DNS qui ressurgit souvent à ce moment-là.
- Après un déménagement de fournisseur DNS. Les enregistrements TXT sont reconnus pour ne pas migrer proprement — les guillemets se font malmener, les enregistrements longs sont tronqués, les séparateurs
;sautent. Un parse DMARC contre le nouveau DNS confirme que l’enregistrement a fait le voyage intact. - Quand la livrabilité chute sans explication. Un destinataire qui acceptait votre courriel commence à le mettre en pourriel. Première vérification : votre politique DMARC est-elle en mode strict (
p=quarantineoup=reject), votre envoi aligné est-il vraiment aligné, et avez-vous une adresseruaqui collecte les rapports agrégés nécessaires pour pousser le diagnostic ? PortJar pointe un guide de référence sur ce quep=quarantineveut réellement dire pour les expéditeurs pendant ce déploiement. - Mener un client de
p=noneau mode strict. Le guide PortJar sur les échecs DKIM se marie naturellement avec ceci — dès que DMARC passe en mode strict, chaque signature DKIM mal alignée devient un problème de livraison plutôt qu’un défaut cosmétique. - Auditer un domaine à la prise en charge. Un parse DMARC est le premier contrôle DNS sur tout client qu’on intègre avec cPanel ou un environnement de courriel hébergé. Il nous dit en quinze secondes si l’opérateur précédent a fait le travail ou s’il l’a esquivé.
Quoi faire du résultat
Une politique p=none n’est pas une protection — c’est de l’observation. C’est une étape valide vers le mode strict, mais un domaine resté à p=none depuis un an est un domaine dont le propriétaire avait l’intention de déployer DMARC et ne l’a jamais terminé. Une adresse rua manquante signifie que vous volez à l’aveugle ; même à p=none, les rapports agrégés sont la façon de trouver chaque expéditeur mal aligné. Un pct inférieur à 100 devrait être un état temporaire, pas permanent. Une étiquette sp qui diffère de p veut dire que les sous-domaines suivent une règle différente (souvent plus faible) que le parent — ce qui peut être voulu mais relève plus souvent d’un oubli. Quand l’analyseur signale rua=mailto: pointant vers une adresse que vous ne reconnaissez pas, traitez ça comme une observation — quelque part en route, quelqu’un a pointé vos rapports DMARC vers un traitant tiers et cette relation n’est peut-être plus active.
Pour les environnements où l’authentification du courriel et la posture DMARC doivent rester justes sur des dizaines de domaines, Stack Harbor gère cela dans le cadre de la gestion cPanel/WHM.