rDNS/PTR manquant : la correction DNS ennuyeuse qui sauve la délivrabilité des e-mails

Ce qu’est réellement rDNS/PTR (et pourquoi le mail s’en soucie)

Le DNS répond normalement : « Quelle IP correspond à mail.example.com ? » C’est le DNS direct (enregistrements A/AAAA). Le DNS inverse répond à l’opposé : « Quel nom appartient à 203.0.113.10 ? » C’est un enregistrement PTR stocké sous une zone de mappage inverse spéciale (in-addr.arpa pour IPv4 et ip6.arpa pour IPv6).

Pour le mail, ce mappage inverse devient un signal peu coûteux : « L’opérateur de cette IP est-il suffisamment compétent pour configurer correctement le DNS de base, et le nom annoncé semble-t-il cohérent avec le reste de l’identité ? » Les récepteurs n’ont pas besoin du rDNS pour livrer un paquet. Ils l’utilisent pour décider s’ils peuvent faire confiance à un expéditeur assez pour placer le message dans la boîte de réception plutôt que dans la poubelle spam.

L’attente de base pour la délivrabilité : cohérence

Les récepteurs aiment généralement que ceci concorde :

• L’IP du serveur SMTP qui se connecte a un PTR qui résout vers un nom d’hôte, par ex. mail01.example.com.
• Ce nom d’hôte a un enregistrement A/AAAA qui résout de nouveau vers la même IP (reverse DNS confirmé par forward, souvent abrégé FCrDNS).
• Le nom utilisé dans la salutation SMTP (HELO/EHLO) correspond (ou appartient au moins à la même famille de domaines que) ce nom d’hôte.
• SPF/DKIM/DMARC s’alignent avec les domaines envelope-from et/ou header-from (ce n’est pas strictement rDNS, mais les problèmes rDNS ont tendance à coïncider avec « le reste est aussi en désordre »).

Remarquez ce qui n’est pas dans la liste : « Le PTR doit correspondre au domaine From: ». C’est une idée fausse courante. Vous pouvez envoyer des mails en tant que @example.com depuis un hôte nommé smtp-out.provider.net—cela se fait constamment par des expéditeurs légitimes. Mais si vous gérez votre propre infrastructure, aligner ces signaux coûte moins cher que de déboguer pourquoi Outlook fait la tête aujourd’hui.

Une règle pratique : si vous exploitez l’IP, vous devriez pouvoir définir le PTR. Si vous ne contrôlez pas l’IP (hébergement partagé, FAI grand public, adresse dynamique), vous n’opérez pas un serveur mail sortant de production ; vous réalisez une expérience.

Blague courte n°1 : Le DNS inverse, c’est comme étiqueter la porte de votre bureau. Les gens peuvent toujours entrer dans l’immeuble sans ça, mais ils supposeront que vous êtes le stagiaire et vous dirigeront vers le dossier spam.

Comment les systèmes récepteurs utilisent rDNS (comportement réel, pas le folklore)

Les récepteurs accordent des poids différents au rDNS, et ils ne publient pas la formule exacte. Mais rDNS apparaît dans trois endroits qui importent opérationnellement :

1) Rejets directs et règles de politique

Certaines organisations (surtout dans des secteurs régulés) configurent des passerelles entrantes pour rejeter les connexions SMTP qui n’ont pas de PTR ou ont un PTR à l’apparence générique. La logique est brutale : « Si vous n’avez pas pris la peine de configurer rDNS, vous n’êtes pas sérieux. » C’est rudimentaire, mais facile à expliquer aux auditeurs.

Beaucoup de grands fournisseurs pour consommateurs sont plus nuancés : l’absence de PTR seule n’entraînera pas toujours un rejet instantané, mais elle peut se combiner avec des signaux de réputation (IP nouvelle, faible volume, contenu étrange, mauvais alignement DKIM) et vous faire franchir la ligne.

2) Scoring anti-spam et limitation de débit

rDNS et FCrDNS alimentent souvent des heuristiques : un mappage incohérent ou manquant augmente la suspicion, ce qui peut signifier placement en spam, limitation de débit, ou comportement de type greylisting. C’est là que ça devient exaspérant : vos mails « fonctionnent parfois », sauf pour les 15 % de destinataires qui sont derrière une politique entrante stricte.

3) Réponse aux incidents et traitement des abus

