Defaults.Exposed › Oplossingen › Reverse DNS (PTR)

Hoe je Reverse DNS (PTR) oplost

Reverse DNS is het identiteitsbewijs voor de server die de e-mail van uw bedrijf verstuurt. Wanneer een ontvangende provider als Gmail of Microsoft 365 opzoekt wie er achter het verzendadres zit en een naam krijgt die klopt, ziet uw post er legitiem uit. Ontbreekt dat bewijs — of komen de naam en het getal niet overeen — dan worden uw volkomen echte facturen en offertes als verdacht behandeld en stilletjes weggegooid of geweigerd.

De kern voor je bedrijf: Uw facturen, offertes en klantantwoorden belanden stilletjes in de spam of komen helemaal niet aan — dus deals stranden, betalingen komen laat binnen en klanten denken dat u ze negeerde, en niets daarvan verschijnt als een fout die u zou opmerken.

Wat dit je kan kosten

U stuurt een offerte naar een hete prospect, die belandt in hun spam, en ze kiezen de concurrent die «echt reageerde» — en u wist niet eens dat de e-mail niet aankwam.
Facturen aan klanten verdwijnen in de spam, betalingen komen weken te laat, en uw cashflow krijgt de klap omdat niemand de e-mail ooit zag.
Een klant klaagt dat u nooit terugkwam — maar dat deed u wel; hun mailprovider gooide uw antwoord stilletjes weg omdat uw verzendende server niet kon bewijzen wie hij was.
Uw domein slaagt bij de beveiligingsbeoordeling van een nieuwe klant op alles, en wordt dan gemarkeerd omdat uw mailserver geen behoorlijke identiteit heeft — een kleinigheid die u slordig doet lijken.
U bent overgestapt op een goedkope VPS of een nieuwe app om uw nieuwsbrieven en facturen te versturen, en van de ene op de andere dag daalt uw afleverpercentage — omdat die nieuwe verzendserver geen reverse-DNS-bewijs heeft en de grote providers hem niet meer vertrouwen.

Waarom het ertoe doet. Elke grote e-mailprovider controleert de identiteit van de server die uw mail verstuurt, en ze controleren die bij elk bericht. Kan die server niet bewijzen wie hij is — of spreken zijn naam en zijn getal elkaar tegen — dan wordt uw echte zakelijke e-mail behandeld alsof het spam zou kunnen zijn. U verliest antwoorden, betalingen en vertrouwen, en omdat niets bouncet komt u meestal nooit te weten waarom.

De korte versie

Wanneer uw bedrijf een e-mail verstuurt, vertrekt die vanaf een mailserver, en elke server op het internet heeft een numeriek adres — zijn IP. Reverse DNS (een «PTR»-record) is het naambordje van die server: het laat iedereen die het getal ziet de juiste naam erachter opzoeken, zoals mail.uwbedrijf.com.

De grote ontvangende providers — Gmail, Microsoft 365, Yahoo — controleren dat bordje bij elk bericht dat u verstuurt. Een server die zichzelf kan benoemen, en waar de naam en het getal met elkaar overeenkomen, ziet eruit als een legitieme mailserver. Een server zonder bordje, of met een bordje dat niet klopt, ziet eruit als precies de anonieme, wegwerpmachines die spammers gebruiken. Dus uw echte facturen en offertes beginnen elk gesprek onder verdenking — en veel ervan verliezen.

Het frustrerende is dat niets u vertelt dat het gebeurt. Geen bounce, geen fout. Uw e-mail presteert gewoon stilletjes onder de maat.

Wat dit u kan kosten

Dit zijn de alledaagse manieren waarop een ontbrekend of niet-overeenkomend reverse-DNS-record verandert in geld en vertrouwen dat de deur uit loopt. We noemen nooit een echt bedrijf — dit zijn patronen die we in de data zien.

