Test DMARC gratuit et vérificateur
Testez le DMARC de tout domaine : trouvez le TXT public, validez sa politique et ses balises, voyez quoi corriger. DNS en direct, lecture seule, sans compte.
Que prouve un test DMARC ?
Un test DMARC interroge le TXT public de _dmarc.votredomaine.com, valide sa syntaxe et ses balises, et explique p, sp, rua, aspf et adkim. Il prouve ce que le DNS publie à cet instant, pas que vos e-mails réels passent DMARC, ni qui sont tous vos expéditeurs légitimes.
Lire votre résultat
| Résultat | Signification | Que faire |
|---|---|---|
| v=DMARC1; p=reject | Application complète : les destinataires sont priés de rejeter les e-mails en échec DMARC. | Gardez rua actif et surveillez les nouveaux expéditeurs avant de les ajouter. |
| p=quarantine | Application adoucie : les destinataires traitent les e-mails en échec comme suspects, souvent en spam. | Examinez un cycle d’envoi représentatif et vérifiez chaque expéditeur légitime avant d’envisager p=reject. |
| p=none | Suivi seul : p=none ne demande aucune application DMARC. Les destinataires peuvent filtrer ou rejeter via d’autres contrôles. | Corrigez l’alignement SPF/DKIM de chaque expéditeur des rapports, puis passez à quarantine. |
| Aucun DMARC trouvé | Le domaine ne publie ni préférence DMARC ni demande de rapports agrégés, et ne remplit pas le volet DMARC des exigences actuelles d’envoi en masse. | Publiez dès aujourd’hui v=DMARC1; p=none avec rua sur _dmarc.votredomaine.com, puis montez. |
| Plusieurs DMARC | Selon RFC 9989, plusieurs enregistrements sont ignorés lors de la découverte DMARC. | Supprimez tous les TXT de _dmarc sauf un. |
| Syntaxe invalide | Une balise requise mal formée peut rendre la politique inutilisable. v=DMARC1 vient en premier et p doit avoir une valeur valide. | Lisez l’erreur précise, refaites la balise touchée et publiez un enregistrement utilisable. |
| Balise inconnue | RFC 9989 impose aux destinataires d’ignorer les balises inconnues et de traiter les autres ; une balise inconnue seule n’invalide pas l’enregistrement. | Vérifiez que la balise est voulue. Retirez-la si c’est une coquille ou si elle ne sert plus. |
| pct obsolète | RFC 9989 a retiré pct, appliqué de façon inégale par les destinataires. | Échelonnez l’application par les rapports et des changements maîtrisés ; retirez pct après revue de compatibilité. |
| Pas de rua | Aucun rapport agrégé demandé : moins de preuves pour recenser les expéditeurs et changer de politique. | Ajoutez rua=mailto:… pour décider de l’application sur données. |
| sp plus faible que p | Quand ce DMARC est retenu au domaine organisationnel ou PSD, les sous-domaines existants peuvent recevoir une politique plus souple que lui. | Recensez les expéditeurs de sous-domaines, puis gardez une politique sp voulue ou laissez la politique parente s’appliquer. |
Ce que ce test peut prouver
Le test prouve ce que le DNS public renvoie au nom de la politique DMARC et si ses balises forment une politique utilisable. Son interprétation suit le standard DMARC RFC 9989 actuel. Il ne peut prouver qu’un e-mail réel a passé SPF ou DKIM, trouver tous vos expéditeurs ni prédire la décision privée d’un destinataire. Utilisez notre analyseur d’en-têtes pour un vrai e-mail et notre analyse de rapports DMARC pour les rapports agrégés. Si l’enregistrement manque ou est mal formé, créez-en un nouveau avec le générateur DMARC.
Pour un repère plus large, l’étude Palisade État de DMARC 2026 analyse l’application DMARC sur les 100 000 premiers domaines et détaille sa méthode.
Du résultat public à l’application
Un test ponctuel montre le problème du jour. Le vrai travail, c’est l’application : lire les rapports agrégés, aligner SPF et DKIM pour chaque expéditeur légitime et durcir la politique sans gêner le courrier réel. Palisade en fait un flux priorisé pour identifier les expéditeurs, analyser les échecs d’alignement, relire les changements proposés et mener chaque domaine à l’application, preuves à l’appui.
Pour les MSP, c’est multi-client : chaque domaine client testé, corrigé et appliqué depuis une console, avec un prix par domaine client qui baisse quand vous grandissez, sans mesurer le volume d’e-mails.
Tests et termes liés
p=nonep=quarantinep=rejectadkim / aspfdmarc=failLe logiciel DMARC qui fait le travail
Palisade transforme les rapports DMARC en tâches priorisées (expéditeurs, alignement) : validez chaque changement et menez vos domaines vers l’application depuis une console.
Audit de domaine gratuit, sans carte. Une carte lance l’essai de 15 jours.
Base de connaissances e-mail
Que lit un test DMARC ?
Un test DMARC interroge le TXT public de _dmarc.votredomaine.com et valide ses balises, dont p, sp, rua, aspf et adkim. Il montre la politique publiée dans le DNS, mais ne prouve pas qu’un e-mail réel a passé SPF, DKIM ou DMARC.
p=reject garantit-il le rejet de tout e-mail en échec ?
Non. p=reject exprime la demande du titulaire du domaine : rejeter les e-mails en échec DMARC. Le destinataire décide en dernier. Avant p=reject, vérifiez que chaque flux légitime passe SPF ou DKIM avec alignement.
Ce test prouve-t-il que mes e-mails passent DMARC ?
Non. Un enregistrement public peut être valide alors qu’un vrai expéditeur échoue, son Return-Path ou son domaine DKIM n’étant pas aligné sur le From visible. Testez un e-mail du flux réel et lisez son en-tête Authentication-Results.
Qu’est-ce que l’alignement ?
L’alignement DMARC compare le domaine From visible au domaine SPF authentifié ou au domaine de signature DKIM. Un e-mail passe DMARC quand SPF ou DKIM passe et s’aligne. Le mode souple admet le même domaine organisationnel ; le strict exige le domaine exact.
Pourquoi plusieurs DMARC sont invalides ?
La découverte DMARC attend un seul TXT de politique utilisable par nom. Selon RFC 9989, s’il reste plusieurs DMARC sur la même cible, ils sont ignorés. Regroupez les balises en un enregistrement sur _dmarc et supprimez les doublons.
p=none suffit-il ?
p=none ne demande aucune application pour les e-mails en échec DMARC. Les destinataires peuvent filtrer ou rejeter via d’autres contrôles. Avec rua, le domaine demande aussi des rapports agrégés. Servez-vous-en pour recenser et aligner vos expéditeurs, puis passez à quarantine et reject quand les preuves sont nettes.
Comment utiliser les rapports agrégés avant l’application ?
Servez-vous des rapports agrégés pour identifier les sources d’envoi, donner un responsable à chacune et analyser les échecs SPF, DKIM et d’alignement. Confirmez les flux clés par de vrais en-têtes, puis changez de politique après un cycle d’envoi complet prouvant que tout est prêt.
Que change RFC 9989 ?
RFC 9989 a remplacé RFC 7489 comme spécification DMARC Standards Track en mai 2026. Elle découvre la politique en remontant l’arbre DNS, ajoute les balises np, psd et t, et retire pct. Les rapports agrégés et d’échec relèvent des RFC 9990 et RFC 9991.
DMARC bloque-t-il tout phishing ou BEC ?
Non. DMARC réduit l’usurpation directe d’un domaine protégé chez les destinataires qui l’appliquent, mais pas les domaines sosies, l’usurpation du nom affiché, les comptes compromis ni toutes les techniques de phishing. C’est un contrôle d’authentification, pas un filtre ni un anti-phishing complet.
Chaque balise possible d’un DMARC et ce qu’elle contrôle.
- vVersion
- La balise Version est indispensable dans un DMARC et doit valoir strictement « DMARC1 ». Si la valeur est incorrecte ou la balise absente, l’enregistrement DMARC n’est pas valide et il est ignoré.
- pPolitique DMARC
- La balise de politique DMARC accepte trois valeurs pour le courrier qui échoue : none ne demande aucune application, quarantine un traitement suspect, reject le rejet. Les destinataires décident en dernier et peuvent filtrer ou rejeter via d’autres contrôles en p=none. Les rapports agrégés se demandent à part, via la balise rua.
- ruaDestination des rapports agrégés
- La destination des rapports agrégés est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour envoyer les rapports agrégés. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- rufDestination forensique
- La destination des rapports forensiques (d’échec) est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour livrer les rapports d’échec. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- spSous-domaines
- Par défaut, la politique des sous-domaines hérite de la balise de politique du domaine principal (p=), décrite plus haut, sauf mention contraire. Comme pour le domaine, les valeurs possibles sont « none », « quarantine » ou « reject ». Cette option reste toutefois peu utilisée en pratique.
- adkimAlignement DKIM
- Cette balise fixe l’alignement de la signature DKIM, c’est-à-dire la correspondance entre le domaine DKIM et le domaine d’origine du « Header From ». Valeurs possibles : « r » (relaxed) et « s » (strict). Par défaut, « r » accepte une correspondance partielle entre ces domaines, tandis que « s » exige qu’ils soient identiques.
- aspfAlignement SPF
- Cette balise fixe l’alignement SPF, c’est-à-dire la compatibilité entre le domaine SPF (l’expéditeur) et le domaine du « Header From ». Deux valeurs : « r » (relaxed) et « s » (strict). Par défaut, « r » tolère une correspondance partielle entre les domaines. À l’inverse, « s » exige une correspondance exacte des domaines.
- foOptions forensiques
- Les options des rapports forensiques sont « 0 », « 1 », « d » et « s ». Par défaut, « 0 » déclenche un rapport seulement quand les alignements SPF et DKIM échouent tous deux. « 1 » en déclenche un dès que SPF ou DKIM ne passe pas. « d » produit un rapport pour les échecs de validation DKIM, « s » pour les problèmes SPF. Pour recevoir ces rapports forensiques, il faut renseigner la balise « ruf ».
- rfFormat des rapports
- Le format des rapports d’échec peut valoir « afrf » ou « iodef », les deux seules options autorisées.
- pctPourcentage (historique)
- L’ancienne balise Pourcentage demandait d’appliquer quarantine ou reject à une partie seulement du courrier en échec DMARC. La RFC 9989 a retiré pct, l’application partielle étant mise en œuvre de façon inégale. Les nouveaux enregistrements l’omettent et échelonnent via les rapports agrégés, des politiques entières et des sous-domaines à faible volume.
- riFréquence des rapports
- L’intervalle des rapports indique, en secondes, la fréquence des rapports XML. La valeur standard est 86400 secondes, soit un rapport par jour. Notez toutefois que, quel que soit l’intervalle indiqué, les fournisseurs d’accès (FAI) envoient en général ces rapports selon leur propre calendrier, le plus souvent une fois par jour également.