Quand vous êtes signalé pour abus, quelqu’un—humain ou machine—essaie de déterminer qui possède l’IP. Le PTR n’est pas une preuve d’autorité, mais c’est une miette de pain. Un nom rDNS propre et cohérent qui pointe vers un domaine avec des boîtes postmaster/abuse opérationnelles fait que le monde vous traite comme un adulte. Un PTR tel que ip-203-0-113-10.somecloud.internal n’aide pas votre cause.

Ce que les récepteurs ne font généralement pas

Les récepteurs n’« authentifient » généralement pas votre identité avec le PTR. Le PTR peut être spoofé par celui qui contrôle la délégation de la zone inverse (presque toujours le fournisseur d’accès/cloud). C’est un signal faible par conception. Mais les filtres anti-spam raffolent des signaux faibles—beaucoup d’entre eux, pondérés et combinés.

Mentalité opérationnelle : rDNS n’est pas une baguette magique pour la délivrabilité. C’est le ticket d’entrée. Vous ne gagnez pas parce que vous l’avez ; vous perdez parce que vous ne l’avez pas.

Faits et historique : pourquoi cela existe encore

Le rDNS ressemble à la ligne fixe des fonctionnalités DNS : tout le monde prétend qu’il est obsolète, et pourtant il pilote encore la logique commerciale de la moitié du monde. Quelques faits concrets et points de contexte historique qui expliquent pourquoi :

1. Les enregistrements PTR précèdent les anti-spams modernes. Le mappage inverse existait tôt comme commodité pour nommer les hôtes depuis les IP ; le mail l’a adopté plus tard comme indice de confiance.
2. Les zones inverses sont généralement contrôlées par les propriétaires des IP, pas par les propriétaires de domaine. C’est pourquoi vous ne pouvez souvent pas définir le PTR depuis l’interface de votre fournisseur DNS habituel.
3. L’espace de noms du DNS inverse est séparé. IPv4 utilise in-addr.arpa avec les octets inversés ; IPv6 utilise ip6.arpa avec les nybbles inversés—oui, c’est aussi amusant que ça en a l’air.
4. « FCrDNS » (forward-confirmed reverse DNS) est un schéma, pas un protocole. C’est une vérification de cohérence : PTR → nom → A/AAAA → même IP.
5. Les défenses anti-spam initiales s’appuyaient sur rDNS parce que c’était bon marché. Les requêtes DNS étaient faciles, et beaucoup de spammeurs utilisaient des pools dial-up/dynamiques sans PTR stable.
6. Certaines réseaux attribuent volontairement des PTR génériques pour les plages grand public. Cela aide les systèmes de mail à repérer les « émetteurs résidentiels probables » qui essaient d’exécuter des serveurs SMTP.
7. Le courriel est l’un des derniers systèmes qui récompensent encore les signaux d’infrastructure statique. HTTP ne se soucie pas de votre PTR. SMTP, culturellement et techniquement, s’en soucie toujours.
8. Les grands fournisseurs combinent de plus en plus les signaux d’identité. rDNS seul ne vous sauvera pas, mais un PTR manquant coïncide souvent avec des SPF/DKIM/DMARC manquants, et les filtres traitent la corrélation comme une confession.
9. IPv6 a rendu rDNS plus difficile opérationnellement. Le nom inverse est long, la délégation se fait par nybbles, et il est facile de l’oublier lors des déploiements—donc c’est une cause fréquente de « pourquoi le mail en v6 échoue ? ».

Une citation qui devrait figurer sur tous les murs des opérations, même si vous ne vous en souvenez qu’en cas d’incident : Everything fails, all the time. — Werner Vogels

rDNS est un petit « tout peut échouer ». Traitez-le comme tel.

Playbook de diagnostic rapide

Voici la checklist « quelqu’un a escaladé la délivrabilité » que vous exécutez avant de commencer à blâmer le contenu, l’automatisation marketing, ou la phase de la lune.

Première étape : identifier l’IP d’egress réelle utilisée pour le mail sortant

• Confirmez quelle IP les destinataires voient dans les logs SMTP ou les messages de rebond.
• Si vous utilisez un relais, confirmez si vous êtes sur un pool partagé ou des IP dédiées.
• Si vous avez plusieurs NIC, NAT, egress Kubernetes, ou un pare-feu réécrivant les IP source, supposez que vous vous trompez jusqu’à preuve du contraire.

Deuxième étape : vérifier l’existence et l’exactitude du PTR

