Defaults.Exposed › Corrections › DNS inversé (PTR)

Comment corriger DNS inversé (PTR)

Le DNS inversé est le badge d'identité du serveur qui envoie les e-mails de votre entreprise. Quand un fournisseur destinataire comme Gmail ou Microsoft 365 cherche qui se cache derrière l'adresse d'envoi et obtient un nom vérifié, vos e-mails ont l'air légitimes. Sans badge — ou si le nom et le numéro ne concordent pas — vos factures et devis parfaitement authentiques sont traités comme suspects et discrètement mis à la corbeille ou rejetés.

En clair, pour votre entreprise : Vos factures, devis et réponses aux clients atterrissent discrètement dans les spams ou n'arrivent jamais — si bien que des affaires s'enlisent, des paiements arrivent en retard, et des clients pensent que vous les avez ignorés, sans qu'aucun de ces problèmes n'apparaisse comme une erreur que vous remarqueriez.

Ce que cela peut vous coûter

Vous envoyez un devis à un prospect chaud, il tombe dans ses spams, et il choisit le concurrent qui « a vraiment répondu » — et vous n'avez même jamais su que l'e-mail n'était pas arrivé.
Les factures aux clients disparaissent dans les indésirables, les paiements arrivent avec des semaines de retard, et votre trésorerie en pâtit parce que personne n'a jamais vu l'e-mail.
Un client se plaint que vous ne l'avez jamais rappelé — alors que si ; son fournisseur de messagerie a discrètement jeté votre réponse parce que votre serveur d'envoi ne pouvait pas prouver son identité.
Votre domaine réussit haut la main la revue de sécurité d'un nouveau client sur tout le reste, puis est signalé parce que votre serveur de messagerie n'a pas d'identité correcte — un petit détail qui vous fait paraître négligent.
Vous êtes passé à un VPS bon marché ou à une nouvelle application pour envoyer vos infolettres et factures, et du jour au lendemain votre taux de distribution chute — car ce nouveau serveur d'envoi n'a pas de badge DNS inversé et les grands fournisseurs ne lui font plus confiance.

Pourquoi c'est important. Chaque grand fournisseur de messagerie vérifie l'identité du serveur qui envoie vos e-mails, et il la vérifie sur chaque message. Si ce serveur ne peut pas prouver qui il est — ou si son nom et son numéro se contredisent — vos vrais e-mails professionnels sont traités comme s'ils pouvaient être du spam. Vous perdez des réponses, des paiements et de la confiance, et comme rien ne rebondit, vous n'en découvrez généralement jamais la raison.

En bref

Quand votre entreprise envoie un e-mail, il part d’un serveur de messagerie, et chaque serveur sur Internet a une adresse numérique — son IP. Le DNS inversé (un enregistrement « PTR ») est le badge nominatif de ce serveur : il permet à quiconque voit le numéro de retrouver le nom correct qui se cache derrière, comme mail.votreentreprise.com.

Les grands fournisseurs destinataires — Gmail, Microsoft 365, Yahoo — vérifient ce badge sur chaque message que vous envoyez. Un serveur capable de se nommer, et où le nom et le numéro concordent, ressemble à un serveur de messagerie légitime. Un serveur sans badge, ou avec un badge qui ne correspond pas, ressemble exactement aux machines anonymes et jetables qu’utilisent les spammeurs. Du coup, vos vraies factures et devis commencent chaque échange sous le coup de la suspicion — et beaucoup y perdent.

Le plus frustrant, c’est que rien ne vous prévient que cela se produit. Pas de rebond, pas d’erreur. Vos e-mails sous-performent simplement en silence.

Ce que cela peut vous coûter

Voici les façons quotidiennes dont un enregistrement DNS inversé absent ou discordant se traduit par de l’argent et de la confiance qui s’envolent. Nous ne nommons jamais d’entreprise réelle — ce sont des schémas que nous observons dans les données.

