DNS inversé (PTR) : pourquoi vos e-mails souffrent et comment corriger correctement le rDNS

Ce qu’est réellement le DNS inversé (PTR) — et ce que ce n’est pas

Le DNS répond généralement à la question : « Quelle IP correspond à ce nom ? » C’est une recherche directe (A pour IPv4, AAAA pour IPv6).
Le DNS inversé répond à une question différente : « Quel nom correspond à cette IP ? » C’est un enregistrement PTR.

Les enregistrements PTR vivent dans des zones inverses spécialisées :
in-addr.arpa pour IPv4 et ip6.arpa pour IPv6.
Une adresse IPv4 comme 203.0.113.45 devient un nom inverse comme
45.113.0.203.in-addr.arpa. Le propriétaire de la zone définit un enregistrement PTR pointant vers un nom d’hôte, par exemple
mail01.example.com.

Voici ce que PTR n’est pas :

• Ce n’est pas une authentification. Un PTR ne prouve pas que vous possédez un domaine. Il prouve que celui qui contrôle la zone inverse a fait une déclaration.
• Ce n’est pas un chiffrement. Il ne protège pas le mail en transit. C’est le rôle de TLS, MTA-STS et autres.
• Ce n’est pas optionnel si vous voulez une délivrabilité cohérente. Le SMTP fonctionne techniquement sans rDNS ; les filtres modernes supposent que vous mentez si vous l’omettez.

La réalité gênante : l’entité qui contrôle le rDNS est généralement votre fournisseur d’accès ou cloud, car ils gèrent l’allocation IP et la délégation DNS inverse.
Cela signifie que vous ne pouvez pas « simplement ajouter un PTR dans Cloudflare. » Vous pouvez ajouter des enregistrements directs pour votre domaine là-bas. Le PTR est lié à la zone inverse de l’IP.

Pourquoi les systèmes de messagerie tiennent tant au PTR

Le courrier est un jeu de confiance fédérée joué par des machines qui ont été trompées pendant des décennies. Si vous exploitez un serveur récepteur, vous êtes bombardé par :
credential stuffing, botnets, hôtes WordPress compromis, « plateformes marketing » qui se comportent comme des malwares, et des entreprises parfaitement légitimes mais avec une hygiène catastrophique.

Les récepteurs utilisent donc des heuristiques peu coûteuses. Le PTR est l’une des moins chères :
une requête DNS, une chaîne, un jugement rapide. Ce n’est pas la porte unique, mais c’est un signal fort dans la pile de scoring anti‑spam.

Ce que les récepteurs déduisent du rDNS

• Cette IP est‑elle « destinée » à envoyer du mail ? Beaucoup de plages résidentielles et dynamiques ont des PTR comme cpe-, dsl-, dynamic-. C’est un fort « non ».
• L’expéditeur se comporte‑t‑il comme un MTA stable ? Les vrais MTA ont des noms stables et un mappage direct/inverse cohérent. Les botnets s’en fichent.
• La chaîne HELO/EHLO paraît‑elle sensée ? De nombreux récepteurs comparent la salutation SMTP au nom PTR, ou au moins vérifient qu’il s’agit d’un nom résoluble.
• L’expéditeur essaie‑t‑il trop d’optimisations ? Les astuces de nommage trop « optimisées » peuvent se retourner contre vous. Plus de détails plus bas.

Ce que le rDNS casse souvent

• Bloquages stricts par des récepteurs sévères (certains gateways d’entreprise font encore « pas de PTR, pas de mail »).
• Augmentation du score spam qui vous fait franchir la ligne quand d’autres problèmes mineurs existent.
• Douleurs liées au greylisting car votre « identité » n’est pas consistante entre les tentatives.
• Systèmes de réputation qui cataloguent votre plage IP comme dynamique/mal configurée.

Une phrase qui vous fera gagner une semaine : le rDNS concerne l’IP, pas le domaine dans votre en‑tête From:
header. Si votre produit SaaS envoie comme billing@yourbrand.com mais part d’une VM aléatoire dont le PTR est ip-10-0-3-44.internal,
vous donnez aux filtres une bonne raison de vous méfier.

Faits et historique intéressants : le rôle étonnamment durable du PTR

Quelques points de contexte qui importent parce qu’ils expliquent pourquoi les « vieilles choses » continuent de vous poser problème :

