Reverse DNS (rDNS) beantwoordt een andere vraag dan gewone DNS: in plaats van "naar welk IP-adres verwijst deze hostnaam?" beantwoordt het de vraag "naar welke hostnaam verwijst dit IP-adres?" Het mechanisme daarachter is het PTR-record (pointer), en mailservers controleren dit als basale controle of de machine die mail verstuurt echt is wie hij beweert te zijn. Gaat dit mis, dan belandt je uitgaande mail veel vaker in de spam, zelfs als je SPF-, DKIM- en DMARC-records perfect zijn ingesteld.
Wat is reverse DNS?
Een normale (forward) DNS-lookup neemt een hostnaam zoals mail.example.com en geeft een A- of AAAA-record met een IP-adres terug. Reverse DNS doet het omgekeerde: op basis van een IP-adres geeft het via een PTR-record een hostnaam terug. Deze koppeling is vastgelegd in de oorspronkelijke DNS-specificatie (RFC 1035) en staat in speciale reverse zones, niet in het zonebestand van je gewone domein.
Je kunt de records van elk IP-adres of elke hostnaam controleren met een DNS-lookuptool. Voor reverse lookups kun je bij de meeste tools het recordtype PTR rechtstreeks voor het IP-adres opvragen.
Zo werken de in-addr.arpa- en ip6.arpa-zones
Reverse DNS staat niet onder je domein. Het staat onder twee speciale, op IP-adressen gebaseerde zones die vanuit de DNS-root via de nummeringshiërarchie worden gedelegeerd:
- IPv4 gebruikt
in-addr.arpa. De vier octetten van het adres worden omgedraaid en voor dat achtervoegsel geplaatst.192.0.2.1wordt dus1.2.0.192.in-addr.arpa. - IPv6 gebruikt
ip6.arpa(vastgelegd in RFC 3596). Elke hexadecimale nibble van het 128-bits adres wordt omgedraaid en met punten gescheiden, wat een veel langere naam met 32 labels oplevert.
Omdat in-addr.arpa per octet is opgebouwd, worden reverse zones gewoonlijk gedelegeerd op /8-, /16- of /24-grenzen. Krijg je van je provider een kleiner blok, bijvoorbeeld een /27, dan past gewone in-addr.arpa-delegatie daar niet netjes op. RFC 2317 ("classless in-addr.arpa delegation") lost dit op met een workaround op basis van CNAME's, zodat ook blokken kleiner dan /24 correct PTR-delegatie kunnen krijgen.
Waarom mailservers een PTR-record nodig hebben
De meeste ontvangende mailservers controleren het PTR-record van het verbindende IP-adres als onderdeel van hun spamfiltering. Twee controles komen vaak voor:
- Bestaan van een PTR-record: heeft het verzendende IP-adres überhaupt een PTR-record? Veel spamfilters zien een ontbrekend PTR-record als alarmsignaal, omdat legitieme mailservers er bijna altijd een hebben.
- Forward-confirmed reverse DNS (FCrDNS): de ontvangende server neemt de hostnaam uit het PTR-record en doet daar een forward lookup op. Verwijst dat forward A/AAAA-record terug naar hetzelfde IP-adres, dan is de identiteit in beide richtingen bevestigd. Een mismatch, of een PTR-record dat nergens naartoe resolvet, lijkt op spoofing.
Een generiek PTR-record dat door de provider is toegewezen (iets als 123-45-67-89.dynamic-ip.example.net) in plaats van een echte mailhostnaam is ook een veelvoorkomend signaal dat je afzenderreputatie schaadt, zelfs als het technisch gezien resolvet. Ben je een deliverabilityprobleem aan het onderzoeken, dan hoort dit naast SPF, DKIM en DMARC bij de eerste dingen die je controleert. Lees waarom je e-mails in de spam belanden voor het volledige plaatje en gebruik tegelijk de MX-lookuptool om te controleren of je mailroutering klopt.
TipBest practice is precies één PTR-record per IP-adres, en dat moet overeenkomen met de hostnaam die je mailserver gebruikt in de SMTP HELO/EHLO-begroeting. Meerdere of niet-overeenkomende PTR-records laten de FCrDNS-controle mislukken, ook als de mail zelf legitiem is.
PTR-record instellen
Wie je PTR-record beheert, hangt af van wie eigenaar is van het IP-adres:
| Situatie | Wie stelt het PTR-record in |
|---|---|
| Cloud-VM (AWS, GCP, Azure) | De provider, via een supportverzoek of een selfservice-instelling voor reverse DNS in je account |
| VPS/dedicated server | Het controlepaneel van de hostingprovider, of je accountmanager |
| Zelf gehost met een eigen IP-blok | Jijzelf, zodra je provider of RIR de reverse zone naar jouw nameservers delegeert |
| Gedeeld/dynamisch IP-adres van je provider | Meestal niet mogelijk: je beheert het adres niet |
Cloud- en VPS-providers wijzen vrijwel altijd een standaard PTR-record toe dat naar een generieke hostnaam met de naam van de provider verwijst, tenzij je zelf een aangepaste instelt. Voor een mailserver wil je dat het PTR-record verwijst naar de daadwerkelijke hostnaam waarmee de server zich identificeert, bijvoorbeeld:
; Reverse zone: 2.0.192.in-addr.arpa
1.2.0.192.in-addr.arpa. IN PTR mail.example.com.
En de forward kant moet daarmee overeenkomen, zodat FCrDNS beide richtingen bevestigt:
; Forward zone: example.com
mail.example.com. IN A 192.0.2.1
Bij een cloudprovider vraag je dit meestal aan via de console of een supportticket in plaats van zelf een zonebestand te bewerken, omdat de in-addr.arpa-zone niet van jou is. Het eindresultaat is echter hetzelfde: een gekoppeld PTR- en A-record.
WarningStel je alleen het PTR-record in zonder een overeenkomend forward A-record (of andersom), dan mislukken FCrDNS-controles. Controleer na elke wijziging altijd beide richtingen, en houd er rekening mee dat het even duurt voordat de wijziging overal zichtbaar is. Lees DNS-propagatie uitgelegd als een lookup nog de oude waarde toont.
Reverse DNS buiten e-mail
Maildeliverability is de meest voorkomende reden waarom mensen naar PTR-records vragen, maar reverse DNS komt ook voor bij:
- Diagnostiek: traceroute en serverlogs zetten IP-adressen om in hostnamen voor de leesbaarheid.
- Toegangsbeheer: sommige oudere systemen en netwerkbeleidsregels doen allow/deny-controles op basis van rDNS, al komt dit veel minder vaak voor dan mailfiltering.
- Algemene netwerkhygiëne: een correct ingesteld PTR-record is een van de kleinere controles die het waard zijn om mee te nemen naast SPF, DKIM, DMARC en CAA wanneer je de DNS-configuratie van een domein doorlicht. Zie 20 DNS-beveiligingscontroles waar elk domein voor moet slagen voor de volledige lijst.
Het beheren van PTR-records is meestal een bijkomstigheid van het beheren van servers en mail bij meerdere providers, en daar wordt het rommelig: de ene host regelt reverse DNS via een supportticket, de andere via een schakelaar in het controlepaneel, en je verliest snel het overzicht welke IP-adressen echt een overeenkomend PTR-record hebben. Met DNS-beheer van InfraNest houd je records, delegatie en eigenaardigheden van providers zichtbaar vanuit één dashboard, zodat een ontbrekend of niet-overeenkomend PTR-record niet onopgemerkt blijft totdat je deliverability daalt.
Controleer het huidige PTR-record van elk IP-adres met de gratis DNS-lookuptool voordat je verder gaat met troubleshooten.
Veelgestelde vragen
#Wat gebeurt er als mijn server geen PTR-record heeft?
Veel ontvangende mailservers zien een ontbrekend PTR-record als spamsignaal en kunnen mail van dat IP-adres weigeren of in quarantaine plaatsen, zelfs als SPF en DKIM slagen. Buiten e-mail betekent een ontbrekend PTR-record vooral dat logs en diagnostiek een kaal IP-adres tonen in plaats van een hostnaam.
#Kan één IP-adres meerdere PTR-records hebben?
Technisch gezien wel: DNS staat meerdere PTR-records voor één IP-adres toe, maar best practice en de meeste mailfilters verwachten precies één canonieke hostnaam per IP-adres. Meerdere of inconsistente PTR-records zorgen er vaak voor dat forward-confirmed reverse DNS (FCrDNS)-controles mislukken.
#Heb ik reverse DNS nodig voor een website die geen e-mail verstuurt?
Nee, reverse DNS is vooral belangrijk voor uitgaande mailservers en voor netwerkdiagnostiek. Een server die alleen websites host en geen mail verstuurt, heeft in de praktijk weinig behoefte aan een aangepast PTR-record naast het standaardrecord dat je host toewijst.
#Waarom kan ik geen PTR-record instellen op mijn internetverbinding thuis?
Delegatie van reverse DNS volgt het eigendom van IP-adressen, en consumentenproviders zijn eigenaar van de adresblokken die aan klanten worden toegewezen in plaats van reverse zones aan hen te delegeren. Dat is een van de redenen waarom mailservers op dynamische IP-adressen thuis door spamfilters bijna altijd als hoog risico worden aangemerkt.
Probeer het met een gratis tool
Was dit artikel nuttig?