De offerte die nooit aankwam. U mailt een gedetailleerde offerte naar een prospect die er die ochtend om vroeg. Hun provider kan uw verzendende server niet verifiëren, dus die zet het bericht in de spam. Ze spitten de spam niet door. Tegen de middag hebben ze de offerte van de concurrent aangenomen — die «echt opdook». U schrijft het af als een trage lead; in werkelijkheid werd uw e-mail nooit gezien.
De factuur in het luchtledige. U factureert een goede klant. Die belandt in hun spammap. Dertig dagen later jaagt u een betaling na die achterstallig is buiten hun schuld — en nu is er een ongemakkelijk gesprek, een gespannen relatie, en een cashflowgat dat volledig vermijdbaar was.
«U heeft nooit gereageerd.» Een klant is geïrriteerd dat u zijn vraag negeerde. Dat deed u niet — u antwoordde dezelfde dag. Hun mailprovider gooide uw antwoord stilletjes weg omdat uw verzendende server onbetrouwbaar leek. U lijkt onprofessioneel voor iets wat u juist goed deed.
De doe-het-zelf verzendserver die stilletjes alles vergiftigde. Om geld te besparen ging uw mail (of alleen uw nieuwsbrieven en geautomatiseerde facturen) uit via een goedkope VPS of een nieuwe verzend-app. Die server kreeg nooit een reverse-DNS-bordje. Van de ene op de andere dag zakte uw afleverpercentage over de hele linie — en omdat er geen foutmelding is, duurde het maanden om de oorzaak ook maar te vermoeden.
De vlag bij de beveiligingsbeoordeling. De IT-afdeling van een grotere klant doet een routinecontrole op uw domein tijdens de onboarding. Al het andere is in orde, maar uw mailserver heeft geen behoorlijke identiteit. Het is een klein technisch puntje, maar het leest als slordigheid — en nu lost u het onder tijdsdruk op, of praat u het weg, terwijl het domein van een concurrent net glansrijk slaagde.

De rode draad door dit alles: de kosten landen bij u, het is onzichtbaar terwijl het gebeurt, en de oplossing is gratis.

Wat het eigenlijk is

Normale DNS zet een naam om in een getal: u typt uwbedrijf.com, en DNS geeft het IP-adres terug om mee te verbinden. Reverse DNS doet het omgekeerde — het zet een getal terug om in een naam. Gegeven het IP 203.0.113.10 antwoordt een reverse lookup (een «PTR-record») mail.uwbedrijf.com.

Waarom ontvangers het belangrijk vinden: wanneer uw mailserver verbinding maakt met Gmail om een bericht af te leveren, ziet Gmail het verbindende IP. Het eerste wat een serieus mailfilter doet is vragen «wie is deze machine?» — door een reverse lookup op dat IP te doen. Een echte zakelijke mailserver heeft een antwoord (mail.uwbedrijf.com). Een wegwerp-spammachine heeft dat meestal niet, of heeft een generieke, door de provider toegewezen naam zoals host-203-0-113-10.eenisp.net. Dus de aanwezigheid en kwaliteit van het bordje is een van de allereerste vertrouwenssignalen die op uw mail worden toegepast — nog voordat SPF, DKIM of de berichtinhoud ook maar een blik krijgen.

Het controleert de mailserver, niet uw website. Hier struikelen mensen over. Het adres van uw website zit vaak achter een CDN of proxy (zoals Cloudflare) en zal nooit een overeenkomend bordje hebben — en dat is prima, want reverse DNS voor e-mail gaat over het IP van de MX-mailserver, een totaal aparte machine. Deze controle zoekt correct de primaire mailserver van uw domein op (het MX-record met de laagste prioriteit), herleidt die tot zijn IP, en controleert het bordje op dat IP.

De helft die de meeste opzetten verkeerd doen: het moet in beide richtingen kloppen. Een naam hebben is op zichzelf niet genoeg. Gmail en de andere grote filters doen iets strikters, genaamd forward-confirmed reverse DNS (FCrDNS):

Zoek het IP op → krijg een naam (bijv. mail.uwbedrijf.com).
Zoek nu die naam terug op → die moet herleiden naar hetzelfde IP waar u begon.

Komen de twee richtingen overeen, dan is de server bevestigd en volledig vertrouwd. Is er een naam maar wijst die elders heen (of nergens), dan is de server maar half vertrouwd — een bordje dat een tweede blik niet overleeft, wordt zwakker behandeld dan u zou hopen. Een PTR die wijst naar een hostnaam die een aanvaller beheert, en die niet terug herleidt, is in sommige opzichten erger dan geen PTR.

Precies zo scoort deze controle het:

Forward-confirmed (FCrDNS): het IP benoemt een host, en die host wijst terug naar hetzelfde IP. Volle punten — dit is correcte configuratie, en het is wat ontvangers vertrouwen.
Bordje bestaat maar bevestigt niet: er is een PTR-record, maar de naam herleidt niet terug naar het IP van de mailserver. Alleen gedeeltelijk krediet — het lijkt geconfigureerd maar de grote filters vertrouwen het niet volledig.
Helemaal geen bordje: geen PTR-record op het IP van de mailserver. Geen krediet, en de afleverbaarheidskosten zijn reëel.

Een opmerking over gewicht: in de methodologie is dit een gescoorde e-mailbeveiligingscontrole (25 punten waard, een P2-prioriteitsitem). Het is niet de zwaarst wegende e-mailcontrole — dat zijn SPF en DMARC, die regelrechte nabootsing stoppen — maar het is een echt, beoordeeld onderdeel van uw e-mailstatus, en een van de weinige die afhangt van of uw provider iets goed doet in plaats van u. Als u alleen via Google Workspace of Microsoft 365 verstuurt, slaagt u vrijwel zeker al; de bedrijven die falen zijn degene die via hun eigen of een externe server versturen.

