Analyseur DMARC

Vous préparez un passage de la surveillance à l’application et devez savoir si l’enregistrement publié résistera à l’évaluation des récepteurs. Le marketing envoie via un CRM, le produit via un prestataire transactionnel et la finance via un relais local. Avant de monter `p` de `none` à `quarantine`, DN01 indique si le TXT sur `_dmarc.example.com` est syntaxiquement valide, si des tags dupliqués invalident l’enregistrement et si `pct` limite déjà l’application. Cette unique publication DNS est ce que des milliards de boîtes mail évaluent ; une faute dans `p=` ou un second TXT DMARC peut affaiblir la protection sur tous les canaux.

Les tickets de délivrabilité incriminent souvent DMARC alors que SPF passe seul. Un message peut avoir un SPF valide et échouer DMARC quand envelope From, header From et domaine signataire DKIM ne s’alignent pas selon `aspf` et `adkim`. DN01 affiche les modes d’alignement : sans tags, il suppose le mode relâché (`r`) et avertit que les récepteurs peuvent accepter des correspondances de domaine plus larges que prévu. Croisez le résultat avec DKIM Validator et DNS Checker.

Les équipes sécurité utilisent DMARC comme contrôle anti-usurpation pour domaines dirigeants, portails partenaires et marques similaires. Si `_dmarc` est absent, DN01 renvoie un diagnostic clair — `no DMARC record found at _dmarc.<domain>` — et recommande de publier `v=DMARC1` avec une politique initiale. Ce n’est pas une panne outil ; c’est l’état que voient les récepteurs quand le phishing peut réutiliser votre domaine sans politique de rejet publiée.

Les MSP passent en revue DMARC sur des dizaines de zones clients lors d’onboarding ou renouvellements. Les `dig` manuels ne passent pas à l’échelle quand il faut comparer `sp` et `p`, vérifier les boîtes de rapports et repérer un `pct` invalide. DN01 renvoie un rapport cohérent avec durée, inventaire de tags et recommandations pour les tickets. La page SEO de résultat par domaine offre aux parties prenantes un lien stable sur la publication actuelle.

Les architectures à sous-domaines multiples — `news.example.com`, `billing.example.com`, `eu.example.com` — dépendent de `sp=` quand les zones filles envoient avec leur propre SPF et DKIM. Sans `sp`, les récepteurs appliquent `p` aux sous-domaines, ce qui surprend les équipes qui croyaient la zone isolée. DN01 montre les deux valeurs et signale les politiques sous-domaine invalides comme les politiques organisationnelles.

Les questionnaires conformité demandent des preuves de maturité en authentification mail, pas seulement des cases cochées. Les auditeurs veulent savoir si le reporting agrégé (`rua`) est configuré, si l’application est partielle (`pct` inférieur à 100) et si l’enregistrement est valide aujourd’hui. DN01 répond depuis le DNS live, conserve le TXT brut et sépare erreurs dures et avertissements.

Après une vague d’usurpation, la réponse à incident commence souvent par « DMARC manquant ou cassé ? ». Quand plusieurs TXT sur `_dmarc` contiennent plus d’un fragment `v=DMARC1`, les récepteurs peuvent traiter la configuration comme invalide. DN01 choisit le premier enregistrement correspondant mais signale les tags dupliqués dans une même chaîne. Revérifiez après le TTL et validez les signatures via DKIM Validator avant de revenir à `reject`.

Si DN01 signale l’absence de DMARC, interrogez `_dmarc.votredomaine.tld` spécifiquement, pas le TXT racine où vit SPF. Beaucoup d’équipes publient SPF à l’apex et supposent que DMARC s’y trouve aussi. Confirmez l’enregistrement sur tous les NS autoritaires après migration DNS ; des délégations obsolètes font qu’un résolveur voit `v=DMARC1` et un autre NXDOMAIN.

Quand `valid` est faux avec `found` true, lisez d’abord le tableau d’erreurs. Tags `p=` dupliqués, politiques inconnues, `pct` non entier ou hors 0–100 invalident l’enregistrement. Supprimez les doublons dans le panneau DNS, gardez un seul TXT point-virgule et évitez de scinder DMARC en plusieurs TXT sans concaténation correcte.