Le devis qui n’est jamais arrivé. Vous envoyez un devis détaillé à un prospect qui l’a demandé le matin même. Son fournisseur ne peut pas vérifier votre serveur d’envoi, alors il dépose le message dans les spams. Il ne fouille pas dans les indésirables. Dans l’après-midi, il a retenu le devis du concurrent — celui qui « est vraiment arrivé ». Vous mettez cela sur le compte d’une piste lente ; en réalité, votre e-mail n’a jamais été vu.
La facture dans le vide. Vous facturez un bon client. Elle atterrit dans son dossier indésirable. Trente jours plus tard, vous relancez un paiement en retard sans qu’il y soit pour rien — et voilà une conversation gênante, une relation tendue, et un trou de trésorerie entièrement évitable.
« Vous n’avez jamais répondu. » Un client est agacé que vous ayez ignoré sa question. Ce n’est pas le cas — vous avez répondu le jour même. Son fournisseur de messagerie a discrètement jeté votre réponse parce que votre serveur d’envoi semblait peu fiable. Vous passez pour peu professionnel pour quelque chose que vous avez en réalité bien fait.
Le serveur d’envoi maison qui a tout discrètement empoisonné. Pour économiser, vos e-mails (ou seulement vos infolettres et factures automatisées) se sont mis à sortir par un VPS bon marché ou une nouvelle application d’envoi. Ce serveur n’a jamais reçu de badge DNS inversé. Du jour au lendemain, votre taux de distribution a fléchi sur toute la ligne — et comme il n’y a aucun message d’erreur, il a fallu des mois pour seulement en soupçonner la cause.
Le signalement en revue de sécurité. L’équipe informatique d’un client plus important effectue un contrôle de routine sur votre domaine lors de l’intégration. Tout le reste va bien, mais votre serveur de messagerie n’a pas d’identité correcte. C’est un point technique mineur, mais il se lit comme de la négligence — et vous voilà à le corriger sous la pression d’une échéance, ou à vous justifier, quand le domaine d’un concurrent vient de passer sans encombre.

Le fil rouge de tout cela : le coût retombe sur vous, il est invisible pendant qu’il se produit, et la correction est gratuite.

Ce que c’est réellement

Le DNS normal transforme un nom en un numéro : vous tapez votreentreprise.com, et le DNS renvoie l’adresse IP à laquelle se connecter. Le DNS inversé fait l’inverse — il retransforme un numéro en un nom. À partir de l’IP 203.0.113.10, une recherche inversée (un « enregistrement PTR ») répond mail.votreentreprise.com.

Pourquoi les destinataires y tiennent : quand votre serveur de messagerie se connecte à Gmail pour livrer un message, Gmail voit l’IP qui se connecte. La première chose qu’un filtre de messagerie sérieux fait est de demander « qui est cette machine ? » — en effectuant une recherche inversée sur cette IP. Un vrai serveur de messagerie d’entreprise a une réponse (mail.votreentreprise.com). Une machine à spam jetable n’en a généralement pas, ou porte un nom générique attribué par le fournisseur comme host-203-0-113-10.unfai.net. La présence et la qualité du badge sont donc l’un des tout premiers signaux de confiance appliqués à vos e-mails — avant même que SPF, DKIM ou le contenu du message soient examinés.

Il vérifie le serveur de messagerie, pas votre site web. C’est là que les gens trébuchent. L’adresse de votre site web est souvent derrière un CDN ou un proxy (comme Cloudflare) et n’aura jamais de badge correspondant — et c’est très bien, car le DNS inversé pour l’e-mail concerne l’IP du serveur de messagerie MX, une machine complètement distincte. Ce contrôle recherche correctement le serveur de messagerie principal de votre domaine (l’enregistrement MX de priorité la plus basse), le résout vers son IP, et vérifie le badge sur cette IP.

La moitié que la plupart des configurations ratent : il doit concorder dans les deux sens. Avoir un nom ne suffit pas à lui seul. Gmail et les autres grands filtres font quelque chose de plus strict, appelé DNS inversé confirmé en avant (FCrDNS) :