Hoe «goed» eruitziet: het IP van uw primaire mailserver heeft een PTR-record dat wijst naar een echte hostnaam die u bezit, en die hostnaam herleidt rechtstreeks terug naar hetzelfde IP — de twee richtingen komen overeen (FCrDNS bevestigd).

Hoe los je het op (gratis, ~10 minuten van iemands tijd)

Geef dit onderdeel aan wie het IP-adres van uw mailserver bezit — meestal uw e-mail- of hostingprovider, of uw datacenter voor een zelfgehoste box — en merk op dat de oplossing gratis is. Dit is de ene e-mailinstelling die u vrijwel zeker niet zelf kunt wijzigen in uw normale DNS-paneel, omdat reverse DNS wordt beheerd door wie het IP bezit, niet door wie het domein bezit. Wij rekenen alleen kosten om te bewaken dat het correct blijft, nooit om de wijziging te maken.

Stap 1 — Vind het IP van de verzendende mailserver. Identificeer de primaire MX-host van het domein (de mailserver met het laagste prioriteitsgetal) en herleid die tot zijn IP-adres:

dig MX uwbedrijf.com        # vind de primaire (laagste-prioriteit) MX-host
dig A mail.uwbedrijf.com    # herleid die host tot zijn IP

Dat IP is degene die het bordje nodig heeft. Gebruik niet het IP van de website — dat is een andere machine en vaak achter een CDN die nooit zal overeenkomen.

Stap 2 — Vraag de IP-eigenaar het PTR-record in te stellen. Reverse DNS leeft bij wie het IP-blok beheert, dus het verzoek gaat naar:

Google Workspace / Gmail: automatisch beheerd voor Google’s eigen mailservers — als een domein dat alleen via Google verstuurt op de een of andere manier als falend wordt getoond, kaart het aan bij Google-support. (In de praktijk slagen deze.)
Microsoft 365: eveneens automatisch beheerd voor Microsoft’s servers.
Een zelfgehoste of VPS-mailserver: open een ticket bij uw hostingprovider of datacenter met het verzoek de PTR (reverse DNS) voor uw IP in te stellen op uw mailhostnaam. De meeste providers stellen dit beschikbaar in hun configuratiescherm onder «Reverse DNS», «rDNS» of «PTR». Bij de grote clouds is het een instelling van één veld (bijv. AWS vereist een kort aanvraagformulier om rDNS op een Elastic IP in te schakelen; de meeste VPS-hosts laten u het direct instellen).
Een externe verzend-app (nieuwsbrief- / facturatie- / CRM-tool): als die vanaf zijn eigen gedeelde servers verstuurt, regelt de provider reverse DNS — er is niets voor u om in te stellen, en u kunt dit voor dat verkeer negeren. Verstuurt die vanaf een dedicated IP dat u bij hen kocht, vraag dan of ze de PTR erop instellen.

Vertel hun welk record u wilt, bijvoorbeeld: 203.0.113.10 → mail.uwbedrijf.com.

Stap 3 — Laat het forward-confirmen (dit is de stap die de meeste mensen missen). De hostnaam in de PTR moet ook terug herleiden naar hetzelfde IP via een normaal A-record dat u beheert in uw eigen DNS. Dus:

De PTR zegt 203.0.113.10 → mail.uwbedrijf.com (uw provider stelt dit in).
Het A-record zegt mail.uwbedrijf.com → 203.0.113.10 (u stelt dit in uw DNS in, bijv. Cloudflare → DNS → voeg een A-record toe, Name mail, content 203.0.113.10).

Beide richtingen moeten naar elkaar wijzen. Pas dan is het forward-confirmed en volledig vertrouwd.

Stap 4 — Controleer uw domein opnieuw. Bevestig dat de mailserver nu forward-confirmed reverse DNS toont en de controle slaagt. DNS-wijzigingen propageren binnen enkele minuten tot een paar uur.

Veelgemaakte fouten