• Pas de PTR du tout ? Corrigez cela d’abord. Arrêtez de débattre.
• Le PTR existe mais est générique ou pointe vers un mauvais domaine ? Décidez si vous pouvez le changer ; sinon, migrez le mail vers une meilleure IP.

Troisième étape : vérifier FCrDNS et la salutation SMTP

• Le nom PTR doit se résoudre en avant vers la même IP.
• Le nom HELO/EHLO de votre MTA doit être ce nom d’hôte (ou un alias sensé qui se résout correctement).

Quatrième étape : confirmer que SPF/DKIM/DMARC ne vous sapent pas

• Les problèmes PTR voyagent souvent avec des SPF « ~all » et un DKIM qui ne fonctionne que le mardi.
• Ne corrigez pas un signal et ignorez le reste.

Cinquième étape : vérifier les signaux de liste noire / réputation de base

• Si vous êtes sur une IP sale, un PTR correct ne lavera pas votre réputation.
• Si vous êtes sur une IP neuve, échauffez-la ; ne « optimisez » pas en envoyant tout le volume immédiatement.

Blague courte n°2 : La délivrabilité des e-mails, c’est comme la plomberie : le problème n’est presque jamais le robinet sophistiqué, et presque toujours le tuyau que vous n’avez pas vérifié.

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

Ce sont des tâches d’opérateur réelles. Chacune inclut une commande, un exemple de sortie plausible, ce que cela signifie, et quelle décision prendre. Remplacez les IPs/domaines par les vôtres. Utilisez une machine qui a une récursion DNS fonctionnelle (ou orientez les outils vers un résolveur connu explicitement).

Task 1: Determine what IP your server uses to reach the internet

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Signification : Votre trafic sortant (et probablement l’egress SMTP) utilise l’IP 203.0.113.10.

Décision : Cette IP doit avoir un PTR correct. Si vous attendiez une autre IP, cherchez les règles NAT, l’egress cloud, ou le SNAT du load balancer.

Task 2: Find the public egress IP from outside your network

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

Signification : Les services externes voient votre egress comme 203.0.113.10.

Décision : Si cela diffère de l’IP à laquelle vous pensez que votre serveur SMTP est lié, vous êtes peut-être derrière un NAT. Le rDNS doit être défini sur l’IP publique NAT, pas sur votre adresse privée.

Task 3: Check PTR (reverse DNS) with dig

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

Signification : L’IP a un PTR pointant vers mail01.example.com.

Décision : Bon début. Vérifiez ensuite que ce nom se résout vers la même IP (FCrDNS).

Task 4: Detect missing PTR

cr0x@server:~$ dig -x 203.0.113.11
; <<>> DiG 9.18.24-1-Debian <<>> -x 203.0.113.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1196
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Signification : Aucun enregistrement inverse n’existe pour cette IP.

Décision : Corrigez le rDNS auprès du fournisseur d’IP (cloud/FAI). Ne continuez pas à « tester la délivrabilité » tant que ce n’est pas fait—vos résultats seront bruyants et majoritairement mauvais.

Task 5: Verify forward DNS of the PTR hostname

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

Signification : Le DNS direct correspond à l’IP de connexion.

Décision : C’est un FCrDNS réussi (au moins pour IPv4). Si vous voyez une IP différente, corrigez l’enregistrement A, les attentes NAT, ou changez le PTR vers le nom d’hôte correct.

Task 6: Verify AAAA too (if you have IPv6)

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

Signification : Le nom d’hôte a aussi de l’IPv6.

Décision : Si votre SMTP écoute sur IPv6, vous devez aussi configurer le PTR IPv6 et garantir la cohérence forward-reverse. Si vous n’êtes pas prêt, ne publiez pas d’AAAA pour le nom d’hôte mail.

Task 7: Check IPv6 PTR

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

Signification : Le mappage inverse IPv6 existe et correspond.

Décision : Bien. S’il manque, attendez-vous à ce que certains récepteurs traitent votre livraison IPv6 comme suspecte ou échoue complètement ; configurez-le ou désactivez le SMTP IPv6 jusqu’à ce que vous puissiez le faire correctement.

Task 8: Inspect what your MTA uses for HELO/EHLO

cr0x@server:~$ postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name)='
mydomain = example.com
myhostname = mail01.example.com
smtp_helo_name = $myhostname

Signification : Postfix se présentera comme mail01.example.com.

