Comment corriger l'erreur « Le DNS inversé ne correspond pas à la bannière SMTP »

Points clés à retenir

Le DNS inversé (enregistrements PTR) doit correspondre au nom d'hôte utilisé dans votre bannière SMTP (HELO/EHLO).
Une incompatibilité entre les enregistrements PTR et les bannières SMTP déclenche les filtres anti-spam et réduit le placement dans la boîte de réception.
La plupart des fournisseurs de messagerie électronique exigent le DNS inversé confirmé par transfert (FCrDNS) pour garantir la fiabilité.
Le nom d'hôte de votre serveur de messagerie doit être un nom de domaine complet (FQDN).
La bannière SMTP, l'enregistrement PTR et l'enregistrement A doivent tous pointer vers la même adresse IP.
Les fournisseurs de VPS cloud attribuent souvent des enregistrements PTR par défaut qui doivent être mis à jour manuellement.
Les problèmes liés au DNS inversé peuvent entraîner un ralentissement ou un rejet avant l'évaluation du DMARC.
Un alignement rDNS correct renforce l'efficacité des protocoles SPF, DKIM et DMARC.
Des audits réguliers permettent d'éviter les échecs silencieux de délivrabilité causés par la dérive DNS.

Si vous gérez votre propre serveur de messagerie, vous rencontrerez probablement l'erreur « Reverse DNS does not match the SMTP banner » (Le DNS inversé ne correspond pas à la bannière SMTP) lors d'un test de délivrabilité des e-mails. Cet avertissement n'est pas anodin. L'ignorer nuit directement à la confiance accordée à vos e-mails, augmente le filtrage des spams et peut amener les principaux fournisseurs tels que Gmail et Outlook à rejeter entièrement vos messages.

Le DNS inversé agit comme la carte d'identité de votre serveur, tandis que la bannière SMTP agit comme sa poignée de main. Lorsque ces deux identifiants ne correspondent pas, les serveurs destinataires traitent votre courrier comme suspect. Cette incompatibilité est le signe d'une mauvaise hygiène du serveur et est une caractéristique courante des infrastructures de spam.

« Le DNS inversé ne correspond pas à la bannière SMTP » signifie que le nom d'hôte lié à votre adresse IP d'envoi (DNS inversé ou enregistrement PTR) ne correspond pas au nom d'hôte que votre serveur de messagerie annonce dans son message d'accueil SMTP (HELO/EHLO). Lorsque ces deux éléments ne correspondent pas, les serveurs de messagerie destinataires considèrent la connexion comme non fiable et peuvent signaler ou bloquer vos e-mails.
Considérez cela comme un processus de vérification entre deux serveurs.

DNS inversé

Le DNS standard transforme un nom de domaine en adresse IP. Le DNS inversé fait l'inverse : il examine une adresse IP et demande « Quel nom est associé à cette adresse ? ». C'est un enregistrement PTR qui s'en charge.

Lorsque votre serveur établit une connexion avec un autre serveur, il se présente à l'aide d'un message d'accueil appelé bannière SMTP. Ce message d'accueil comprend un nom d'hôte (par exemple, mail.example.com).

La comparaison

Lorsque votre e-mail arrive, le serveur destinataire examine votre adresse IP et vérifie l'enregistrement PTR. Si l'enregistrement PTR indique server1.isp-provider.net mais que votre bannière SMTP indique mail.votredomaine.com, il y a une incompatibilité.

Un exemple rapide :

Adresse IP : 1.2.3.4
Bannière SMTP : mail.business.com
Enregistrement PTR (DNS inversé) : 1-2-3-4.dynamic.cloudhost.com
Résultat : Erreur ! Les identités ne correspondent pas.