Les avertissements sur `p=none`, `rua` absent ou alignement relâché décrivent une exposition, pas toujours des échecs actuels. `p=none` surveille sans demander quarantaine ou rejet. Sans `rua`, vous ne recevrez pas les rapports XML agrégés. Si l’alignement relâché est mentionné, décidez si vous avez besoin de `adkim=s` ou `aspf=s` avant `reject`.

Si le DNS live diffère du tableau registrar, comparez le champ brut à `dig +short TXT _dmarc.domaine`. Caches, anycast régional et imports partiels trompent les dashboards. DN01 interroge au moment de la requête ; conservez le TXT brut comme preuve externe.

Si le courrier légitime échoue après durcissement, DMARC peut être correct tandis que SPF ou DKIM ne le sont pas. Utilisez DNS Checker pour les includes SPF et DKIM Validator pour sélecteurs et expiration des clés. `pct=50` rend les échecs aléatoires ; DN01 avertit quand pct est inférieur à 100.

DMARC s’appuie sur SPF et DKIM. SPF valide le chemin enveloppe ; DKIM la signature cryptographique ; DMARC demande si l’un s’aligne sur le domaine visible dans From et quoi faire si les deux échouent. DN01 n’envoie pas de mail ni n’évalue des messages individuels : il inspecte la politique DNS qui indique aux récepteurs comment traiter le trafic non aligné. Associez-le donc à DKIM Validator et DNS Checker.

Le tag `p=` est obligatoire. Les politiques doivent être `none`, `quarantine` ou `reject` ; toute autre valeur est marquée invalide. `none` convient à la surveillance initiale mais DN01 avertit qu’il ne bloque pas les échecs. `quarantine` envoie généralement les échecs en spam ; `reject` demande de rejeter les messages. L’escalade doit s’appuyer sur les rapports `rua`.

`pct` limite la fraction de messages en échec concernés. Des valeurs sous 100 signifient une application partielle, utile en déploiement progressif mais déroutante au debug. DN01 parse `pct` comme entier et erreur si hors 0–100. La plupart des marques finissent à `pct=100` avec des rapports propres.

Les rapports agrégés vont vers les URI `rua`, souvent des `mailto:` enregistrés chez votre processeur. DN01 liste les destinations séparées par virgules et avertit si `rua` manque. Les rapports forensiques `ruf` sont optionnels et sensibles ; beaucoup omettent `ruf`. L’analyseur affiche les deux s’ils sont publiés.

`adkim` et `aspf` contrôlent la correspondance stricte (`s`) ou relâchée (`r`). S’ils manquent, DN01 suppose relâché et avertit que les récepteurs peuvent accepter des combinaisons apex/sous-domaine non voulues. Les modes stricts sont courants avant `reject`.

Valide dans DN01 signifie absence d’erreurs de parse bloquantes au moment du contrôle. Un enregistrement de surveillance avec `p=none` et sans `rua` peut être found avec avertissements. Traitez `valid=false` comme défaut DNS bloquant jusqu’à correction.

`dig TXT _dmarc.example.com` montre vite les chaînes brutes, mais l’interprétation reste manuelle. Il faut savoir qu’un `p=` dupliqué invalide l’enregistrement, que `sp` gouverne les sous-domaines et que sans `rua` il n’y a pas de reporting. DN01 encode ces règles et renvoie des recommandations en un passage.

DNS Checker sur DN01 affiche tous les TXT de la zone, utile quand SPF, DKIM et jetons de vérification coexistent. Il ne score pas le risque de politique ni l’application partielle de `pct`. Utilisez DNS Checker pour le contexte zone ; DMARC Analyzer pour la politique sur `_dmarc`.

Les rapports XML agrégés en boîte mail montrent l’historique d’envoi, mais arrivent avec retard et reflètent le passé. Ils ne prouvent pas la publication DNS actuelle après changement urgent. DN01 répond en secondes sur la publication live.

Les consoles DMARC hébergées offrent des tableaux de bord, mais les auditeurs externes ont besoin d’un lookup neutre du TXT visible sur internet. DN01 est indépendant de la boîte de rapports et fonctionne même sans `rua`.

Les validateurs TXT génériques n’appliquent pas toujours les règles DMARC. DN01 utilise le même parser Go que l’API de production ; SEO et API partagent la validation de `p`, `sp`, `pct`, doublons et défauts d’alignement.

Les inventaires tableur vieillissent dès qu’une édition DNS arrive. Une URL de résultat DN01 donne au support une instantanée actuelle avec nom de requête, enregistrement brut et durée.