Rechercher l’IP → obtenir un nom (par ex. mail.votreentreprise.com).
Rechercher maintenant ce nom à l’envers → il doit se résoudre vers la même IP d’où vous êtes parti.

Si les deux sens concordent, le serveur est confirmé et pleinement digne de confiance. S’il y a un nom mais qu’il pointe ailleurs (ou nulle part), le serveur n’est qu’à moitié digne de confiance — un badge qui ne survit pas à un second coup d’œil est traité comme plus faible qu’on ne l’espérerait. Un PTR qui pointe vers un nom d’hôte contrôlé par un attaquant, et qui ne se résout pas en retour, est à certains égards pire que pas de PTR du tout.

C’est exactement ainsi que ce contrôle le note :

Confirmé en avant (FCrDNS) : l’IP nomme un host, et ce host repointe vers la même IP. Note maximale — c’est la configuration correcte, et c’est ce à quoi les destinataires font confiance.
Le badge existe mais ne se confirme pas : il y a un enregistrement PTR, mais le nom ne se résout pas vers l’IP du serveur de messagerie. Crédit partiel seulement — cela a l’air configuré mais les grands filtres ne lui font pas pleinement confiance.
Aucun badge du tout : pas d’enregistrement PTR sur l’IP du serveur de messagerie. Aucun crédit, et le coût en délivrabilité est réel.

Une note sur le poids : dans la méthodologie, c’est un contrôle de sécurité e-mail noté (valant 25 points, un item de priorité P2). Ce n’est pas le contrôle e-mail le plus lourd — ce sont SPF et DMARC, qui stoppent l’usurpation pure et simple — mais c’est une part authentique et notée de votre standing e-mail, et l’un des rares qui dépend de votre fournisseur faisant bien quelque chose plutôt que de vous. Si vous n’envoyez qu’à travers Google Workspace ou Microsoft 365, vous le réussissez presque certainement déjà ; les entreprises qui échouent sont celles qui envoient via leur propre serveur ou un serveur tiers.

À quoi ressemble le « bon » réglage : l’IP de votre serveur de messagerie principal a un enregistrement PTR pointant vers un vrai nom d’hôte que vous possédez, et ce nom d’hôte se résout directement vers la même IP — les deux sens concordent (FCrDNS confirmé).

Comment corriger (gratuit, ~10 minutes du temps de quelqu’un)

Transmettez cette section au propriétaire de l’adresse IP de votre serveur de messagerie — généralement votre fournisseur de messagerie ou d’hébergement, ou votre centre de données pour une machine auto-hébergée — et notez que la correction est gratuite. C’est le seul réglage e-mail que vous ne pouvez presque certainement pas modifier vous-même dans votre panneau DNS habituel, car le DNS inversé est contrôlé par le propriétaire de l’IP, et non par le propriétaire du domaine. Nous facturons uniquement la surveillance du maintien de la configuration, jamais la modification.

Étape 1 — Trouvez l’IP du serveur de messagerie d’envoi. Identifiez le host MX principal du domaine (le serveur de messagerie au numéro de priorité le plus bas) et résolvez-le vers son adresse IP :

dig MX votreentreprise.com        # trouver le host MX principal (priorité la plus basse)
dig A mail.votreentreprise.com    # résoudre ce host vers son IP

C’est cette IP-là qui a besoin du badge. N’utilisez pas l’IP du site web — c’est une machine différente, souvent derrière un CDN qui ne concordera jamais.

Étape 2 — Demandez au propriétaire de l’IP de définir l’enregistrement PTR. Le DNS inversé relève du propriétaire du bloc d’IP, la demande va donc à :