1. Le DNS inversé est venu tôt. Le système DNS et la cartographie inverse in-addr.arpa ont été définis dans les années 1980 lors de la standardisation des noms Internet.
2. Le PTR précède l’anti‑spam moderne. Le PTR n’a pas été conçu pour lutter contre le spam ; le spam en a juste fait un signal utile et bon marché.
3. Le SMTP est plus ancien que la plupart des logiques de filtrage. Le comportement de base du SMTP a été spécifié quand l’« identité d’hôte » était majoritairement honnête et que les réseaux étaient plus petits.
4. Beaucoup de gateways d’entreprise exigent encore le « PTR requis. » C’est grossier, mais ça élimine une grande quantité de bruit avec peu de CPU.
5. Le forward‑confirmed reverse DNS (FCrDNS) est devenu une attente de facto. Ce n’est pas exigé strictement par un protocole, mais les filtres le considèrent comme le minimum.
6. L’IPv6 a rendu le DNS inversé plus pénible. La zone inverse est basée sur les nibbles et est longue ; la délégation et la correction sont faciles à foirer.
7. Le cloud a rendu la propriété du rDNS morcelée. Vous pouvez posséder le domaine à un endroit et louer l’IP ailleurs, ce qui crée des angles morts opérationnels.
8. Les grands fournisseurs de boîtes mail documentent rarement le scoring exact. Le rDNS n’est pas « la » clé, mais il fait partie d’une posture plus large : identité stable, comportement cohérent, faibles taux de plaintes.
9. Les schémas PTR dynamiques sont intentionnellement stigmatisés. Beaucoup d’ISP marquent les pools dynamiques dans les PTR pour que les récepteurs puissent les filtrer.

Blague n°1 : Les enregistrements PTR sont comme des badges nominaux à une conférence — optionnels en théorie, suspects en pratique, et toujours manquants quand on en a besoin.

Mode d’urgence : trouver le goulot en quelques minutes

Quand la délivrabilité chute, les équipes aiment débattre SPF vs DKIM vs « peut‑être Microsoft est en panne ». Commencez par ce qu’il est le plus rapide d’invalider.
Voici l’ordre que j’utilise quand je suis de garde et que mon café négocie encore avec mon système circulatoire.

1) Vérifier l’IP d’envoi et son PTR (en premier)

• Trouvez l’IP sortante réellement utilisée (les gateways NAT, load balancers, hôtes relais omettent souvent l’information).
• Vérifiez qu’un enregistrement PTR existe et qu’il ressemble à un hôte mail, pas à un bail DHCP.
• Faites une vérification de confirmation directe : le nom PTR résout de nouveau sur la même IP.

2) Vérifier la bannière SMTP et l’alignement HELO/EHLO (deuxième)

• Assurez‑vous que votre MTA annonce un FQDN stable dans sa bannière et son HELO/EHLO.
• Assurez‑vous que ce FQDN a des enregistrements A/AAAA et est cohérent avec le nom PTR (pas forcément identique, mais pas absurde).

3) Vérifier l’authentification (troisième)

• SPF doit valider pour l’IP d’envoi.
• DKIM doit signer et vérifier pour le domaine From: (ou un domaine aligné).
• La politique DMARC et l’alignement ne doivent pas vous saboter (surtout pour les e‑mails transactionnels).

4) Vérifier la réputation et le comportement de volume (quatrième)

• Si l’IP est nouvelle, attendez‑vous à des exigences de warm‑up.
• Recherchez les pics : rebonds, plaintes, changements soudains de volume, problèmes d’hygiène de listes.

5) Ensuite seulement, creuser le contenu et les modèles (cinquième)

• Le contenu compte, mais si votre posture d’identité est cassée, le meilleur texte du monde ne vous sauvera pas.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des vérifications pragmatiques que vous pouvez exécuter depuis un hôte Linux avec des outils DNS basiques. Chaque tâche inclut : une commande, ce que la sortie signifie, et la décision à prendre.
Remplacez l’IP/le domaine d’exemple par les vôtres.

Task 1: Find the public outbound IP from the host (sanity check)

cr0x@server:~$ curl -4 ifconfig.me
203.0.113.45

Signification : C’est l’adresse IPv4 que voient les services externes. Si vous vous attendiez à autre chose, vous êtes derrière un NAT ou le routage de sortie diffère.

Décision : Utilisez cette IP pour les vérifications PTR/SPF. Si ce n’est pas l’IP du mail, arrêtez et tracez l’egress.

Task 2: Confirm which IP your MTA is actually using (Postfix example)

cr0x@server:~$ postconf -n | egrep '^(smtp_bind_address|smtp_bind_address6|myhostname|myorigin|inet_interfaces) ='
myhostname = mail01.example.com
myorigin = /etc/mailname
inet_interfaces = all

Signification : Pas d’adresse de liaison explicite ; Postfix choisira en fonction du routage. Votre IP d’egress peut être différente de l’IP de l’interface du serveur.

