Pourquoi le DNS inverse est si important
Les serveurs de réception demandent le nom (enregistrement PTR) de chaque adresse IP qui livre et vérifient que ce nom pointe vers la même IP. On parle de forward-confirmed reverse DNS (FCrDNS). Sans cela, les mails finissent en spam ou sont directement refusés. Google et Yahoo l’exigent explicitement depuis 2024. Messages d’erreur typiques :
550-5.7.25 [203.0.113.10] The IP address sending this message does not have a 550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not 550 5.7.25 point to the sending IP. 450 4.7.1 Client host rejected: cannot find your reverse hostname, [203.0.113.10]
Où se configure le PTR
Le PTR n’appartient pas à ton domaine mais à l’adresse IP. Seul le propriétaire de l’IP peut le définir : ton hébergeur ou fournisseur d’accès. C’est pourquoi tu ne le trouves pas dans la gestion DNS de ton domaine.
- Hetzner : Cloud Console → serveur → Networking → modifier le reverse DNS ; pour les serveurs dédiés dans Robot sous « IPs ».
- OVHcloud : Bare Metal Cloud → Network → IP → « … » → modifier le reverse.
- AWS : EC2 → Elastic IPs → Actions → « Update reverse DNS ». L’enregistrement A doit exister avant.
- Azure : en CLI avec
az network public-ip update --reverse-fqdn. - DigitalOcean : le PTR suit le nom du droplet. Nomme donc le droplet exactement comme le serveur mail.
- Connexion Internet domestique ou de bureau : impossible avec une IP dynamique ; avec une IP fixe, en général seulement sur demande au fournisseur.
Étape par étape
- Choisir un nom, p. ex.
mail.example.com. - Enregistrement A (et AAAA pour IPv6) dans ta zone :
mail.example.com → 203.0.113.10. - PTR chez l’hébergeur :
203.0.113.10 → mail.example.com. - Nom HELO du serveur mail réglé sur le même nom. Postfix :
myhostname = mail.example.comdans main.cf. Exchange : FQDN dans le connecteur d’envoi. - Vérifier le SPF : l’IP doit figurer dans le SPF du domaine expéditeur, p. ex. via
mxouip4:203.0.113.10.
Le PTR n’a pas besoin de correspondre au domaine expéditeur. Un serveur mail.example.com peut envoyer sans problème pour autre-domaine.fr. L’important est que PTR, enregistrement A et HELO concordent entre eux.
Le piège IPv6
Si ton serveur a une adresse IPv6, Postfix livre souvent à Gmail & co. en IPv6. L’adresse IPv6 a alors aussi besoin d’un PTR et d’un AAAA correspondant. Si tu ne peux pas le définir, désactive l’envoi en IPv6 :
# Postfix main.cf inet_protocols = ipv4 # ou autoriser IPv6 mais préférer IPv4 : smtp_address_preference = ipv4
Vérifier
# PTR de l'IP dig -x 203.0.113.10 +short # le nom pointe-t-il vers l'IP ? dig +short A mail.example.com # Windows nslookup 203.0.113.10 # voir le HELO du serveur openssl s_client -starttls smtp -connect mail.example.com:25 -quiet
Selon le TTL, une modification du PTR peut mettre quelques heures avant d’être vue par tous les résolveurs. La recherche DNS montre PTR et contre-vérification en une étape ; le test de propagation DNS indique quels résolveurs connaissent déjà le nouvel enregistrement A.
FAQ
Le nom PTR doit-il contenir mon domaine expéditeur ?
Non. Il doit seulement être un vrai nom qui pointe vers la même IP via un A ou AAAA. Les noms génériques comme 203-0-113-10.fournisseur.net sont toutefois moins bien notés par certains destinataires.
Une IP peut-elle avoir plusieurs PTR ?
Techniquement oui, en pratique cela pose problème. Un nom par IP est la voie sûre.
Je ne peux pas définir le PTR. Que faire ?
Envoie le courrier sortant via un smarthost (relais) de ton fournisseur ou d’un service mail. Ton serveur continue de recevoir lui-même mais envoie via le relais.
Combien de temps avant que le PTR soit effectif ?
Chez l’hébergeur, en général immédiatement. Les résolveurs qui ont l’ancienne valeur en cache ne la voient qu’après expiration du TTL, souvent une à 24 heures.