Réputation de domaine gratuite
Testez la réputation de votre domaine e-mail sur les sources publiques, comprenez chaque résultat et reliez-le à l’IP d’envoi et aux messages qui font la délivrabilité.
Définir la réputation de domaine
La réputation de domaine, c’est la confiance que les messageries et filtres anti-spam accordent à un domaine d’envoi : elle décide si vos e-mails arrivent en boîte de réception, en spam ou nulle part. Elle dépend des plaintes, des rebonds, de l’engagement et de l’authentification SPF, DKIM et DMARC. Contrairement à la réputation IP, elle suit le domaine : changer de fournisseur ne la remet pas à zéro.
Lire le résultat de réputation de domaine
| Résultat | Signification | Que faire |
|---|---|---|
| Listé | Le domaine, ou l’IP de son serveur web ou mail, figure sur au moins une blocklist qui a répondu. | Ouvrez la preuve de chaque listage, corrigez le problème d’envoi ou la compromission, puis suivez la procédure de l’opérateur. |
| Sain | Aucune blocklist ayant répondu ne liste le domaine ni les IP de ses serveurs. | Rien ici, mais un résultat sain n’est qu’une couche de preuve de délivrabilité. |
| Sain, listes de domaines indisponibles | Les blocklists de domaines n’ont pas répondu, mais les IP des serveurs web et mail sont saines. | Preuve partielle. Relancez plus tard si la réponse compte pour un incident en cours. |
| Inconnu | Aucune blocklist n’a répondu : le test n’a aucune preuve dans un sens ou l’autre. | Traitez-le comme inconnu, pas sain, et réessayez dans un instant. |
| Moteur « Non testé » | Cette blocklist a refusé, expiré, limité la requête, ou ne gère pas ce type d’adresse. | Lisez-le comme inconnu pour cette source. Le verdict exclut déjà les moteurs indisponibles des totaux. |
| Aucun MX signalé | Le domaine ne publie aucun hôte mail : aucun chemin entrant déclaré à tester. Les expéditeurs se rabattent sur son adresse (règle MX implicite de la RFC 5321). | Confirmez avec le test MX, et publiez un MX nul si le domaine n’est fait que pour envoyer. |
Ce que ce test interroge vraiment
Chaque test a deux couches. Le domaine part vers les grandes blocklists de domaines que lisent les filtres, et son infrastructure (l’IP de son serveur web et celle de son premier hôte mail) vers un plus large lot de blocklists IP. La seconde couche compte : sur beaucoup de réseaux, les listes de domaines seules ne renvoient rien d’utile, et un serveur compromis explique souvent qu’un domaine sain soit filtré.
Chaque blocklist est interrogée deux fois : pour votre domaine, puis pour une entrée de test à laquelle elle répond toujours. Cette seconde requête distingue « non listé » de « cette source a refusé de répondre » : plusieurs grandes listes ne renvoient rien aux résolveurs publics ou non enregistrés, ce qui ressemble à une réponse saine. Les sources qui échouent sont indiquées non testées et exclues des totaux, pas comptées comme saines.
Testez avec le contexte de l’incident
Saisissez le domaine From visible, puis notez la campagne ou le chemin du message, l’heure d’envoi, le fournisseur et le symptôme. Un test de domaine sert surtout s’il est lié à un incident précis. En cas de rejet ou de spam, lisez les en-têtes ou le rebond d’origine pour trouver la vraie IP d’envoi et les identités d’authentification.
Un domaine sain ne garantit pas la livraison
Les sources publiques sont une couche de preuve. Les messageries gardent aussi des signaux privés (réputation, plaintes, engagement, destinataires) que ce test ne voit pas. L’IP de l’hébergeur web peut aussi n’avoir rien à voir avec l’envoi. Testez l’adresse d’envoi confirmée avec l’outil de réputation IP et envoyez un message type via le test de délivrabilité.
Tests de réputation liés
Le 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 dit ce test, et que ne dit-il pas ?
Il dit si les blocklists publiques enregistrent votre domaine ou ses serveurs. Il ne dit pas ce qu’une messagerie pense de vous en privé. Gmail, Microsoft et Yahoo ont chacun leurs signaux (plaintes, engagement, historique par destinataire) qu’aucun outil externe ne lit. Un résultat sain avec des e-mails toujours en spam est normal et parlant : le problème est dans ces signaux privés ou dans votre authentification, pas dans un listage public.
Pourquoi « Non testé » plutôt que « Non listé » ?
Parce que ce n’est pas pareil, et les confondre induit en erreur. Plusieurs grandes blocklists refusent les résolveurs publics ou non enregistrés et ne renvoient rien, ce qui ressemble à une réponse saine. Chaque liste est donc interrogée deux fois : pour votre domaine et pour une entrée de test à laquelle elle répond toujours. Si le test échoue, la source est indiquée non testée et exclue des totaux, pas comptée saine.
Réputation de domaine ou réputation IP ?
La réputation de domaine suit votre domaine d’où qu’il envoie : changer de fournisseur ne la remet pas à zéro. La réputation IP appartient à l’adresse d’où part un message, souvent l’infrastructure partagée du fournisseur, que vous ne contrôlez pas. Les deux pèsent. En pratique : corrigez les causes au niveau du domaine, qui sont à vous, et trouvez la vraie IP d’envoi dans un en-tête avant de croire qu’un souci d’IP est à votre charge.
Pourquoi tester aussi l’IP de mon serveur web ?
Parce qu’un site compromis est l’une des causes les plus fréquentes du filtrage d’un domaine jusque-là sain. Si l’IP de votre hébergeur est listée pour malware ou spam, le domaine en pâtit même si vos e-mails passent par un tout autre fournisseur. La couche infrastructure donne aussi une réponse utile là où les listes de domaines refusent de répondre.
Mon domaine est listé. Comment le faire retirer ?
Le retrait est accordé par l’opérateur de chaque liste, pas par un outil de test. Ouvrez la preuve de chaque listage, corrigez la cause (compte compromis, formulaire abusé, liste achetée, sous-domaine détourné), puis suivez la procédure de l’opérateur. Demander le retrait avant de corriger mène souvent à un nouveau listage, parfois plus long.
Un domaine neuf peut-il déjà avoir des soucis ?
Oui, de deux façons. Quelqu’un a pu l’enregistrer et l’abuser avant vous : vérifiez son historique au lieu de le croire vierge. Et un domaine sans historique d’envoi est traité avec prudence, d’où l’échec fréquent des gros volumes dès le premier jour. Aucun des deux n’est un listage, mais les deux pèsent sur la délivrabilité.
Quel lien entre authentification et réputation ?
L’authentification rend la réputation imputable à vous. SPF et DKIM confirment qu’un message vient bien d’un expéditeur autorisé de votre domaine, et DMARC dit quoi faire si aucun n’est aligné. Sans eux, quiconque usurpe votre domaine pèse sur son image, et vous ne pouvez pas prouver quels e-mails étaient les vôtres.
À quelle fréquence tester ?
Assez souvent pour repérer un listage avant qu’il coûte un cycle d’envoi : chaque semaine pour les gros volumes, chaque mois sinon, et tout de suite si des e-mails disparaissent. Un test ponctuel ne dit que l’instant où il tourne : ce qu’il faut savoir vite doit être surveillé en continu.
Chaque balise et mécanisme de DMARC, SPF et DKIM, expliqués au même endroit.
DMARC
- 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.
SPF
- v
- La balise de version doit valoir « spf1 », exclusivement. Une version fausse ou absente fait ignorer l’enregistrement SPF.
- ip4
- Cette balise liste les adresses IPv4 autorisées à envoyer pour le domaine.
- ip6
- Cette balise indique les adresses IPv6 autorisées à envoyer au nom du domaine.
- a
- La balise A valide l’expéditeur via l’adresse IP du domaine, le domaine courant par défaut s’il n’est pas précisé.
- mx
- La balise MX valide l’enregistrement MX du serveur mail, le domaine courant par défaut s’il n’est pas précisé.
- ptr
- La balise PTR lance un contrôle PTR des noms d’hôte des IP clientes, déconseillé par la RFC 7208 (trop de requêtes DNS).
- exists
- La balise exists vérifie la présence d’un enregistrement A sur le domaine indiqué.
- include
- La balise include est essentielle à un SPF exact : elle confirme aux destinataires que chaque domaine ou sous-domaine listé envoie légitimement.
- all
- La balise all est obligatoire, en fin d’enregistrement SPF : ses qualificateurs (~, +, -, ?) disent aux destinataires comment traiter les sources non autorisées.
DKIM
- v
- La balise de version indique la version de DKIM, qui doit toujours valoir 1.
- p
- La balise de clé publique, une chaîne créée à la configuration DKIM, ne doit pas être vide pour rester valide.
- t
- Cette balise liste des indicateurs séparés par deux-points ; seuls « y » et « s » sont définis, les autres doivent être ignorés.
- s
- Cette balise précise les types de service concernés. Les serveurs destinataires ignorent les types absents ou inconnus.
- h
- Cette balise indique les algorithmes de hachage permis (tous par défaut). Les destinataires ignorent ceux qu’ils ne connaissent pas ; l’expéditeur fixe la liste.
- n
- Cette balise est un champ de note facultatif pour les administrateurs, à n’utiliser qu’au besoin.