Google Workspace / Gmail : géré automatiquement pour les serveurs de messagerie de Google — si un domaine n’envoyant qu’à travers Google apparaît malgré tout en échec, signalez-le au support Google. (En pratique, ces domaines réussissent.)
Microsoft 365 : de même, géré automatiquement pour les serveurs de Microsoft.
Un serveur de messagerie auto-hébergé ou VPS : ouvrez un ticket auprès de votre fournisseur d’hébergement ou de votre centre de données en leur demandant de définir le PTR (DNS inversé) de votre IP vers le nom d’hôte de votre messagerie. La plupart des fournisseurs l’exposent dans leur panneau de contrôle sous « Reverse DNS », « rDNS » ou « PTR ». Sur les grands clouds, c’est un réglage à un seul champ (par ex. AWS exige un court formulaire de demande pour activer le rDNS sur une Elastic IP ; la plupart des hébergeurs VPS vous laissent le définir instantanément).
Une application d’envoi tierce (outil d’infolettre / facturation / CRM) : si elle envoie depuis ses propres serveurs partagés, le fournisseur gère le DNS inversé — vous n’avez rien à définir, et vous pouvez ignorer cela pour ce trafic. Si elle envoie depuis une IP dédiée que vous leur avez achetée, demandez-leur d’y définir le PTR.

Indiquez-leur l’enregistrement souhaité, par exemple : 203.0.113.10 → mail.votreentreprise.com.

Étape 3 — Rendez-le confirmé en avant (c’est l’étape que la plupart des gens manquent). Le nom d’hôte du PTR doit aussi se résoudre en retour vers la même IP via un enregistrement A normal que vous contrôlez dans votre propre DNS. Donc :

Le PTR dit 203.0.113.10 → mail.votreentreprise.com (votre fournisseur le définit).
L’enregistrement A dit mail.votreentreprise.com → 203.0.113.10 (vous le définissez dans votre DNS, par ex. Cloudflare → DNS → ajoutez un enregistrement A, Name mail, content 203.0.113.10).

Les deux sens doivent pointer l’un vers l’autre. C’est seulement alors que c’est confirmé en avant et pleinement digne de confiance.

Étape 4 — Recontrôlez votre domaine. Confirmez que le serveur de messagerie affiche désormais un DNS inversé confirmé en avant et que le contrôle réussit. Les modifications DNS se propagent en quelques minutes à quelques heures.

Erreurs fréquentes

Mettre le badge sur l’IP du site web au lieu de celle du serveur de messagerie. Le DNS inversé pour l’e-mail concerne le serveur MX. Poser un PTR sur l’adresse de votre site / CDN ne fait rien pour la délivrabilité — c’est la mauvaise machine qui reçoit le badge.
S’arrêter à « le PTR existe ». Un nom à lui seul ne rapporte qu’une confiance partielle. S’il ne se résout pas en retour vers la même IP, les filtres stricts (Gmail, M365, Yahoo) ne lui feront pas pleinement confiance. Complétez toujours la confirmation en avant (Étape 3).
Oublier l’enregistrement A après que le fournisseur a défini le PTR. Le fournisseur définit la moitié inversée ; vous devez définir la moitié en avant dans votre propre DNS. Les gens font l’une et croient avoir terminé.
Demander à la mauvaise partie. Envoyer la demande à votre bureau d’enregistrement ou hébergeur DNS au lieu du propriétaire de l’IP vous vaut un « nous ne pouvons pas faire ça » — parce qu’ils ne le peuvent réellement pas. Cela doit aller au propriétaire de l’IP.
Noms d’hôte génériques de fournisseur. Un PTR comme host-203-0-113-10.unfai.net existe techniquement mais ne fait rien pour votre marque ni votre confiance. Utilisez un vrai nom d’hôte sur votre propre domaine qui se confirme en avant.

Où cela s’inscrit