Composant	Exemple (Réussite)	Exemple (échec)
Adresse IP	1.2.3.4	1.2.3.4
Enregistrement PTR	mail.exemple.com	hôte-1-2-3-4.isp.net
Bannière SMTP	mail.exemple.com	mail.exemple.com
Un dossier	mail.exemple.com → 1.2.3.4	mail.exemple.com → 1.2.3.4
Résultat	MATCH / CONFIANCE	INADÉQUATION / SPAM

Pourquoi cette erreur est importante pour la délivrabilité des e-mails

Les serveurs de réception utilisent ce contrôle comme un moyen rapide de repérer les spammeurs.

1. Déclencheurs du filtre anti-spam

Les spammeurs utilisent souvent des serveurs non configurés ou des botnets. Un nom d'hôte générique ou incompatible est l'un des premiers éléments signalés par un filtre anti-spam.

2. Réputation et confiance

Les grands FAI donnent la priorité au DNS inversé confirmé à l'avance. Cela signifie que votre adresse IP pointe vers un nom, et que ce nom pointe vers la même adresse IP. Si vous ne disposez pas de cette fonctionnalité, votre « score de confiance » chute.

3. Signaux d'authentification

Bien que techniquement distincts du SPF, DKIM et DMARC, le rDNS fait partie intégrante de la « vision globale » de la santé du serveur. Si votre connexion de base est désordonnée, votre politique DMARC pourrait ne pas suffire à sauver votre réputation.

Causes courantes du décalage

Voici quelques causes courantes de non-correspondance.

Noms d'hôte cloud par défaut

Vous utilisez un VPS et n'avez pas modifié l'enregistrement PTR par défaut attribué par le fournisseur.

Oublier la configuration MTA

Vous avez mis à jour vos enregistrements DNS, mais vous avez oublié de mettre à jour les paramètres réels dans votre logiciel de messagerie.

Hébergement mutualisé

Vous utilisez une adresse IP partagée pour laquelle le fournisseur a défini le PTR sur son propre domaine principal, et non sur le vôtre.

Problèmes liés à la propriété intellectuelle

Vous n'avez pas l'autorisation de modifier l'enregistrement PTR car l'adresse IP est gérée par un FAI qui ne vous a pas délégué le contrôle.

Comment vérifier vos valeurs actuelles

Avant de commencer à modifier les paramètres, vous devez voir ce que le reste du monde voit.

1. Vérifiez l'enregistrement PTR.

Exécutez une commande rapide dans le terminal pour voir quel nom d'hôte est associé à votre adresse IP :

Mac/Linux : dig -x [Votre_adresse_IP]
Windows : nslookup [Votre_adresse_IP]

Utilisez Telnet ou OpenSSL pour voir comment votre serveur accueille les autres. La première ligne de la réponse affichera le nom d'hôte de votre bannière SMTP.

3. Utilisez un outil centralisé

Une vérification manuelle est tout à fait acceptable, mais des outils tels que la recherche d'enregistrements DNS de PowerDMARC peuvent vous montrer à quoi ressemblent vos enregistrements PTR et A à l'échelle mondiale afin de vous assurer qu'il n'y a pas de « décalage DNS » qui vous donnerait de faux résultats.

Voici quelques mesures importantes à prendre pour corriger l'erreur.

Étape 1 : Identifiez l'adresse IP d'envoi

Vérifiez l'adresse IP publique exacte utilisée par votre serveur de messagerie pour envoyer des e-mails. Si vous êtes derrière un pare-feu, un NAT ou un proxy, elle peut être différente de l'adresse IP de votre serveur local.

Étape 2 : Corrigez l'enregistrement PTR

C'est la partie qui pose le plus de problèmes à la plupart des gens. En général, vous ne pouvez pas modifier cela dans le panneau DNS de votre domaine. Vous devez passer par la société qui détient l'adresse IP.

Cloud VPS : accédez au tableau de bord de votre fournisseur (section Réseau/IP statique) et recherchez « DNS inversé » ou « PTR ».
Dédié/sur site : vous devrez peut-être ouvrir un ticket d'assistance auprès de votre FAI.
Objectif : définir le PTR sur un nom de domaine complet.