Décision : Gardez-le cohérent : HELO/EHLO doit être un FQDN réel avec A/AAAA, idéalement correspondant au PTR. Si vous voyez localhost ou un nom interne aléatoire, corrigez-le.

Task 9: See your SMTP greeting 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 affiche un nom d’hôte sensé.

Décision : Si la bannière affiche localhost ou un hôte interne, corrigez la configuration MTA. Certains filtres considèrent les bannières incohérentes comme suspectes.

Task 10: Confirm TLS certificate name matches the mail hostname (optional but common)

cr0x@server:~$ openssl s_client -starttls smtp -connect mail01.example.com:25 -servername mail01.example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mail01.example.com
issuer=CN = R3, O = Let's Encrypt, C = US

Signification : L’identité TLS correspond à mail01.example.com.

Décision : Non requis pour le rDNS, mais cela fait partie de l’image « expéditeur cohérent ». Si ce n’est pas le cas, corrigez-le ; vous voulez le moins de raisons possible pour que les récepteurs vous soupçonnent.

Task 11: Check SPF for the domain you send as

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

Signification : SPF autorise explicitement l’IP et est strict.

Décision : Si SPF est manquant ou n’inclut pas votre IP d’egress, corrigez SPF. Un PTR parfait ne compensera pas un échec SPF chez beaucoup de récepteurs.

Task 12: Check DKIM selector presence (DNS side)

cr0x@server:~$ dig +short TXT default._domainkey.example.com | head -n 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Signification : La clé publique DKIM existe pour le sélecteur default.

Décision : Assurez-vous que votre MTA signe les mails sortants avec ce sélecteur et que les en-têtes montrent DKIM=pass chez les destinataires. Si DKIM n’est pas en place, les corrections rDNS n’aideront que partiellement.

Task 13: Check DMARC policy

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Signification : DMARC existe avec une politique de quarantine et un alignement strict.

Décision : Si DMARC est absent, la délivrabilité peut varier ; si DMARC est strict mais que votre domaine From: n’est pas aligné avec DKIM/SPF, vous vous sabotez. Corrigez l’alignement avant de durcir la politique.

Task 14: Inspect reverse DNS delegation / authority (who can set PTR)

cr0x@server:~$ dig +noall +authority -x 203.0.113.10
10.113.0.203.in-addr.arpa.  3600 IN SOA ns1.provider.net. hostmaster.provider.net. 2026010301 7200 3600 1209600 3600

Signification : Le nameserver du fournisseur est autorité pour la zone inverse.

Décision : Vous devez définir le PTR via le panneau/API de ce fournisseur ou le demander via le support. Changer votre fournisseur DNS direct ne servira à rien.

Task 15: Confirm the PTR you set is visible globally (not just cached locally)

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

Signification : Un résolveur public voit le PTR correct.

Décision : Si les résolveurs publics divergent, vous courez après la propagation ou un DNS à horizon partagé. Les récepteurs utilisent leurs propres résolveurs ; faites confiance à ce que voient les résolveurs publics.

Task 16: Check for multiple PTRs (usually a bad idea)

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer
10.113.0.203.in-addr.arpa. 300 IN PTR mail01.example.com.
10.113.0.203.in-addr.arpa. 300 IN PTR mail-gateway.example.com.

Signification : Deux PTR existent pour une même IP.

Décision : Choisissez un PTR canonique. Plusieurs PTR embrouillent les heuristiques et les humains. Le mail veut une identité par IP d’envoi.

Task 17: Watch SMTP transactions and see rejections tied to rDNS

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log | egrep -i 'reject|rbl|helo|ptr|reverse'
Jan 03 09:14:22 mail01 postfix/smtp[12044]: host mx.remote.example[198.51.100.25] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)

Signification : Un destinataire a explicitement rejeté en raison d’un nom inverse manquant.

Décision : Corrigez le PTR immédiatement. Si le PTR est défini, vérifiez la propagation et que l’IP de connexion correspond à celle que vous avez corrigée.

Task 18: Validate your MTA binds to the intended interface/IP

cr0x@server:~$ sudo ss -ltnp | egrep ':25\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=912,fd=13))

Signification : Le SMTP écoute sur toutes les interfaces IPv4.

Décision : Si vous avez plusieurs IP publiques et qu’une seule a un PTR correct, envisagez de lier explicitement ou de router le mail sortant via la bonne IP source.

Task 19: Confirm outbound source IP for SMTP specifically (packet-level)

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 25 and host 198.51.100.25 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:15:01.102938 IP 203.0.113.10.48214 > 198.51.100.25.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0

