E-mail. Intelligent. Concentré.
Un e-mail rapide et multiplateforme conçu pour filtrer le bruit.
Définition
💡 Reverse DNS lookup : le processus de résolution d'une adresse IP vers un nom de domaine, l'inverse du fonctionnement habituel du DNS. Pour les e-mails, c'est ainsi que les serveurs de réception vérifient si une adresse IP d'envoi appartient réellement au domaine qu'elle prétend représenter. Le DNS normal va du domaine vers l'IP. Le reverse DNS va de l'IP vers le domaine. Les deux directions doivent correspondre.
Est-ce que ça vous concerne ?
Probablement pas directement, mais il vaut la peine de savoir pourquoi.
Si vous envoyez des e-mails via Gmail, Google Workspace, Outlook ou Microsoft 365, le reverse DNS est géré automatiquement par Google et Microsoft sur leurs propres IP d'envoi. Vous n'y touchez pas. Il en va de même pour les IP partagées sur des plateformes comme Mailchimp ou Klaviyo. Ces ESP gèrent les enregistrements PTR pour les adresses IP à partir desquelles leurs serveurs envoient.
Le reverse DNS devient votre problème si vous envoyez depuis une adresse IP dédiée (via un service comme SendGrid ou Mailgun) ou si vous exploitez votre propre serveur de messagerie sur un VPS ou une instance cloud. Dans ces situations, l'enregistrement PTR de votre IP n'est pas configuré automatiquement. Vous devez le configurer. Et s'il est manquant ou mal configuré, la délivrabilité de vos e-mails en pâtit.
Le test pratique : si vos e-mails atterrissent dans les spams et que vos DKIM, SPF et enregistrement DMARC passent tous, un enregistrement PTR manquant ou défectueux est la prochaine chose logique à vérifier.
Comment fonctionne le reverse DNS lookup
Ce processus s'appelle le Forward-Confirmed reverse DNS (FCrDNS). Voici ce qui se passe lorsque votre e-mail arrive sur un serveur de réception.
Le serveur de réception prend votre adresse IP d'envoi et interroge le DNS pour trouver l'enregistrement PTR (Pointer) qui y est associé. Cette recherche s'effectue dans une zone DNS spéciale appelée in-addr.arpa. Si un enregistrement PTR est configuré, la recherche renvoie un nom d'hôte, quelque chose comme mail.yourbusiness.com.
Le serveur de réception effectue ensuite une recherche DNS directe classique sur ce nom d'hôte pour confirmer qu'il correspond bien à l'IP d'origine. Si l'IP correspond, la vérification réussit. Si le nom d'hôte correspond à une IP différente, ou s'il n'y a aucun enregistrement PTR, l'expéditeur paraît peu fiable.
Cette vérification bidirectionnelle, c'est tout l'intérêt. N'importe qui peut prétendre envoyer depuis yourbusiness.com. Bien moins de gens peuvent manipuler à la fois l'enregistrement PTR et le DNS direct pour les faire correspondre. Depuis que Google et Yahoo ont durci les exigences pour les expéditeurs en masse en 2024, Gmail renvoie désormais une erreur spécifique (421 4.7.23) pour les IP sans enregistrement PTR valide. Ce n'est plus optionnel pour quiconque envoie un volume significatif.
Un reverse DNS manquant ou incohérent est l'un des problèmes de délivrabilité les plus sournois. Il ne produit pas toujours de rebond clair. Vos e-mails peuvent simplement partir discrètement dans les spams sans aucune explication.
Comment vérifier votre enregistrement PTR
Avant de tenter de corriger quoi que ce soit, vérifiez qu'un enregistrement PTR existe et qu'il est correct.
MXToolbox : rendez-vous sur mxtoolbox.com/ReverseLookup.aspx et saisissez l'adresse IP de votre serveur de messagerie. Il renverra l'enregistrement PTR ou signalera s'il n'en existe aucun.
Ligne de commande (Mac/Linux/Windows) :
nslookup [your IP address]
Ou sur Mac/Linux :
dig -x [your IP address]
La sortie devrait afficher un enregistrement PTR pointant vers le nom d'hôte de votre serveur de messagerie. S'il n'affiche rien, ou pointe vers quelque chose de générique comme le nom d'hôte par défaut d'un fournisseur cloud (ec2-203-0-113-25.compute-1.amazonaws.com), c'est un problème à corriger.
Comment configurer ou corriger un enregistrement PTR
Voici le détail crucial que la plupart des gens ignorent : les enregistrements PTR sont contrôlés par celui qui possède l'adresse IP (votre hébergeur ou fournisseur VPS, et non votre bureau d'enregistrement de domaine).
Vous ne pouvez pas définir un enregistrement PTR chez Cloudflare ou GoDaddy. Vous le configurez via DigitalOcean, Vultr, Hetzner, AWS, Linode, ou là où réside l'IP de votre serveur de messagerie.
Processus général (serveur de messagerie auto-hébergé) :
- Connectez-vous au tableau de bord de votre hébergeur
- Trouvez la section de gestion du réseau ou des IP (recherchez « Reverse DNS » ou « enregistrements PTR » ; l'emplacement varie selon le fournisseur)
- Saisissez le nom d'hôte de votre serveur de messagerie (par exemple, mail.yourdomain.com) comme valeur PTR pour l'IP de votre serveur
- Enregistrez et laissez le temps à la propagation DNS (généralement une heure, parfois jusqu'à 48 heures)
- Vérifiez à l'aide de l'outil de reverse lookup de MXToolbox
Pour que votre configuration passe le FCrDNS, vous devez également confirmer que le nom d'hôte de votre serveur de messagerie possède un enregistrement A qui correspond à la même IP. Les deux directions doivent fonctionner.
Si vous êtes sur une IP dédiée via un ESP : SendGrid, Mailgun et les services similaires ont leurs propres flux de configuration du reverse DNS dans leurs tableaux de bord. Pour SendGrid, c'est sous Settings > Sender Authentication > Reverse DNS. Consultez le guide reverse DNS de SendGrid pour la procédure complète. Ils génèrent les enregistrements et vous guident dans leur publication.
Si vous êtes sur une IP partagée via un ESP : le fournisseur gère les enregistrements PTR pour les IP partagées. Vous n'avez rien à configurer.
Garder un reverse DNS propre
Évitez les noms d'hôte cloud génériques. Un PTR par défaut d'un fournisseur cloud signale « instance VPS générique » plutôt que « serveur de messagerie géré ». Les serveurs de réception considèrent cela comme un signal d'alerte. Remplacez-le par un nom d'hôte personnalisé qui correspond à votre domaine.
Le PTR est une couche, pas l'ensemble du dispositif. Un PTR propre aide à établir une légitimité d'envoi de base, mais il fonctionne aux côtés de DKIM, SPF et DMARC, pas à leur place. Un PTR parfait sans DKIM peine tout de même. Mettez d'abord en place les trois couches d'authentification ; ensuite, vérifiez votre PTR.
Revérifiez après toute modification de l'infrastructure. Si vous migrez vers un nouveau serveur, obtenez une nouvelle IP ou changez d'hébergeur, votre enregistrement PTR ne suit pas automatiquement. Il doit être reconfiguré pour la nouvelle IP. Facile à oublier. Vaut la peine d'être vérifié.
Un enregistrement PTR par IP, pointant vers votre nom d'hôte d'envoi. Votre enregistrement PTR doit correspondre au même nom d'hôte que votre serveur SMTP annonce dans les échanges SMTP (la commande HELO/EHLO). Les incohérences paraissent suspectes aux filtres anti-spam.
Termes associés