Décision : Si vous avez besoin d’une IP spécifique, définissez smtp_bind_address (ou corrigez le routage/NAT), puis revérifiez ce que le monde voit.

Task 3: Reverse lookup (PTR) for your sending IP

cr0x@server:~$ dig +short -x 203.0.113.45
mail01.example.com.

Signification : Le PTR existe et pointe vers mail01.example.com.

Décision : Poursuivez la confirmation directe. Si rien, vous devez définir le PTR auprès de votre ISP/fournisseur cloud.

Task 4: Check for multiple PTRs (usually a smell)

cr0x@server:~$ dig -x 203.0.113.45 +noall +answer
45.113.0.203.in-addr.arpa. 3600 IN PTR mail01.example.com.

Signification : Exactement un PTR. Plusieurs PTR peuvent embrouiller les filtres et les humains.

Décision : Conservez un PTR stable par IP d’envoi, sauf raison très spécifique et maîtrisée.

Task 5: Forward lookup of the PTR name (A record)

cr0x@server:~$ dig +short A mail01.example.com
203.0.113.45

Signification : Le nom PTR résout de nouveau sur la même IP. C’est le schéma classique « forward‑confirmed reverse DNS » que les récepteurs apprécient.

Décision : Si l’enregistrement A pointe ailleurs, corrigez votre DNS (ou ajustez le PTR pour refléter la réalité).

Task 6: Check IPv6 rDNS too (even if you “mostly use IPv4”)

cr0x@server:~$ dig +short -x 2001:db8:abcd:10::25
mail01.example.com.

Signification : Votre IPv6 a aussi un PTR. Bien. Si votre serveur peut envoyer en IPv6, certains destinataires le verront.

Décision : Si absent, soit définissez le PTR IPv6, soit désactivez l’envoi SMTP en IPv6 jusqu’à correction.

Task 7: Verify the SMTP banner and EHLO name from the outside

cr0x@server:~$ nc -v mail01.example.com 25
Connection to mail01.example.com 25 port [tcp/smtp] succeeded!
220 mail01.example.com ESMTP Postfix

Signification : La bannière utilise un FQDN approprié. Si elle affiche localhost ou un nom interne, vous paraissez amateur aux yeux des filtres.

Décision : Définissez correctement myhostname et assurez‑vous qu’il se résout en DNS public.

Task 8: Confirm the server’s HELO/EHLO string during a test session

cr0x@server:~$ printf "EHLO test.example.net\r\nQUIT\r\n" | nc -w 3 mail01.example.com 25
220 mail01.example.com ESMTP Postfix
250-mail01.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

Signification : Le serveur répond avec son identité. Beaucoup de récepteurs comparent ce que vous déclarez en EHLO avec le PTR/la bannière.

Décision : Si l’identité EHLO est étrange, corrigez la configuration du MTA avant de chasser des problèmes SPF fantômes.

Task 9: Check SPF for the From: domain (does it authorize the sending IP?)

cr0x@server:~$ dig +short TXT example.com | sed -n 's/"//g;/^v=spf1/p'
v=spf1 ip4:203.0.113.45 -all

Signification : SPF autorise explicitement l’IP et interdit les autres. Idéal pour du mail transactionnel depuis un hôte unique.

Décision : Si SPF manque ou est trop strict pour votre chemin d’envoi réel, corrigez‑le. Le PTR ne compensera pas un SPF échoué.

Task 10: Check if your IP is in a “dynamic” reverse naming scheme (pattern recognition)

cr0x@server:~$ dig +short -x 198.51.100.77
cpe-198-51-100-77.isp.example.

Signification : Le PTR crie « connexion résidentielle ». Vous pouvez exécuter un MTA depuis là, mais beaucoup de destinataires vous traiteront comme un botnet.

Décision : Déplacez l’envoi sortant vers une IP statique/business appropriée ou vers un relais réputé. Ne combattez pas la physique.

Task 11: Validate that the reverse zone is reachable and not SERVFAIL-ing

cr0x@server:~$ dig -x 203.0.113.45 +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> -x 203.0.113.45 +time=2 +tries=1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
45.113.0.203.in-addr.arpa. 3600 IN PTR mail01.example.com.

;; Query time: 26 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 96

Signification : NOERROR et une réponse. Si vous voyez SERVFAIL, vous avez probablement une délégation cassée ou des serveurs de noms « lame » pour la zone inverse.

Décision : Escaladez auprès du propriétaire/fournisseur IP ; ce n’est pas un problème de configuration MTA.

Task 12: Inspect a bounce for rDNS/PTR clues (don’t guess; read)