Maintenant, assurez-vous que votre serveur connaît son nom. De nombreux serveurs de messagerie utilisent un modèle de bannière par défaut pour le message d'accueil SMTP. Vous devez donc configurer votre agent de transfert de courrier pour qu'il annonce le même nom de domaine complet que celui que vous avez défini à l'étape 2.

Postfix : Modifiez le fichier /etc/postfix/main.cf et mettez à jour myhostname = mail.example.com.
Exim : mettez à jour le nom d'hôte principal (primary_hostname) dans votre fichier de configuration.
Redémarrez le service après avoir effectué les modifications !

Étape 4 : Vérifiez que le DNS direct correspond

Le nom d'hôte que vous avez utilisé aux étapes 2 et 3 doit également avoir un enregistrement A renvoyant à votre adresse IP. Lorsque le PTR pointe vers le nom et que le nom pointe vers l'IP, vous obtenez un DNS inversé confirmé en avant (FCrDNS).

Meilleures pratiques pour éviter les erreurs DNS inversées

Suivez ces pratiques pour éviter les erreurs DNS inversées.

Une adresse IP par nom d'hôte

Si possible, veillez à ce que la convention de nommage de vos adresses électroniques soit cohérente (par exemple, mail1.domain.com).

Évitez les noms génériques

Ne laissez jamais votre rDNS tel quel : static.123.45.clients.provider.com.

Audits réguliers

Utilisez des outils automatisés pour surveiller votre infrastructure. PowerDMARC, par exemple, offre une surveillance en temps réel qui peut vous alerter si vos enregistrements ne sont plus alignés ou si votre IP se retrouve sur une liste noire.

Aligner avec l'authentification

Assurez-vous que votre nom d'hôte DNS inversé est inclus dans votre SPF afin d'éviter les échecs « soft ».

Comment cette erreur est liée au DMARC et à l'authentification des e-mails

Alors que DMARC se concentre sur l'intégrité du message, le DNS inversé et la bannière SMTP se concentrent sur l'intégrité de la connexion. Considérez cela comme deux couches de sécurité : l'une pour le colis et l'autre pour le camion de livraison.
Voici comment une incompatibilité peut compromettre votre stratégie d'authentification globale :

Priorité de l'évaluation

La plupart des serveurs destinataires effectuent une vérification « handshake » avant même de consulter vos enregistrements DMARC ou DKIM. Si votre rDNS et votre bannière ne correspondent pas, votre e-mail pourrait être ralenti ou rejeté au niveau de la passerelle avant même que votre politique DMARC « Reject » ait la possibilité de prouver la légitimité du message.

Le signal « professionnalisme »

Les filtres de sécurité utilisent l'alignement rDNS comme indicateur de l'état de santé du serveur. Une incompatibilité suggère un serveur mal configuré ou piraté, typique des botnets, ce qui peut entraîner une baisse de la note de réputation, quelle que soit la qualité de vos SPF .

Conformité FCrDNS

Les principaux FAI exigent souvent un DNS inversé confirmé comme base de confiance. Si votre bannière SMTP n'est pas synchronisée avec vos enregistrements PTR et A, vous échouerez à cette vérification, ce qui rendra vos e-mails conformes à la norme DMARC suspects.

Échecs invisibles

Sans une plateforme telle que PowerDMARC, ces lacunes infrastructurelles passent souvent inaperçues. Si les vérifications DNS standard peuvent indiquer que vos enregistrements sont « actifs », elles ne vous indiquent pas toujours comment la passerelle du destinataire interprète l'incohérence entre votre bannière et votre adresse IP.

Comment PowerDMARC automatise l'alignement rDNS et SMTP