Signification : La connexion SMTP provient de 203.0.113.10.

Décision : C’est l’IP dont le rDNS doit être correct. Si vous voyez une IP source différente de celle attendue, corrigez le routage/NAT ou la configuration de l’adresse source du MTA.

Task 20: Test reverse + forward in one shot (FCrDNS quick check)

cr0x@server:~$ ip=203.0.113.10; host $ip; hn=$(host $ip | awk '/domain name pointer/{print $5}'); host ${hn%.}
10.113.0.203.in-addr.arpa domain name pointer mail01.example.com.
mail01.example.com has address 203.0.113.10

Signification : Le PTR retourne mail01.example.com, et ce nom retourne la même IP.

Décision : FCrDNS est validé. Si la seconde requête retourne une IP différente, vous avez une incohérence—corrigez soit le PTR soit l’A/AAAA pour les faire correspondre.

Trois mini-histoires d’entreprise issues du terrain

1) L’incident causé par une mauvaise hypothèse : « Le cloud configure sûrement le rDNS »

Une entreprise de taille moyenne a migré d’un service e-mail géré vers « SMTP sortant auto-hébergé pour contrôler les coûts ». Le plan était séduisant sur la feuille de calcul : quelques VM, Postfix, un relais pour la redondance, et une nouvelle plage d’IP dédiée fournie par leur cloud. Ils ont conservé SPF et DKIM en grande partie. Ils avaient même un monitoring sur la profondeur des files et la latence.

Puis les rebonds ont commencé. Pas une panne dramatique—pire. Certains clients recevaient des mails. D’autres non. Les tickets support sont devenus étranges : « Le reset de mot de passe n’arrive pas », « E-mail de facture manquant », « Votre système est instable ». L’équipe a regardé les suspects habituels : limites de taux, filtres de contenu, réglages TLS, et s’ils envoyaient accidentellement depuis le mauvais domaine. Ils étaient fiers de leur automatisation, donc naturellement ils ont suspecté tout le monde sauf eux.

L’hypothèse erronée était simple : « Si la VM a une IP, le rDNS sera là. » Il ne l’était pas. Leur bloc d’IP avait des PTR pointant vers des noms génériques du fournisseur. Le MTA se présentait comme mail.example.com, SPF autorisait les IPs, mais l’identité inverse ressemblait à un hôte jetable d’un pool de compute.

La correction fut anticlimatique : demander des PTR personnalisés au fournisseur, les faire correspondre au nom d’hôte du MTA, s’assurer que l’A en avant correspondait, et attendre l’expiration des caches. Le rapport d’après-action était plus intéressant que la réparation. Ils ont ajouté un élément à la checklist pré-déploiement : « PTR défini et vérifié extérieurement pour toutes les IP sortantes. » Ce n’était pas une percée technique ; c’était une maturité organisationnelle déguisée en ennui.

2) L’optimisation qui a échoué : « On va faire tourner des IP d’egress pour répartir le risque »

Une autre entreprise avait des problèmes de délivrabilité et a décidé de jouer plus malin que les systèmes de réputation. L’idée : faire tourner les IPs sortantes à travers un pool pour qu’aucune IP n’accumule une mauvaise réputation. Quelqu’un a même appelé ça « sharding de la délivrabilité ». Ce terme aurait dû déclencher une alarme.

Ils ont construit une couche NAT astucieuse qui mappait les connexions SMTP sortantes sur plusieurs IPs publiques. Le pool incluait des IPs neuves et quelques-unes qui étaient restées inactives pendant des mois. Leurs instances Postfix ne liaient pas une IP source spécifique ; le réseau faisait l’équilibrage. Les ingénieurs aiment une belle abstraction, et le NAT est le plus propre des mensonges qu’on se raconte.

Ce qui est arrivé ensuite était prévisible si vous avez déjà géré du mail : les récepteurs ont vu des signaux d’identité incohérents. Une connexion venait d’une IP avec un PTR mail01.example.com. Une autre venait d’une IP sans PTR. Une autre avait un PTR pointant vers un nom d’hôte désaffecté qui n’avait plus d’enregistrement A en avant. Le HELO était stable, l’IP source ne l’était pas. Les filtres anti-spam n’avaient pas besoin d’un doctorat : ils ont vu l’instabilité et l’ont traitée comme un risque.

