Comment vérifier le DMARC de tous vos domaines clients en une fois

Collez tous vos domaines clients dans le vérificateur DMARC en masse et filtrez par politique. Chaque ligne indique si le domaine a un enregistrement DMARC, sa politique (none, quarantine ou reject), la politique des sous-domaines, où vont les rapports agrégés et les réglages d'alignement. Vous voyez d'un coup d'œil quels clients n'ont pas de DMARC, lesquels se contentent de surveiller et lesquels appliquent leur politique.

Vérifier DMARC sur une liste de domaines →

Les vérifier en masse

1. Ouvrez le vérificateur DMARC en masse.
2. Collez les domaines, un par ligne : jusqu'à 100 par passage, ou 500 après une connexion Google gratuite. Les adresses email et les URL fonctionnent aussi ; le domaine est extrait de chacune.
3. Cliquez sur Check DMARC (vérifier DMARC).
4. Lisez chaque ligne : Reject, Quarantine, Monitoring only, Partly enforced, Broken ou No DMARC, avec les balises qui l'expliquent.
5. Filtrez par politique, par exemple tous les domaines en Monitoring only, et téléchargez le CSV pour votre rapport client.

Le faire à la main

printf "google.com\ngithub.com\ndebian.org\nshopify.com\nneverssl.com\ntest.com\n" > clients.txt

while read -r d; do
  rec=$(dig +short txt "_dmarc.$d" | tr -d '"' | grep '^v=DMARC1')
  p=$(echo "$rec" | sed -n 's/.*[; ]p=\([a-z]*\).*/\1/p')
  echo "$d,${p:-NO DMARC}"
done < clients.txt
# google.com,reject
# github.com,quarantine
# debian.org,none
# shopify.com,reject
# neverssl.com,NO DMARC
# test.com,NO DMARC

Nous avons lancé cette commande le 9 novembre 2026. Deux lignes méritent un examen plus attentif :

• shopify.com : dig +short txt _dmarc.shopify.com affiche d'abord dmarcreject.shopify.com., parce que le nom _dmarc est un CNAME. L'enregistrement vers lequel il pointe indique p=reject. Beaucoup d'entreprises gèrent DMARC de façon centralisée de cette manière.
• test.com : il existe un enregistrement TXT à _dmarc.test.com, mais il ne commence pas par v=DMARC1, donc les destinataires l'ignorent. C'est pour cela que la boucle ne garde que les lignes qui commencent par v=DMARC1.

Le motif sed cherche p= après un point-virgule ou une espace, pour ne pas confondre sp=reject avec la politique principale. La boucle ne fait pas ce que font les destinataires pour un sous-domaine sans enregistrement à lui : la RFC 9989, section 4.10 leur demande de remonter l'arborescence DNS jusqu'à l'enregistrement du parent. Le vérificateur en masse fait cette remontée et marque la ligne comme héritée.

Classer les résultats en trois piles

• Pas de DMARC. Pas d'enregistrement, un enregistrement qui ne commence pas par v=DMARC1, ou deux enregistrements sous le même nom. La RFC 9989 demande aux destinataires de tous les ignorer quand plus d'un est renvoyé. Ces clients passent en premier. Les consignes pour les expéditeurs de Google exigent des expéditeurs en masse qu'ils publient DMARC.
• p=none. Rapports uniquement. La même page de Google indique que la politique peut être réglée sur none, donc cela satisfait le minimum, mais les emails usurpés sont toujours livrés. Vérifiez que rua= est renseignée, sinon personne ne lit les rapports.
• Quarantine ou reject. La politique est appliquée. Vérifiez aussi sp= : un client peut être en reject sur le domaine principal pendant que ses sous-domaines restent en none.

Ce qui a changé en mai 2026

La RFC 9989 a remplacé la RFC 7489 comme norme DMARC. Trois changements comptent quand vous lisez les enregistrements de vos clients :

• pct= a disparu. L'annexe A.6 explique que les valeurs autres que 0 et 100 n'étaient pas appliquées de façon cohérente. Les enregistrements avec pct= fonctionnent encore auprès des destinataires qui la lisent, mais ne bâtissez pas un déploiement autour d'elle.
• t=y est le nouveau drapeau de test. Il demande aux destinataires d'appliquer un niveau en dessous de la politique indiquée, donc p=reject; t=y est traité comme quarantine.
• np= couvre les sous-domaines qui n'existent pas. Elle fixe une politique pour des noms inventés comme invoice.client.com, que créent les spammeurs.

Pour faire passer un client de none à l'application de la politique, voir DMARC de none à reject. Pour lire les rapports qui reviennent, voir comment lire les rapports agrégés DMARC.

Étape suivante : vérifier les listes que vous envoyez pour vos clients

DMARC protège le domaine d'un client contre l'usurpation. Il n'empêche pas les rebonds sur les adresses mortes des listes que vous envoyez pour lui, qui nuisent à la même réputation. Importez chaque liste sur /verify pour vérifier chaque boîte sans rien envoyer. Les 100 premières vérifications sont gratuites avec une connexion Google, sans carte.

Pro, 39 $ par mois : vérification d'emails illimitée.* Jamais décomptée, jamais coupée. Voir les tarifs.

*Usage raisonnable : les 100 000 premières vérifications du mois à pleine vitesse, puis plus lentement, jamais coupées.

À lire aussi : vérifier l'enregistrement DMARC d'un domaine, comment les agences rendent compte de la vérification des listes à leurs clients.