La vérification manuelle des commandes du terminal et la connexion à divers tableaux de bord VPS peuvent prendre beaucoup de temps et être sources d'erreurs humaines. PowerDMARC fournit une suite centralisée d'outils conçus pour garantir que la « poignée de main » de votre serveur est toujours valide et reconnue par les FAI mondiaux.

1. Validation PTR et FCrDNS en temps réel

Notre outil de recherche d'enregistrements DNS va au-delà des vérifications de base. Il vérifie FCrDNS en contrôlant simultanément votre enregistrement PTR et en s'assurant que le nom d'hôte résultant renvoie à votre adresse IP d'envoi. Cela vous aide à identifier les configurations « à moitié configurées » où un PTR existe mais n'est pas correctement aligné avec un enregistrement A.

2. Surveillance proactive et alertes

Des dérives DNS peuvent se produire, les fournisseurs de services cloud réinitialisent parfois les enregistrements ou les plages d'adresses IP sont remappées. Les services de surveillance de la réputation surveillent votre infrastructure 24 h/24, 7 j/7. Si votre alignement rDNS est rompu ou si l'adresse IP de votre serveur apparaît soudainement sur une liste noire en raison d'une erreur de configuration, vous recevrez une alerte avant que vos taux de délivrabilité ne commencent à baisser.

3. Tableau de bord holistique de la délivrabilité

Alors que rDNS gère la couche de connexion, PowerDMARC relie ces données à vos performances SPF, DKIM et DMARC. En consultant vos rapports RUA agrégés, vous pouvez voir si certaines adresses IP sont confrontées à des taux de rejet élevés de la part de Gmail ou Outlook, ce qui vous aide à remonter à l'origine des problèmes de délivrabilité jusqu'aux bannières SMTP incompatibles.

Liste de contrôle finale

L'enregistrement PTR correspond à la bannière SMTP.
La bannière SMTP correspond au DNS direct (enregistrement A).
La réputation IP est bonne (pas sur les listes noires).
SPF, DKIM et DMARC sont entièrement configurés et alignés.

Résumé

En fin de compte, l'e-mail est une question de confiance. Si votre adresse IP et votre message d'accueil ne correspondent pas, vous aurez du mal à atteindre la boîte de réception. Aligner vos enregistrements n'est pas seulement une « bonne pratique », c'est une nécessité si vous voulez que vos e-mails soient réellement lus.
Les erreurs d'infrastructure de ce type peuvent être difficiles à détecter. PowerDMARC vous facilite la tâche en surveillant votre configuration et en vous fournissant des rapports clairs sur ce qui fonctionne et ce qui ne fonctionne pas. Il détecte ces lacunes de configuration avant qu'elles ne se transforment en cauchemar en matière de délivrabilité.
Essayez gratuitement PowerDMARC et voyez exactement comment vos serveurs sont perçus par le reste du monde.

Foire aux questions

Puis-je corriger un enregistrement PTR dans mon registraire de domaine ?
Non. Les enregistrements PTR sont liés à l'adresse IP. Vous devez contacter votre hébergeur ou votre FAI.
Le DMARC échouera-t-il à cause de cela ?
Pas nécessairement, mais vous pourriez tout de même être bloqué. De nombreux filtres vérifient la bannière « handshake » avant même de consulter vos enregistrements DMARC.
Pourquoi l'erreur persiste-t-elle après que je l'ai corrigée ?
Propagation DNS. La propagation des nouveaux enregistrements sur Internet peut prendre jusqu'à 24 heures.
Que faire si j'ai plusieurs domaines sur une seule adresse IP ?
Pas d'inquiétude, c'est très courant. Vous n'avez pas besoin d'une bannière différente pour chaque domaine. Choisissez simplement un nom « principal » pour votre serveur et assurez-vous que votre PTR, votre bannière SMTP et votre enregistrement A pointent tous vers ce nom. Tant qu'ils correspondent les uns aux autres, les autres domaines qui envoient depuis cette adresse IP fonctionneront correctement.

À propos de
Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des courriels chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)