La délivrabilité s’est aggravée. Ils ont aussi rendu le débogage plus difficile parce que les rebonds faisaient référence à des IP sources différentes selon le mapping NAT du jour. L’« optimisation » a dilué leur réputation et empêché toute IP d’accumuler un historique cohérent. Ils sont revenus en arrière, ont épinglé l’egress SMTP à une seule IP réchauffée avec rDNS correct, puis n’ont introduit une seconde IP—correctement configurée—qu’une fois la première stabilisée.

La leçon n’était pas « ne jamais utiliser plusieurs IPs ». La leçon était : si vous ne pouvez pas maintenir une identité cohérente sur le pool (PTR, DNS direct, HELO, SPF), ne créez pas de pool. Le mail punit l’ingéniosité.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Traitez le PTR comme une dépendance de production »

Une grande entreprise avait un rituel presque comiquement procédural. Chaque fois qu’une nouvelle IP sortante était allouée—cloud, colo, site de secours, peu importe—un petit ticket « identité mail » devait être clôturé avant que l’IP puisse être utilisée. Le ticket n’était pas optionnel. Il avait une checklist : PTR demandé, A/AAAA direct créés, HELO configuré, SPF mis à jour, et une validation externe exécutée depuis une machine hors du DNS corporate.

Pendant une panne régionale, ils ont basculé le mail sortant vers un site secondaire. Leurs MTA sont montés, les files se sont vidées, et les clients ont à peine remarqué. Pourquoi ? Parce que les IPs secondaires avaient déjà des PTR et un DNS direct corrects depuis des mois, même si le site était majoritairement inactif. Rien n’a été « découvert » pendant l’incident. Le travail ennuyeux avait été prépayé.

Il restait du travail—chauffe de volume, surveillance des changements de réputation, réglage des limites de débit—mais ils ont évité le pire scénario : une bascule qui fonctionne techniquement pendant que chaque grand fournisseur vous jette silencieusement dans le spam. C’est le type d’incident qui n’apparaît pas dans les graphiques CPU et qui détruit la confiance.

Ce n’est pas de l’ingénierie héroïque. C’est juste refuser d’exécuter le mail sur une identité partiellement configurée. Le mantra de l’équipe était grosso modo : si vous ne déployeriez pas sans TLS, ne déployez pas sans PTR.

Erreurs courantes : symptôme → cause racine → correction

Voici des patterns que je rencontre régulièrement en production. Chacun a un symptôme spécifique, une cause probable et une correction qui n’implique pas de souhaits pieux.

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

Cause racine : Aucun enregistrement PTR pour l’IP de connexion, ou DNS inverse cassé à cause d’une mauvaise configuration du fournisseur.

Correction : Définissez le PTR chez le fournisseur d’IP. Vérifiez avec dig -x depuis un résolveur public. Assurez-vous que votre SMTP sort réellement depuis cette IP.

2) Symptom: Mail lands in spam at Microsoft/Google but not everywhere

Cause racine : Le PTR existe mais est générique, non assorti, ou ne se résout pas en avant (FCrDNS échoue). Souvent combiné à une réputation faible/nouvelle.

Correction : Faites pointer le PTR vers un nom d’hôte que vous contrôlez ; assurez-vous que l’A/AAAA du nom d’hôte pointe de retour vers la même IP. Gardez le HELO cohérent. Échauffez progressivement l’IP.

3) Symptom: Bounces reference an IP you don’t recognize

Cause racine : NAT, relais sortant, load balancer, ou serveur multi-homed utilisant une IP d’egress différente de celle attendue.

Correction : Confirmez l’egress avec capture de paquets ou vérifications de route. Liez le MTA à une IP source spécifique si nécessaire. Configurez le PTR pour l’IP réelle d’egress.

4) Symptom: PTR points to a hostname, but forward lookup gives a different IP

Cause racine : Quelqu’un a changé l’enregistrement A durant une migration, ou le PTR a été copié depuis une ancienne infrastructure. FCrDNS échoue.

Correction : Décidez de la source canonique (généralement le nom d’hôte mail réel pour cette IP), puis mettez à jour PTR et A/AAAA pour qu’ils correspondent. Une IP d’envoi, une identité.

5) Symptom: PTR points to localhost or an internal name in logs

Cause racine : myhostname du MTA ou HELO est mal configuré ; l’identité de la bannière ne correspond pas à la réalité.

