Interrogez et validez l’enregistrement TXT DMARC publié à _dmarc.<domain>, puis lisez votre politique, votre alignement et vos balises de reporting en clair. L’outil est gratuit, instantané, s’exécute entièrement dans votre navigateur, sans inscription et sans conserver de données.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
DMARC (Domain-based Message Authentication, Reporting and Conformance) est un enregistrement TXT publié dans le DNS à _dmarc.votredomaine.com. Il indique aux serveurs de réception quoi faire lorsqu’un message se présentant comme venant de votre domaine échoue à l’alignement SPF et DKIM, et où envoyer les rapports sur ces contrôles. DMARC s’appuie sur SPF et DKIM : un message valide DMARC dès que l’un des deux réussit et que le domaine authentifié s’aligne avec celui de l’en-tête From visible. Sans DMARC, un attaquant peut usurper votre domaine exact dans l’adresse From, et vous n’avez aucune visibilité sur qui envoie des messages en votre nom. Depuis février 2024, Google et Yahoo exigent des gros expéditeurs la publication d’un enregistrement DMARC : un enregistrement valide relève désormais de la délivrabilité de base, et plus seulement de la sécurité.
La balise de version. Elle doit valoir exactement v=DMARC1 et venir en premier, sans quoi les serveurs de réception ignorent tout l’enregistrement. C’est elle qui désigne l’enregistrement TXT comme une politique DMARC plutôt qu’une chaîne sans rapport.
La politique appliquée à votre domaine principal. p=none se contente d’observer et de collecter des rapports, p=quarantine envoie les messages en échec vers le dossier spam, et p=reject les bloque purement et simplement. Google et Yahoo exigent au moins p=none des gros expéditeurs, mais reject offre la meilleure protection contre l’usurpation.
sp= définit une politique distincte pour les sous-domaines (à défaut, elle hérite de p=), et pct= n’applique la politique qu’à un pourcentage des messages, pour un déploiement progressif. Notez que pct a été retiré de la dernière spécification DMARC (RFC 9989, publiée en 2026), qui la remplace par une balise t plus simple pour le mode test : les recommandations récentes privilégient donc un passage direct à l’application complète.
rua= est la boîte (par exemple mailto:dmarc@votredomaine.com) qui reçoit les rapports agrégés quotidiens recensant toutes les sources émettant au nom de votre domaine. ruf= reçoit les rapports d’échec message par message. Les rapports agrégés sont ce qui vous permet de passer sans risque de p=none à l’application.
Ces balises fixent la rigueur de l’alignement pour SPF et DKIM. La valeur par défaut r (souple) autorise les sous-domaines de votre domaine d’organisation à s’aligner, tandis que s (strict) impose une correspondance exacte. Le mode souple est le bon réglage par défaut pour la plupart des expéditeurs qui recourent à des sous-domaines ou à des services tiers.
La requête ne renvoie rien à _dmarc.votredomaine.com : les serveurs de réception n’appliquent donc aucune politique et votre domaine peut être usurpé librement. Publiez à cet emplacement un enregistrement TXT commençant par v=DMARC1; p=none; rua=mailto:vous@votredomaine.com pour commencer à observer sans risque pour vos envois.
p=none se contente d’observer et ne bloque jamais les messages usurpés, et pourtant beaucoup de domaines y restent des années. Servez-vous des rapports agrégés envoyés à votre adresse rua= pour confirmer que vos expéditeurs légitimes passent, puis passez à p=quarantine et enfin à p=reject pour une véritable protection.
Sans boîte de reporting rua=, vous ne voyez pas qui envoie au nom de votre domaine, ce qui rend l’application risquée. Ajoutez un rua=mailto: pointant vers une boîte ou un service de traitement des rapports DMARC que vous consultez réellement, avant de durcir la politique.
Publier deux enregistrements TXT à _dmarc, ou placer v= ailleurs qu’en première position, rend l’enregistrement invalide et les serveurs de réception l’ignorent. Conservez un enregistrement unique, commencez-le par v=DMARC1 et séparez chaque balise par un point-virgule.
SPF ou DKIM peuvent réussir alors que le domaine authentifié ne correspond pas à votre domaine From : DMARC échoue malgré tout. Vérifiez que SPF utilise bien votre propre domaine de Return-Path, ou que DKIM signe avec un d= correspondant à votre domaine From, et contrôlez aspf/adkim si vous vous appuyez sur des sous-domaines.