cr0x@server:~$ grep -iE 'ptr|reverse|rdns|helo|host name|554|550' /var/log/mail.log | tail -n 6
Dec 31 12:01:12 mail01 postfix/smtp[22145]: host mx.receiver.example[192.0.2.10] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)
Dec 31 12:01:12 mail01 postfix/smtp[22145]: to=<user@receiver.example>, relay=mx.receiver.example[192.0.2.10]:25, delay=0.6, delays=0.1/0/0.2/0.3, dsn=5.7.1, status=bounced (host mx.receiver.example[192.0.2.10] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command))

Signification : Le récepteur vous a explicitement rejeté pour absence de rDNS. C’est l’erreur la plus claire que vous puissiez obtenir en matière d’e‑mail.

Décision : Corrigez le PTR et vérifiez ; réenfilez le mail après correction.

Task 13: Confirm outbound connections use the IP you think they do

cr0x@server:~$ sudo ss -ntp | awk '$4 ~ /:25$/ {print $4, $5}' | head
203.0.113.45:54322 192.0.2.10:25
203.0.113.45:54324 192.0.2.11:25

Signification : L’IP source est 203.0.113.45 pour le SMTP sortant. Bien : c’est l’IP que vous avez vérifiée.

Décision : Si vous voyez une autre IP source, vous avez débogué la mauvaise adresse. Corrigez le routage/NAT ou les paramètres de liaison du MTA.

Task 14: Confirm your resolver isn’t lying (query a public resolver)

cr0x@server:~$ dig +short -x 203.0.113.45 @1.1.1.1
mail01.example.com.

Signification : Un résolveur public est d’accord. Si votre résolveur local montre autre chose, vous pourriez avoir du cache ou un split‑horizon DNS.

Décision : Utilisez la résolution externe comme source de vérité pour la délivrabilité. Votre cache local ne reçoit pas le courrier pour le monde.

Blague n°2 : Rien ne dit « faites‑moi confiance » comme un serveur de mail dont le DNS inversé est ubuntu. C’est fondamentalement porter une fausse moustache à une banque.

Corriger le rDNS correctement : les parties ennuyeuses qui comptent

Corriger le PTR est simple en concept et pénible en exécution parce que le plan de contrôle est souvent hors de votre fournisseur DNS.
La bonne correction est moins « DNS astucieux » et plus « clarifier la propriété et le nommage. »

Step 1: Decide what the PTR should be

Choisissez un nom d’hôte qui :

• Est un nom de domaine pleinement qualifié que vous contrôlez (ex. mail01.example.com).
• Est stable dans le temps (pas lié à des instances d’autoscaling à moins que vous le gériez volontairement).
• Possède un enregistrement A correspondant (et AAAA si vous utilisez IPv6).
• Ne fait pas semblant d’être le domaine du destinataire ou une autre marque. Les filtres n’aiment pas le cosplay.

Step 2: Create forward DNS first (A/AAAA)

Beaucoup de fournisseurs n’accepteront pas une valeur PTR qui ne résout pas. Même quand ils le font, vous voulez la confirmation directe.
Créez :

• mail01.example.com A 203.0.113.45
• mail01.example.com AAAA 2001:db8:abcd:10::25 (si pertinent)

Step 3: Set the PTR with whoever owns the IP space

C’est la partie que les gens ratent. Les enregistrements PTR ne sont généralement pas définis dans la zone de votre domaine.
Vous les définissez :

• Dans la console de votre fournisseur cloud (pour les IP publiques/elastic), ou
• Via un ticket/email à votre ISP / fournisseur d’hébergement, ou
• Par délégation de zone inverse si vous contrôlez un bloc IP suffisamment grand (rare, mais courant dans les grandes entreprises).

Step 4: Wait for propagation, then verify externally

Les changements de PTR se propagent comme tout changement DNS : les caches respectent les TTL, et certains résolveurs gardent des données obsolètes plus longtemps qu’ils ne devraient.
Vérifiez depuis plusieurs réseaux/résolveurs. Votre portable sur le VPN du bureau n’est pas un oracle fiable.

Step 5: Align the MTA identity with reality

Pour Postfix, les bases sont :

• myhostname doit être le FQDN public (souvent le nom PTR).
• smtpd_banner ne doit pas exposer de déchets, mais doit rester cohérent.
• Votre serveur doit utiliser ce nom dans HELO/EHLO, soit par défaut soit explicitement.

Pour d’autres MTA (Exim, Sendmail, Exchange), le principe est le même : le nom présenté pendant le SMTP doit se résoudre et ne pas contredire le PTR.

Step 6: Don’t forget the network edge

Si vous envoyez via :