Correction : Configurez le nom d’hôte du MTA sur un FQDN réel avec DNS direct correct. Assurez-vous que le HELO l’utilise. Ne vous présentez pas sous des noms internes.

6) Symptom: IPv4 mail is fine; IPv6 mail fails more often

Cause racine : L’enregistrement AAAA existe ; le SMTP propose IPv6 ; mais le PTR IPv6 est manquant ou erroné. Ou l’adresse IPv6 provient d’un pool à mauvaise réputation.

Correction : Configurez correctement le rDNS IPv6 et assurez la FCrDNS, ou cessez d’annoncer IPv6 pour le mail sortant jusqu’à ce que ce soit fait correctement.

7) Symptom: You “set PTR,” but some receivers still claim it’s missing

Cause racine : Propagation/caching, ou vous avez configuré le PTR pour la mauvaise IP (fréquent avec NAT), ou vous avez testé contre votre résolveur interne qui ment.

Correction : Interrogez directement des résolveurs publics. Confirmez l’IP de connexion depuis les logs. Attendez l’expiration des TTL, mais ne confondez pas attente et correction.

8) Symptom: Deliverability drops after moving to a new provider

Cause racine : PTR remis aux valeurs par défaut du fournisseur ; SPF non mis à jour ; HELO non aligné ; réputation IP froide.

Correction : Traitez les migrations comme des migrations d’identité. Pré-provisionnez PTR et enregistrements directs. Échauffez les nouvelles IPs. Gardez l’ancien émetteur en service pendant la transition si possible.

Listes de contrôle / plan étape par étape

Étape par étape : corriger un PTR manquant de manière sûre

1. Identifiez les IP(s) d’envoi réelles. Utilisez rebonds, logs SMTP, ou capture de paquets. Ne devinez pas.
2. Choisissez un nom d’hôte mail canonique par IP d’envoi. Exemple : mail01.example.com pour 203.0.113.10. Gardez-le stable.
3. Créez d’abord le DNS direct. Ajoutez A (et AAAA si applicable) pour le nom d’hôte pointant vers l’IP d’envoi.
4. Demandez/définissez le PTR chez le fournisseur. Pointez-le vers le nom d’hôte canonique. Évitez les PTR multiples.
5. Vérifiez la FCrDNS. PTR se résout en nom ; le nom se résout en IP.
6. Alignez le HELO/EHLO. Configurez votre MTA pour se présenter comme le nom d’hôte canonique.
7. Confirmez que SPF inclut les IP(s) d’envoi. Utilisez une politique stricte si vous pouvez la supporter.
8. Confirmez que DKIM signe correctement de bout en bout. Vérifiez avec les en-têtes des messages chez les destinataires.
9. Vérifiez l’alignement DMARC. Surtout si vous appliquez quarantine/reject.
10. Surveillez files et rebonds pendant 48–72 heures. Attendez-vous à des caches qui traînent. Corrélez par domaine destinataire.
11. Documentez la frontière de propriété. Qui peut changer le PTR (fournisseur), qui peut changer le DNS direct (vous), et le SLA.

Checklist opérationnelle : avant de mettre une nouvelle IP sortante en service

• PTR défini et vérifié depuis au moins deux résolveurs publics.
• A/AAAA pour le nom PTR existe et correspond à l’IP.
• Nom HELO du MTA est ce nom ; la bannière concorde.
• SPF mis à jour pour les domaines d’envoi.
• Sélecteur DKIM publié ; signature activée ; mail de test montre DKIM=pass.
• DMARC présent et aligné avec votre stratégie d’authentification.
• IPv6 soit entièrement configuré (y compris rDNS) soit intentionnellement désactivé pour SMTP.
• Limites de débit sortant définies ; plan de chauffe pour nouvelles IPs.
• Logging en place pour mapper message-id → domaine destinataire → IP d’envoi.

Ce qu’il faut éviter quand vous êtes tenté de « juste faire marcher »

• Ne pas utiliser une IP dynamique/résidentielle pour le mail sortant.
• Ne pas faire tourner les IPs sources sans rDNS cohérent et réputation réchauffée.
• Ne pas définir un PTR vers un nom d’hôte qui n’existe pas en DNS direct.
• Ne pas vous présenter comme localhost, un nom interne, ou un nom sans A/AAAA.
• Ne pas publier d’AAAA pour votre nom d’hôte mail si vous ne pouvez pas définir le PTR IPv6.
• Ne pas supposer que vos tests DNS reflètent ce que voient les récepteurs externes ; testez avec des résolveurs publics.

