Test de réputation IP
Testez une IP d’envoi sur les grandes blacklists et bases de réputation.
Définir la réputation IP
La réputation IP, c’est la confiance accordée à une adresse IP selon son historique d’envoi d’e-mails ou d’activité en ligne. Serveurs mail et systèmes de sécurité s’en servent pour décider si les messages d’une IP sont livrés, classés en spam ou bloqués. Elle dépend des plaintes, du volume, des blacklists et de l’engagement. Ce test fait aussi une recherche DNS inverse et renvoie le PTR qui relie l’IP à un nom d’hôte. Les messageries attendent un PTR sur une IP d’envoi, et son absence rend souvent suspects des e-mails venant d’une IP saine.
Base de connaissances e-mail
Qu’est-ce que le DNS inverse ?
Une recherche DNS inverse part d’une adresse IP et demande au DNS à quel nom d’hôte elle renvoie. La réponse vient d’un PTR, publié dans un espace dédié et non dans la zone de votre domaine : les IPv4 sont sous in-addr.arpa, octets inversés (192.0.2.25 devient 25.2.0.192.in-addr.arpa), les IPv6 sous ip6.arpa. C’est l’inverse d’une recherche normale, qui part d’un nom pour donner une adresse. Cet outil lance la requête pour toute IP et affiche le nom renvoyé, ou dit clairement qu’aucun PTR n’existe.
Pourquoi mon serveur d’envoi a-t-il besoin d’un DNS inverse ?
Les serveurs de réception se servent du DNS inverse pour vérifier l’identité de qui ouvre la connexion SMTP. Une IP sans PTR semble anonyme, et cela suffit à certains pour juger l’e-mail suspect ou le refuser. Les règles de Google imposent aux gros expéditeurs des IP avec DNS direct et inverse valides. À savoir avant de chercher le réglage : vous ne pouvez en général pas publier un PTR vous-même. Le DNS inverse dépend du titulaire de la plage d’IP (hébergeur, cloud ou service e-mail) : pour corriger un PTR manquant, demandez-lui, au lieu d’éditer votre zone.
Qu’est-ce que le DNS inverse confirmé ?
Le DNS inverse confirmé vérifie dans les deux sens. On cherche l’IP, on obtient un nom d’hôte via son PTR, puis on cherche ce nom en A (IPv4) ou AAAA (IPv6) et on vérifie que l’IP d’origine figure dans la réponse. Un PTR seul prouve juste qu’un nom a été publié ; la confirmation prouve que nom et adresse concordent, ce qui en fait un signal d’identité utile. La RFC 1912 recommande que PTR et adresses concordent. Réussir ce test n’est pas réussir l’authentification : il ne dit rien de SPF, DKIM ou DMARC.
Pourquoi la réputation IP compte pour la délivrabilité ?
La réputation IP est clé pour la délivrabilité : elle décide comment les serveurs perçoivent et traitent vos messages. À chaque envoi, les serveurs de réception lisent la réputation de votre IP pour livrer en boîte de réception, classer en spam ou bloquer. Une bonne réputation, bâtie sur de bonnes pratiques (peu de plaintes, volumes réguliers, authentification correcte), fait arriver vos e-mails. Une mauvaise réputation envoie vos e-mails en spam ou les fait rejeter, ce qui nuit à vos échanges et à votre marketing.
Qu’est-ce qui peut nuire à ma réputation IP ?
Plusieurs facteurs nuisent à votre réputation IP et à la délivrabilité. Un taux de plaintes élevé pèse lourd : des signalements fréquents disent aux fournisseurs que vos messages sont indésirables. Écrire à des adresses invalides ou périmées gonfle les rebonds et trahit une liste mal tenue. Figurer sur des blacklists est un autre gros problème, souvent dû à un contenu d’allure spam ou au non-respect des bonnes pratiques. Les pics soudains de volume, surtout sans warm-up de l’IP, éveillent les soupçons. Un faible engagement (ouvertures et clics) montre un désintérêt et abîme encore la réputation. Les listes achetées ou aspirées mènent souvent aux spamtraps et à des destinataires inactifs. Sans authentification SPF, DKIM et DMARC, vos e-mails semblent aussi moins fiables et risquent d’être classés en spam.
IP dédiée ou IP partagée : quelle différence pour la réputation ?
La différence tient à la façon dont la réputation se forme et s’entretient. Une IP dédiée sert à un seul expéditeur : sa réputation dépend de ses seules pratiques. Il garde le contrôle total de sa délivrabilité, idéal pour les entreprises qui envoient beaucoup et veulent une réputation stable. Une IP partagée sert à plusieurs expéditeurs, et sa réputation reflète le comportement de tous. C’est utile aux petits expéditeurs qui n’envoient pas assez pour bâtir seuls une réputation, mais risqué : si d’autres sur l’IP envoient mal (spam, par exemple), la délivrabilité de tous en souffre. Le choix dépend de votre volume, de la régularité de vos envois et du contrôle voulu sur votre réputation.
Combien de temps pour rétablir une réputation IP abîmée ?
De quelques jours à plusieurs semaines, selon la gravité des dégâts et les corrections apportées. Les petits soucis, comme une légère hausse des plaintes ou des pics d’envoi passagers, se règlent en quelques jours avec de meilleures pratiques et des listes nettoyées. Mais une IP sur blacklist ou aux mauvaises habitudes répétées peut demander des semaines, voire des mois. Pour accélérer : réduire les plaintes, améliorer l’engagement, authentifier avec SPF, DKIM et DMARC, et regagner la confiance par des envois réguliers à faible volume (le warm-up d’IP). Surveiller votre réputation IP reste essentiel pour suivre les progrès et tenir la délivrabilité dans la durée.
Quel effet a une blacklist sur ma réputation IP ?
Une blacklist nuit fortement à votre réputation IP et à la délivrabilité. Quand votre IP y entre, elle signale aux fournisseurs et filtres que vos e-mails sont peut-être suspects ou indésirables. Vos messages sont alors plus souvent bloqués ou classés en spam, et les ouvertures et l’engagement chutent. Les causes : gros volumes d’allure spam, trop de plaintes, spamtraps touchés ou liste mal tenue. Plus l’IP reste listée, plus la réputation souffre : trouvez la cause, corrigez vite et demandez le retrait. Une surveillance régulière et de bonnes pratiques d’envoi évitent les blacklists et gardent une réputation saine.
Une IP neuve peut-elle être mal réputée ?
Oui, même si elle est en général jugée « neutre » jusqu’aux premiers envois. Si l’IP servait avant à un expéditeur aux mauvaises pratiques, elle peut hériter d’une réputation négative, et donc de soucis de délivrabilité avant même votre premier e-mail. De plus, une IP sans réputation établie est traitée avec prudence : il faut faire son warm-up en montant le volume peu à peu pour gagner la confiance. Surveiller sa réputation et appliquer les bonnes pratiques (authentification SPF, DKIM et DMARC, listes propres, bon engagement) aide à bâtir et garder une réputation positive.
Réputation IP ou réputation de domaine : quelle différence ?
Les deux comptent pour la délivrabilité, mais jugent la confiance sous des angles différents. La réputation IP repose sur le comportement d’envoi d’une adresse IP précise : plaintes, rebonds et habitudes d’envoi décident si ses e-mails sont livrés ou bloqués. C’est crucial avec une IP dédiée, dont l’expéditeur contrôle toute la réputation. La réputation de domaine, elle, porte sur le domaine de l’expéditeur et non sur l’IP. Elle le suit d’une IP et d’un fournisseur à l’autre, ce qui en fait une mesure plus stable. Même en changeant d’IP, une mauvaise réputation de domaine nuit encore. Les fournisseurs s’en servent contre ceux qui changent souvent d’IP pour fuir les blacklists. En bref, la réputation IP tient à l’infrastructure d’envoi, celle du domaine à l’identité de l’expéditeur. Soigner les deux améliore le placement en boîte de réception.
À quelle fréquence surveiller ma réputation IP ?
Régulièrement, selon votre volume d’envoi et vos besoins. Si vous envoyez chaque jour, surtout en gros volume, surveillez chaque semaine, voire chaque jour, pour repérer et traiter vite tout ce qui nuit à la délivrabilité. Si vous envoyez moins souvent, un test mensuel peut suffire, mais surveillez davantage lors de campagnes critiques ou d’une chute soudaine de l’engagement. Une surveillance proactive repère tôt blacklists, plaintes ou hausse des rebonds, pour corriger avant que vos performances en pâtissent. Des outils de suivi automatisés simplifient la tâche et alertent en temps réel à chaque changement.
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.