• Gateways NAT (courants dans les VPC cloud), votre IP d’envoi est celle du NAT public, pas celle de l’instance.
• Relais sortants / smart hosts, l’IP et le rDNS du relais importent plus que les vôtres.
• Load balancers (rare pour SMTP, mais ça arrive), assurez‑vous que l’identité backend ne fuit pas ou ne se désaccorde pas.

Le rDNS n’est pas un paramètre « on le définit une fois » quand votre routage change chaque mois.
Intégrez‑le dans la gestion des changements pour l’egress réseau, pas dans la mémoire tribale.

Alignement : PTR, A/AAAA, HELO/EHLO, SPF, DKIM, DMARC

Les échecs de délivrabilité aiment la compagnie. Le PTR est rarement le seul souci, mais il est souvent la première raison facile de se méfier.
L’objectif n’est pas « alignement parfait » comme à un examen de conformité ; l’objectif est « pas de contradictions évidentes ».

Les règles d’alignement qui comptent en pratique

• PTR ↔ A/AAAA : Le nom PTR doit résoudre de nouveau sur la même IP d’envoi. C’est la vérification FCrDNS.
• HELO/EHLO ↔ DNS : Le nom HELO doit être un FQDN résoluble avec A/AAAA. Évitez les IP brutes dans HELO à moins d’aimer être filtré.
• SPF ↔ IP d’envoi : L’IP qui se connecte au récepteur doit être autorisée par SPF pour le domaine envelope‑from (ou le domaine HELO, selon la logique du récepteur).
• DKIM ↔ domaine du message : DKIM doit signer avec un domaine aligné au From: visible pour que DMARC réussisse.
• DMARC ↔ politique : DMARC n’utilise pas PTR, mais des échecs DMARC + rDNS faible forment souvent un coup dur.

À quoi ressemble du « bon »

Une configuration propre et ennuyeuse pour du mail transactionnel :

• IP sortante : 203.0.113.45
• PTR : mail01.example.com
• Enregistrement A : mail01.example.com → 203.0.113.45
• Bannière SMTP/HELO : mail01.example.com
• SPF : inclut l’IP d’envoi (ou le relais), suffisamment strict pour empêcher les abus
• DKIM : activé avec des clés stables
• DMARC : au moins p=none pendant le déploiement, puis durcir lorsque la confiance est établie

À quoi ressemble du « mauvais »

• PTR absent, ou pointe vers ip-203-0-113-45.provider.example tandis que votre HELO est mail.yourbrand.com.
• PTR pointe vers un nom, l’A pointe vers une IP différente, et votre bannière SMTP utilise un troisième nom.
• L’IPv6 est activé et utilisé, mais sans PTR, donc la moitié de votre trafic paraît cassée selon la préférence du destinataire.
• Vous envoyez depuis une IP partagée où vous ne contrôlez pas le PTR ; le comportement du voisin vous tire vers le bas.

Une maxime opérationnelle à garder sur un post‑it : la cohérence bat l’ingéniosité.
Les récepteurs font du pattern matching, pas la lecture de votre diagramme d’architecture.

Paraphrase d’une idée de Gene Kranz : « Soyez dur et compétent. » En termes de délivrabilité : soyez ennuyeux et correct, chaque jour.

Trois mini-histoires d’entreprise du terrain

1) Incident causé par une mauvaise hypothèse : « On a configuré le DNS, donc le rDNS est configuré »

Une entreprise B2B de taille moyenne a migré son service de notifications d’un fournisseur géré vers « Postfix auto‑hébergé pour réduire les coûts. »
Le déploiement s’est bien passé : SPF mis à jour, DKIM implémenté, DMARC en mode monitoring, modèles testés.
Leur staging délivrait bien. La production non.

La file de support a commencé à se remplir de « je n’ai jamais reçu ma réinitialisation de mot de passe ». Les équipes commerciales ont escaladé car des prospects ne recevaient plus les invitations d’essai.
L’ingénierie a regardé les métriques : le MTA remettait les messages, la file n’augmentait pas, et les logs montraient des rebonds — certains depuis des gateways strictes,
d’autres depuis de gros fournisseurs de boîtes, et un nombre suspect de messages disparus dans le purgatoire du greylisting.

La mauvaise hypothèse : l’équipe croyait que créer mail01.company.com et son enregistrement A signifiait que le DNS inverse était automatiquement « couvert. »
Ils avaient fait le travail DNS dans leur zone authoritative et mentalement coché la case « DNS fait. »
Personne n’a demandé qui possédait la zone inverse de l’IP. Ce n’était pas eux.