FAQ

1) Ai-je absolument besoin d’un enregistrement PTR pour envoyer des e-mails ?

Techniquement, vous pouvez envoyer du SMTP sans PTR, mais beaucoup de récepteurs vous pénalisent ou vous rejettent. En pratique, un PTR manquant est un dommage auto-infligé pour la délivrabilité.

2) Qui contrôle l’enregistrement PTR—mon fournisseur DNS ou mon FAI/cloud ?

Le propriétaire de l’IP contrôle le DNS inverse. C’est généralement votre FAI ou fournisseur cloud. Votre fournisseur DNS habituel contrôle les enregistrements directs (A/AAAA), pas le PTR.

3) Le PTR doit-il correspondre au domaine From: ?

Pas strictement. Le PTR doit correspondre à l’identité de l’infrastructure d’envoi (le nom d’hôte du serveur). Si vous gérez votre propre domaine, il est plus propre que le PTR soit sous votre domaine, mais il n’a pas à correspondre exactement au From:.

4) Qu’est-ce que FCrDNS et est-ce requis ?

FCrDNS signifie PTR → nom d’hôte → A/AAAA → même IP. Ce n’est pas une exigence de protocole, mais c’est un contrôle de cohérence largement utilisé. Le réussir réduit la suspicion.

5) Une IP peut-elle avoir plusieurs PTR ?

Elle le peut, mais vous ne devriez généralement pas. Pour le mail, une IP d’envoi doit présenter une identité stable. Plusieurs PTR créent de l’ambiguïté et peuvent nuire aux heuristiques.

6) Si je corrige le PTR, ma délivrabilité va-t-elle se rétablir instantanément ?

Parfois vous verrez une amélioration immédiate sur les rejets directs. Le placement en spam peut prendre plus de temps car les systèmes de réputation se souviennent. Corriger le PTR arrête l’hémorragie ; cela n’efface pas l’historique.

7) Qu’en est-il d’IPv6—ai-je besoin du PTR là aussi ?

Si vous livrez le mail sur IPv6, oui. Certains récepteurs sont plus stricts sur IPv6 parce qu’il est plus facile pour des acteurs abusifs d’obtenir de grands espaces d’adresses. Si vous ne pouvez pas faire correctement le rDNS IPv6, n’annoncez pas IPv6 pour SMTP.

8) Mon fournisseur n’autorise que des PTR du type ip-203-0-113-10.provider.net. Est-ce acceptable ?

C’est mieux que rien, mais ce n’est pas idéal. Si vous ne pouvez pas définir un PTR significatif et que la délivrabilité vous importe, envisagez un fournisseur qui supporte le rDNS personnalisé ou utilisez un relais SMTP réputé avec options d’IP dédiées.

9) Le PTR remplace-t-il SPF/DKIM/DMARC ?

Non. Le PTR est un signal d’infrastructure faible. SPF/DKIM/DMARC sont des signaux d’authentification et de politique. Le filtrage moderne utilise tous ces éléments, plus la réputation et le contenu.

10) Quel nom d’hôte devrais-je utiliser pour le PTR ?

Utilisez un nom d’hôte stable et dédié pour le mail sortant : mail01.example.com ou smtp-out.example.com. Assurez-vous qu’il a un A/AAAA correspondant et que votre MTA l’utilise pour le HELO.

Prochaines étapes que vous pouvez faire aujourd’hui

1. Trouvez votre vraie IP d’egress SMTP. Ne vous fiez pas aux diagrammes ; fiez-vous aux captures de paquets et aux rebonds.
2. Exécutez trois recherches : dig -x <ip>, dig A <ptr-name>, et (si applicable) dig AAAA <ptr-name>. Faites-les concorder.
3. Corrigez le nom HELO/banner de votre MTA pour qu’il soit un FQDN réel résolvable et qu’il corresponde à votre identité PTR.
4. Vérifiez extérieurement avec des résolveurs publics pour éviter d’être trompé par un DNS interne.
5. Puis attaquez l’alignement SPF/DKIM/DMARC et le warm-up des IP. Le rDNS vous fait franchir la porte « vous êtes sérieux » ; l’authentification vous fait entrer dans le bâtiment.

Si vos problèmes de délivrabilité semblent mystérieux, commencez par rendre l’identité de votre infrastructure ennuyeuse et cohérente. Le mail récompense l’ennui. Il punit l’ingéniosité.