Le DNS inversé est l’identité du serveur ; SPF, DKIM et DMARC sont la couche d’autorisation et d’anti-usurpation du domaine. Ils répondent à des questions différentes, et les grands fournisseurs les vérifient tous. SPF liste quels services peuvent envoyer en votre nom ; DKIM signe cryptographiquement vos messages pour qu’ils ne puissent pas être falsifiés ; DMARC relie les deux et dit aux destinataires quoi faire des e-mails en échec — et protège le nom d’expéditeur visible que voient réellement vos clients. Le DNS inversé se situe sous tout cela, garantissant que la machine qui envoie est bien, d’abord, un vrai serveur de messagerie nommé. Réglez correctement SPF, DKIM et DMARC pour la défense la plus forte contre l’usurpation ; réglez correctement le DNS inversé pour qu’un serveur d’envoi neuf ou auto-hébergé ne soit pas discrètement boudé avant que le reste n’ait même sa chance. Chacune de ces corrections est gratuite.

FAQ

Je ne suis pas technique — puis-je m'en occuper moi-même ?

Généralement non, et c'est normal. Contrairement à la plupart des réglages e-mail, celui-ci ne se modifie pas dans le DNS de votre propre domaine — il est défini par le propriétaire de l'adresse Internet (l'IP) de votre serveur de messagerie, c'est-à-dire votre fournisseur de messagerie ou d'hébergement. Votre rôle se résume à leur transmettre la section « Comment corriger ». C'est une modification rapide de leur côté, et c'est gratuit.

Si j'utilise Google Workspace ou Microsoft 365, suis-je déjà couvert ?

Presque certainement oui — tous deux gèrent automatiquement le DNS inversé pour leurs propres serveurs de messagerie, donc un domaine qui n'envoie qu'à travers eux réussit ce contrôle sans rien faire de votre part. Si notre contrôle le signale quand même, cela veut presque toujours dire qu'une partie de vos e-mails sort par un serveur différent (votre propre machine, un VPS bon marché, ou une application d'envoi tierce), et que c'est ce serveur-là qui n'a pas son badge. La section de correction explique qui contacter.

Corriger cela pourrait-il casser ma messagerie ?

Non. Cela ne fait qu'ajouter ou corriger l'enregistrement d'identité du serveur d'envoi — cela ne change pas où vont vos e-mails, ni qui est autorisé à les envoyer, ni aucun de vos réglages de boîte de réception. Cela rend simplement les e-mails que vous envoyez déjà plus susceptibles d'être jugés fiables et distribués.

Quelle est la différence entre cela et SPF, DKIM et DMARC ?

Ces trois-là répondent à « ce domaine est-il autorisé à envoyer ce message ? » Le DNS inversé répond à une question différente et plus précoce : « la machine qui envoie est-elle un vrai serveur de messagerie identifiable, ou une machine anonyme ? » Les grands fournisseurs vérifient les deux. Vous voulez que tous soient corrects — mais le DNS inversé est celui qui détecte un serveur d'envoi flambant neuf ou auto-hébergé avant même que SPF et DKIM n'entrent en jeu.

Nous avons un enregistrement DNS inversé mais le contrôle ne réussit toujours pas pleinement — pourquoi ?

Parce qu'avoir un nom ne suffit pas ; le nom doit se vérifier dans les deux sens. Le badge dit que le serveur s'appelle, mettons, mail.votreentreprise.com — mais Gmail recherche ensuite ce nom et s'attend à ce qu'il pointe directement vers la même IP. Si ce n'est pas le cas (ou s'il pointe ailleurs), les fournisseurs le traitent comme non confirmé et ne lui font qu'à moitié confiance. Cette concordance bidirectionnelle s'appelle le DNS inversé confirmé en avant (forward-confirmed reverse DNS), et c'est la partie que la plupart des configurations manquent.

La correction est-elle vraiment gratuite, ou est-ce une vente additionnelle payante ?

La correction est toujours gratuite — c'est une petite modification de configuration effectuée par votre fournisseur, pas un produit que vous achetez. Quiconque vous dit que mettre en place le DNS inversé nécessite un forfait payant se trompe. Nous facturons uniquement la surveillance du maintien de cette configuration dans le temps, jamais la modification.