La correction fut peu glamour. Ils ont ouvert une demande fournisseur pour définir le PTR de l’IP d’egress publique vers mail01.company.com.
Ils ont aligné la bannière et le HELO de Postfix pour correspondre. Ils ont désactivé l’IPv6 jusqu’à ce que le fournisseur configure aussi le PTR IPv6.
En moins d’un jour, les rebonds « pas de PTR » ont cessé, et les délais de greylisting ont diminué car l’identité de l’expéditeur a cessé de fluctuer.

Le changement durable : une étape de runbook indiquant « le PTR appartient au fournisseur IP ; vérifiez avec dig -x depuis l’extérieur. »
C’est le type de connaissance institutionnelle qu’on n’acquiert qu’après s’être fait humilier en production devant la finance.

2) Optimisation qui a échoué : « faisons un rDNS par client pour le branding »

Une plateforme d’entreprise voulait que chaque client « ait l’air d’envoyer depuis lui » tout en utilisant l’infrastructure du fournisseur.
Quelqu’un a proposé : allouer une pool d’IPs et définir des PTR comme customer-a-mail.vendor.example, customer-b-mail.vendor.example,
voire utiliser le domaine du client dans le PTR pour gagner en confiance.

Sur le papier, c’était ingénieux : segmenter la réputation, isoler les locataires bruyants, et donner aux clients l’impression de contrôle.
En réalité, c’est devenu une toile fragile. Les changements PTR étaient liés à l’automatisation et aux workflows de tickets.
Parfois les enregistrements directs (forward) ne suivaient pas les PTR. Parfois l’identité HELO ne se mettait pas à jour avec le mapping client.
Parfois la pool tournait plus vite que les TTL.

Les récepteurs voyaient de l’incohérence : l’IP connectante avait un PTR customer-a-mail.vendor.example, mais le HELO disait mail-gw.vendor.example.
Ou le PTR pointait vers un nom dont l’A n’existait pas encore.
La délivrabilité de la plateforme n’a pas seulement échoué ; elle a échoué de manière intermittente, ce qui est le pire car cela engendre des superstitions.

Le retour de bâton était prévisible : « identité dynamique » ressemble à l’abus.
Certains filtres traitent les combos PTR/HELO qui changent fréquemment comme suspects car les botnets montrent la même rotation.
Parallèlement, la charge opérationnelle a augmenté : plus de pièces mobiles, plus de problèmes de propagation, plus d’exceptions.

Le retour en arrière a été un soulagement. Ils ont conservé des IP dédiées pour les gros clients mais sont revenus à un schéma de nommage stable et ennuyeux :
un petit ensemble de hostnames de gateways mail avec PTR et HELO cohérents, et la séparation des locataires gérée par les domaines d’enveloppe et l’authentification.
Le branding appartient au From: et à l’alignement DKIM, pas aux acrobaties PTR.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : vérifications préalables dans la pipeline de release

Une entreprise soumise à de fortes contraintes de conformité faisait partir le mail via une couche de relais contrôlée. Ils n’étaient pas rapides, mais cohérents.
Chaque changement d’infrastructure passait par une checklist : inventaire des IP d’egress, vérification PTR, autorisation SPF, paramètres TLS, surveillance des codes de rebond.

Lors d’un rafraîchissement réseau, une nouvelle gateway NAT a été introduite pour simplifier le routage. Ça a fonctionné. Le trafic a circulé.
Mais l’IP sortante a changé. C’est là que la plupart des équipes apprennent le rDNS à la dure — après l’arrivée des plaintes.

Leur pipeline l’a détecté avant les utilisateurs de production. Un job de preflight a exécuté des recherches inverses sur l’IP d’egress candidate et a comparé les résultats
à une liste blanche de noms PTR approuvés. Ça a échoué car l’IP NAT avait un PTR par défaut fournisseur.
Le changement a été mis en pause, une demande PTR déposée, et la migration a continué une fois la vérification passée.

Rien de dramatique ne s’est produit. C’était la victoire.
La fiabilité est souvent juste une série de petits « non » pris assez tôt pour que personne n’appelle ça un incident.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: “550 5.7.1 Client host rejected: cannot find your reverse hostname”

Cause racine : Pas d’enregistrement PTR pour l’IP connectante, ou délégation DNS inverse cassée.

Correctif : Définissez le PTR auprès du propriétaire/fournisseur IP. Vérifiez avec dig -x depuis un résolveur public. Si SERVFAIL, escaladez les problèmes de délégation de zone inverse.

2) Symptom: Mail lands in spam on some providers, inbox on others

Cause racine : Le rDNS existe mais ne correspond pas au DNS direct (échec FCrDNS), ou le nom HELO ne se résout pas.

Correctif : Assurez‑vous que le nom PTR a des A/AAAA qui retournent l’IP d’envoi, et que le HELO du MTA utilise un FQDN résoluble cohérent avec le PTR.