Het bordje op het IP van de website zetten in plaats van dat van de mailserver. Reverse DNS voor e-mail gaat over de MX-server. Een PTR op uw web-/CDN-adres zetten doet niets voor de afleverbaarheid — de verkeerde machine krijgt het bordje.
Stoppen bij «de PTR bestaat». Een naam op zichzelf verdient maar gedeeltelijk vertrouwen. Herleidt die niet terug naar hetzelfde IP, dan vertrouwen de strikte filters (Gmail, M365, Yahoo) het niet volledig. Voltooi altijd de forward-confirmation (Stap 3).
Het A-record vergeten nadat de provider de PTR instelt. De provider stelt de reverse-helft in; u moet de forward-helft in uw eigen DNS instellen. Mensen doen er één en denken dat ze klaar zijn.
De verkeerde partij benaderen. Het verzoek naar uw domeinregistrar of DNS-host sturen in plaats van de IP-eigenaar levert «dat kunnen wij niet doen» op — want dat kunnen ze echt niet. Het moet naar wie het IP bezit.
Generieke providerhostnamen. Een PTR als host-203-0-113-10.eenisp.net bestaat technisch maar doet niets voor uw merk of vertrouwen. Gebruik een echte hostnaam op uw eigen domein die forward-confirmt.

Waar dit past

Reverse DNS is de identiteit van de server; SPF, DKIM en DMARC zijn de autorisatie- en anti-nabootsingslaag van het domein. Ze beantwoorden verschillende vragen, en de grote providers controleren ze allemaal. SPF somt op welke services namens u mogen versturen; DKIM ondertekent uw berichten cryptografisch zodat er niet mee kan worden geknoeid; DMARC koppelt de twee aan elkaar en vertelt ontvangers wat te doen met mail die faalt — en beschermt de zichtbare «van»-naam die uw klanten daadwerkelijk zien. Reverse DNS zit onder dit alles en staat ervoor in dat de machine die verstuurt überhaupt een echte, benoemde mailserver is. Krijg SPF, DKIM en DMARC goed voor de sterkste nabootsingsverdediging; krijg reverse DNS goed zodat een nieuwe of zelfgehoste verzendserver niet stilletjes wordt gewantrouwd nog voordat de rest een kans krijgt. Elk van deze oplossingen is gratis.

Veelgestelde vragen

Ik ben niet technisch — kan ik dit zelf regelen?

Meestal niet, en dat is prima. Anders dan de meeste e-mailinstellingen wordt deze niet gewijzigd in de DNS van uw eigen domein — hij wordt ingesteld door wie het internetadres (het IP) van uw mailserver bezit, namelijk uw e-mail- of hostingprovider. Uw taak is simpelweg hun het onderdeel «Hoe los je het op» door te sturen. Het is een snelle wijziging aan hun kant, en het is gratis.

Als ik Google Workspace of Microsoft 365 gebruik, ben ik dan al gedekt?

Vrijwel zeker ja — beide beheren reverse DNS automatisch voor hun eigen mailservers, dus een domein dat alleen via hen verstuurt slaagt hiervoor zonder dat u iets doet. Als onze controle het toch markeert, betekent het bijna altijd dat een deel van uw mail via een andere server uitgaat (uw eigen box, een goedkope VPS, of een externe verzend-app), en dat die server zijn bewijs mist. Het oplossingsonderdeel legt uit wie u moet benaderen.

Kan dit oplossen mijn e-mail breken?

Nee. Dit voegt alleen het identiteitsrecord van de verzendende server toe of corrigeert het — het verandert niet waar uw mail heen gaat, wie hem mag versturen, of een van uw inboxinstellingen. Het maakt de e-mail die u al verstuurt simpelweg waarschijnlijker om vertrouwd en afgeleverd te worden.

Wat is het verschil tussen dit en SPF, DKIM en DMARC?

Die drie beantwoorden «mag dit domein dit bericht versturen?» Reverse DNS beantwoordt een andere, eerdere vraag: «is de machine die verstuurt een echte, identificeerbare mailserver, of een anonieme box?» Grote providers controleren beide. U wilt ze allemaal goed — maar reverse DNS is degene die een gloednieuwe of zelfgehoste verzendserver opvangt nog voordat SPF en DKIM in beeld komen.

We hebben een reverse-DNS-record maar de controle slaagt nog steeds niet volledig — waarom?

Omdat een naam hebben niet genoeg is; de naam moet in beide richtingen kloppen. Het bewijs zegt dat de server bijvoorbeeld mail.uwbedrijf.com heet — maar Gmail zoekt die naam vervolgens op en verwacht dat die rechtstreeks naar exact hetzelfde IP terugwijst. Doet hij dat niet (of wijst hij elders heen), dan behandelen de providers het als onbevestigd en vertrouwen het maar half. Deze tweerichtingsovereenkomst heet forward-confirmed reverse DNS, en het is het deel dat de meeste opzetten missen.

Is de oplossing echt gratis, of is dit een betaalde upsell?

De oplossing is altijd gratis — het is een kleine configuratiewijziging gemaakt door uw provider, geen product dat u koopt. Wie u vertelt dat reverse DNS instellen een betaald abonnement vereist, heeft het mis. Wij rekenen alleen kosten om te bewaken dat het in de loop van de tijd correct blijft, nooit om de wijziging te maken.