DMARC checker en masse

Lancer la vérification

1. Une liste de domaines propre

Mettez un domaine d’organisation ou d’envoi par ligne. Retirez URL, adresses e-mail, adresses IP et doublons avant de soumettre la liste. Notez à part le responsable de chaque domaine, comme une plateforme de messagerie d’entreprise ou un expéditeur marketing, car le résultat DNS n’identifie pas le responsable opérationnel.

Si la liste dépasse la taille de lot de l’outil, divisez-la en lots nommés. Conservez la liste d’origine pour relancer la même vérification après correction.

2. Soumettez un lot à un outil en masse

Ouvrez un outil qui prend explicitement en charge plusieurs domaines et soumettez un lot. Lisez la portée des résultats affichés avant d’agir. Par exemple, dmarc.cc dit n’afficher que les 50 premiers domaines soumis : une liste plus longue demande plusieurs passages ou une analyse avec e-mail vérifié.

Ne concluez pas qu’un domaine n’a pas d’enregistrement parce que son résultat manque. Vérifiez d’abord que l’outil a bien évalué ce domaine dans le lot soumis.

3. Confirmez par une requête DNS directe

Pour un domaine à suivre, interrogez directement le nom DMARC. Remplacez le domaine d’exemple par le domaine examiné.

dig +short TXT _dmarc.yourdomain.com

Cette commande renvoie la réponse DNS publique vue par votre résolveur. Elle ne prouve ni que le serveur faisant autorité a la même réponse, ni que le DNS s’est propagé partout, ni qu’un expéditeur utilise bien le domaine.

Ne remplacez pas un enregistrement DMARC d’après un seul résumé de lot. Notez d’abord la réponse TXT actuelle et trouvez l’équipe ou le service qui gère le courrier du domaine.

Lire les résultats

Un résultat DMARC est présent

Un résultat DMARC présent signifie que l’outil a trouvé un enregistrement public au nom DMARC de ce domaine. Notez le champ de politique comme attribut d’inventaire, puis passez aux preuves des messages et rapports avant de juger la politique adaptée.

Selon la RFC 7489, DMARC s’évalue par l’alignement des identifiants et les résultats d’authentification. Un enregistrement publié ne garantit pas que SPF ou DKIM passe et s’aligne pour chaque expéditeur.

Un résultat DMARC est absent ou flou

Un résultat absent ou flou est prioritaire pour une vérification directe. Vérifiez l’orthographe du domaine, interrogez _dmarc.yourdomain.com et consultez le fournisseur DNS faisant autorité si la réponse du résolveur public surprend.

Ne déduisez pas la bonne valeur à partir d’un autre domaine du lot. Destinataires des rapports, choix de politique et chemins d’envoi autorisés sont propres à chaque domaine.

Un résultat SPF est à revoir

Un résultat signalant un problème SPF cible la tâche suivante, mais n’identifie pas l’expéditeur en cause. Utilisez le test SPF de Palisade pour examiner l’enregistrement SPF public d’un domaine, puis un message reçu de l’expéditeur en cause.

SPF peut réussir alors que DMARC échoue, si le domaine authentifié par SPF n’est pas aligné avec le domaine From visible. Le guide d’authentification pour Gmail explique pourquoi vérifier l’authentification dans le contexte du vrai chemin d’envoi.

Le champ de politique à revoir

Le champ de politique est un attribut de l’enregistrement DMARC publié. Ce n’est pas, en soi, un seuil de correction. Un domaine avec une politique doit encore prouver que ses flux légitimes s’authentifient et s’alignent. Un domaine sans résultat utile demande une vérification DNS et une décision de responsabilité avant toute création ou modification.

Séparez la sortie du lot et la réponse DNS directe des preuves issues des messages. Chacune répond à une question différente.

Agir sur le résultat

Commencez par les domaines dont le résultat est absent, flou ou signale un souci SPF. Pour chacun, réunissez quatre niveaux de preuve avant de tenir un changement pour terminé :

• DNS : interrogez le nom DMARC via le fournisseur DNS faisant autorité et au moins un résolveur public.
• Prestataire : voyez si le service d’envoi montre le domaine authentifié ou vérifié.
• Message : envoyez un vrai message par le chemin de production exact et examinez son en-tête Authentication-Results.
• DMARC : examinez les rapports agrégés une fois le courrier accumulé.

Si le lot signale un souci SPF, identifiez d’abord l’expéditeur. S’il signale un souci d’enregistrement DMARC, conservez l’enregistrement actuel et vérifiez la responsabilité avant de toucher au DNS. Si l’état DKIM d’un expéditeur est incertain, utilisez le test DKIM de Palisade pour la clé publique, puis comparez avec les valeurs d= et s= d’un vrai message.

Retester

Relancez le même lot une fois la réponse DNS changée. Ne comparez que les domaines du premier passage et notez l’heure de chaque vérification. Confirmez la requête DNS directe à part.

Envoyez ensuite un nouveau message par la même application, la même adresse d’expéditeur et le même chemin de destinataire que lors du problème. Examinez l’en-tête Authentication-Results obtenu. Une fois les rapports agrégés accumulés, voyez si d’autres sources envoient encore pour le domaine.

Un enregistrement public modifié est un résultat DNS. Un message reçu conforme prouve le chemin d’envoi. Les rapports agrégés montrent les sources observées dans le temps.

Tester chaque domaine après l’inventaire

Utilisez le test DMARC de Palisade pour examiner l’enregistrement DMARC public d’un domaine à suivre après le lot. Comparez le résultat à votre requête DNS directe et à un message reçu avant de changer la politique.

Commencez avec Palisade pour analyser en continu les rapports agrégés DMARC de vos domaines. Palisade repère les sources d’envoi et les problèmes d’authentification ou d’alignement, crée des tickets de correction priorisés et peut proposer la prochaine étape de politique, validée par un humain. Il ne change pas la politique DMARC pour vous, ne prouve pas que chaque futur message s’authentifiera et ne remplace pas l’analyse des messages.