3) Symptom: Everything worked until a “minor network change”

Cause racine : L’IP sortante a changé (nouveau NAT, nouveau chemin d’egress), mais PTR/SPF n’ont pas été mis à jour.

Correctif : Traitez l’IP d’egress comme une dépendance. Mettez à jour PTR et SPF avant le basculement ; vérifiez avec des requêtes DNS externes.

4) Symptom: IPv4 deliverability OK, IPv6 deliverability terrible

Cause racine : IPv6 n’a pas de PTR, ou le AAAA pointe ailleurs que prévu, ou la zone inverse IPv6 du fournisseur n’est pas déléguée.

Correctif : Définissez PTR et AAAA IPv6 correctement, ou désactivez l’envoi SMTP en IPv6 jusqu’à alignement. Ne laissez pas une IPv6 partiellement configurée vous dégrader.

5) Symptom: PTR set correctly, but some receivers still say “no reverse”

Cause racine : Propagation/caching DNS, ou vous ne testez pas l’IP réellement connectante, ou confusion due au split‑brain DNS.

Correctif : Confirmez l’IP source avec ss ou les logs MTA ; interrogez des résolveurs publics ; attendez les TTL ; videz les caches locaux si nécessaire.

6) Symptom: You can’t set PTR in your DNS provider UI

Cause racine : Vous ne contrôlez pas la zone inverse de l’IP. Votre fournisseur DNS de domaine est hors sujet ici.

Correctif : Utilisez la fonctionnalité PTR de votre fournisseur cloud ou ouvrez un ticket auprès de l’ISP. Si vous possédez le bloc IP, organisez correctement la délégation inverse.

7) Symptom: PTR points to a hostname, but A record points to a different IP “by design”

Cause racine : Abstraction tentée (load balancer, pool, ou nommage de marque) sans tenir compte des vérifications FCrDNS.

Correctif : Faites en sorte que le nom PTR renvoie vers la même IP. Si vous avez besoin d’abstraction, faites‑la aux couches supérieures, pas en cassant les signaux d’identité.

8) Symptom: Deliverability varies by tenant/customer on shared infrastructure

Cause racine : Réputation d’IP partagée et contrôle limité sur PTR/identité. Le comportement d’un voisin pollue la pool.

Correctif : Utilisez des IP dédiées pour l’envoi sortant ou un relais réputé. Si vous devez partager, appliquez des contrôles anti‑abus stricts et des politiques de taux.

Listes de contrôle / plan pas à pas

Checklist A: New outbound mail server (minimum viable “not embarrassing”)

1. Choisir un nom d’hôte stable pour le MTA : mail01.example.com.
2. Créer un enregistrement A : mail01.example.com → your outbound IPv4.
3. Créer un enregistrement AAAA si vous utilisez IPv6 : mail01.example.com → your outbound IPv6.
4. Demander/définir le PTR pour IPv4 vers mail01.example.com.
5. Demander/définir le PTR pour IPv6 vers mail01.example.com (ou désactiver l’IPv6 sortante).
6. Configurer la bannière/HELO du MTA pour utiliser mail01.example.com.
7. Vérifier que la sortie du port 25 est autorisée et stable (les clouds restreignent parfois).
8. Mettre SPF pour autoriser vos IP(s) sortantes ou le relais.
9. Activer la signature DKIM pour le domaine From: visible.
10. Mettre DMARC en mode monitoring initialement, puis durcir une fois les rapports et la confiance acquis.
11. Envoyer un test vers une boîte externe contrôlée ; inspecter les en‑têtes pour les résultats d’authentification.
12. Mettre en place la surveillance : codes de rebond, profondeur de file, anomalies de taux, et contrôles DNS pour PTR/FCrDNS.

Checklist B: When you change networking (NAT, egress, providers)

1. Inventorier les nouvelles IP d’egress pour le SMTP.
2. Pré‑provisionner le PTR pour chaque IP (v4 et v6).
3. Assurer que les hostnames PTR ont des A/AAAA renvoyant ces IP.
4. Mettre à jour SPF pour inclure les nouvelles IP (ou utiliser une inclusion pour le relais).
5. Exécuter une vérification externe : dig -x contre plusieurs résolveurs.
6. Basculer progressivement si possible ; surveiller les logs de rebond pour des rejets liés au rDNS.
7. Garder les anciennes IP actives jusqu’à convergence des caches et systèmes distants, si l’entreprise le permet.

Checklist C: Operational guardrails that keep rDNS from regressing

1. Documenter qui possède les modifications PTR (console fournisseur ? file de tickets ISP ?). Mettre des noms à côté.
2. Suivre les IP sortantes dans la gestion de configuration, pas dans la mémoire de quelqu’un.
3. Ajouter un job périodique pour valider : outbound IP → PTR existe → nom PTR → A/AAAA retourne la même IP.
4. Alerter en cas d’échec, mais garder le bruit bas (quotidien suffit sauf churn IP élevé).
5. Pendant les incidents, exiger que l’équipe identifie l’IP connectante avant de débattre DNS.

FAQ

1) Do I need reverse DNS for email to work?

SMTP livrera encore vers certains endroits sans PTR, mais beaucoup de récepteurs vous rejetteront ou placeront en spam. Si la délivrabilité compte, considérez le PTR comme requis.

2) Where do I create a PTR record?

Chez celui qui contrôle la zone inverse de l’IP — votre ISP, hébergeur ou plateforme cloud. Votre fournisseur DNS habituel ne peut généralement pas définir le PTR pour des IP louées.

3) Should PTR match my MX record?

Pas nécessairement. Le PTR doit représenter l’hôte/connecteur. Vos enregistrements MX représentent le routage entrant d’un domaine.
Souvent ils sont liés, mais les forcer à correspondre n’est pas une exigence et peut être contre‑productif.

4) What is FCrDNS and do I need it?

Forward‑confirmed reverse DNS signifie : IP → nom PTR, et nom → A/AAAA inclut la même IP. Ce n’est pas une loi formelle, mais c’est une vérification courante des filtres.
Si vous pouvez l’atteindre, faites‑le. Cela enlève une excuse facile pour vous méfier.

5) Can I use a PTR like “smtp.example.com” if multiple IPs send mail?

Vous pouvez, mais alors le mapping A/AAAA devient délicat. Si plusieurs IPs partagent le même nom PTR, la FCrDNS peut échouer à moins que l’enregistrement direct liste toutes les IPs.
Opérationnellement, un hostname unique par IP est plus propre pour la délivrabilité et le dépannage.

6) What about shared IPs where I can’t control PTR?

C’est un désavantage structurel. Vous héritez de la réputation et parfois de mauvaises pratiques rDNS.
Pour un envoi sérieux, utilisez une IP dédiée ou un relais où le PTR et la réputation sont gérés correctement.

7) If my PTR is correct, am I guaranteed inbox placement?

Non. Le PTR est de l’ordre du ticket d’entrée, pas du laissez‑passer. La délivrabilité dépend de l’authentification, de la réputation, des taux de plainte, de l’hygiène des listes, des modèles de volume et du contenu.
Le PTR vous évite juste d’échouer au test de « compétence de base ».

8) How fast do PTR changes propagate?

Cela dépend des TTL et du cache des résolveurs. Attendez des minutes à des heures. Certains systèmes conservent des données anciennes plus longtemps que souhaité.
Vérifiez toujours depuis plusieurs résolveurs publics et réseaux externes avant de déclarer victoire.

9) Does DMARC require PTR?

DMARC ne vérifie pas le PTR. Mais les récepteurs évaluent plusieurs signaux ensemble. Un DMARC passant peut être miné par une identité d’hôte manifestement cassée.
Inversement, un bon rDNS ne sauvera pas un DMARC en échec.

10) Should I disable IPv6 if I can’t get IPv6 PTR?

Si votre MTA peut envoyer en IPv6 et que l’identité IPv6 est cassée, désactiver l’IPv6 sortant est souvent la solution pragmatique jusqu’à correction.
Une IPv6 à moitié configurée est un piège pour la délivrabilité.

Étapes suivantes que vous pouvez faire aujourd’hui

1. Identifiez votre vraie IP d’envoi. N’assumez pas ; vérifiez via les logs ou les sockets sortants.
2. Exécutez des vérifications PTR + FCrDNS depuis au moins un résolveur public.
3. Rendez la bannière et le HELO du MTA ennuyeux et résoluble. Idéalement alignez‑les avec le PTR.
4. Corrigez l’IPv6 délibérément. Soit configurez AAAA + PTR IPv6 correctement, soit empêchez l’IPv6 dans le SMTP sortant pour l’instant.
5. Opérationnalisez cela. Ajoutez une vérification récurrente et une étape de gestion des changements liée aux mises à jour d’egress réseau.

Le DNS inversé n’est pas glamour, et il ne remportera pas de prix d’architecture. C’est pourquoi il est si souvent cassé.
Mais si vous envoyez du mail depuis vos propres systèmes, le rDNS fait la différence entre « service professionnel » et « gremlin mystérieux du courrier ».
Choisissez l’ennui. Votre placement en boîte de réception vous remerciera.