Een DNS-record is een regeltje dat vertelt waar iets van jouw domein te vinden is: een A-record wijst je website naar een server, een MX-record vertelt waar je mail naartoe moet, een CNAME is een doorverwijzing naar een andere naam, en een TXT-record bevat losse tekst voor zaken als spamcontrole en verificaties. Die records beheer je bij de partij waar je nameservers staan. Meer is het in de kern niet — maar omdat één verkeerde wijziging je site of mail plat kan leggen, loont het om precies te weten wat er staat voordat je iets aanpast.
Dit artikel is voor iedereen die van z'n webbouwer, mailpartij of hoster te horen kreeg: "even een DNS-record aanpassen." Na het lezen weet je wat elk recordtype doet, waar je moet zijn, en welke drie fouten je absoluut moet vermijden.
Wat DNS eigenlijk doet
Computers werken niet met namen maar met IP-adressen: nummerreeksen zoals 85.10.152.51. Niemand wil die onthouden, dus bestaat DNS: het systeem dat namen vertaalt naar adressen.
Vergelijk het met de contactenlijst in je telefoon. Jij tikt op "mam", je telefoon zoekt het bijbehorende nummer op en belt dat. Typ jij jouwbedrijf.nl in je browser, dan zoekt die via DNS het IP-adres op en maakt daar verbinding mee. Verhuist je site naar een andere server, dan pas je alleen dat "telefoonnummer" aan — de naam blijft hetzelfde en niemand hoeft iets nieuws te onthouden.
Het verschil met je contactenlijst: DNS is openbaar en wereldwijd. Elke internetprovider en elk apparaat kan jouw records opvragen. En omdat al die partijen antwoorden een tijdje onthouden (daarover straks meer bij TTL), werkt een wijziging niet altijd meteen overal.
Waar beheer je je DNS-records?
Dit is het punt waarop de meeste verwarring ontstaat, dus laten we het meteen rechtzetten: je beheert je DNS-records bij de partij waar je nameservers naartoe wijzen — en dat is niet per se de partij waar je je domeinnaam hebt geregistreerd.
Het zit zo. Je domein is geregistreerd bij een registrar (waar je de jaarlijkse factuur van krijgt). Die registrar heeft in het centrale register vastgelegd welke nameservers de dienst uitmaken over jouw domein. Wijzen die nameservers naar je registrar zelf, dan beheer je je records daar. Maar wijzen ze naar je hoster, naar Cloudflare of naar een andere DNS-dienst, dan moet je dáár zijn — inloggen bij je registrar heeft dan geen zin, want wat je daar aanpast, wordt door niemand gebruikt.
Weet je niet waar je nameservers staan? Zoek je domein op met een online lookup-tool (zie verderop) en bekijk de NS-records. De naam die daar staat, verraadt meestal direct welke partij het is.
De belangrijkste recordtypes in mensentaal
A-record: naam naar server
Het A-record koppelt een naam aan het IP-adres van een server. Dit is het record dat bepaalt waar je website draait.
Voorbeeld: jouwbedrijf.nl → A → 85.10.152.51. Typ iemand jouw domein in, dan komt hij uit op de server met dat adres. Meestal heb je er twee: één voor het kale domein (jouwbedrijf.nl) en één voor www.jouwbedrijf.nl — of die tweede is een CNAME, zie hieronder.
Er bestaat ook een AAAA-record: precies hetzelfde, maar dan voor het nieuwere IPv6-adres (zo'n lange reeks met dubbele punten, bijvoorbeeld 2a01:7c8:...). Heeft je server IPv6, dan staan A en AAAA netjes naast elkaar. Heb je alleen een A-record, dan werkt je site ook prima.
Verhuist je website? Dan is het A-record (en eventueel AAAA) wat er aangepast moet worden. Niets anders.
CNAME-record: alias van een andere naam
Een CNAME zegt niet "ga naar dit IP-adres" maar "deze naam is hetzelfde als die andere naam — zoek dáár verder."
Voorbeeld: www.jouwbedrijf.nl → CNAME → jouwbedrijf.nl. Vraagt iemand het adres van www op, dan krijgt hij te horen: kijk bij het kale domein. Verhuist je site en pas je het A-record van het kale domein aan, dan verhuist www automatisch mee. Dat is het gemak van een CNAME: één plek aanpassen in plaats van twee.
Ook handig voor externe diensten: shop.jouwbedrijf.nl → CNAME → shops.externeleverancier.com. Verandert die leverancier van server, dan hoef jij niets te doen.
Eén belangrijke beperking: een CNAME mag niet op de apex staan — het kale domein zelf, dus jouwbedrijf.nl zonder iets ervoor. Op de apex moeten namelijk ook andere records staan (zoals je MX- en NS-records), en de DNS-regels zeggen: waar een CNAME staat, mag niets anders staan. Die twee bijten elkaar. Daarom krijg je bij de meeste DNS-beheerders een foutmelding als je het probeert. Gebruik voor de apex gewoon een A-record.
MX-record: waar gaat de mail heen
Het MX-record vertelt de rest van de wereld waar e-mail voor jouw domein afgeleverd moet worden. Stuurt iemand een bericht naar info@jouwbedrijf.nl, dan kijkt zijn mailserver naar jouw MX-records en levert het bericht daar af.
Voorbeeld: jouwbedrijf.nl → MX → 10 mail.jouwhoster.nl. Dat getal (10) is een prioriteit: heb je meerdere MX-records, dan wordt de laagste eerst geprobeerd.
Het allerbelangrijkste om te onthouden: je MX-records staan volledig los van waar je website draait. Je site kan bij hoster A staan en je mail bij Microsoft 365, Google Workspace of een andere mailpartij. Dat is heel gebruikelijk. Het betekent ook: als je website verhuist, hoeven je MX-records niet mee — en móéten ze vaak juist blijven staan zoals ze staan. Hierover straks meer bij de gevaarlijkste fouten, want dit is dé plek waar het misgaat.
TXT-record: losse tekst met een functie
Een TXT-record is letterlijk een stukje tekst dat aan je domein hangt. Klinkt onbenullig, maar er hangen belangrijke dingen aan:
- SPF — een tekstregel als
v=spf1 include:mail.jouwhoster.nl -alldie vertelt welke servers namens jouw domein mail mogen versturen. Ontbreekt of klopt die niet, dan belandt je mail sneller in de spam. - Verificaties — regels als
google-site-verification=...ofMS=ms12345678. Daarmee bewijs je aan Google, Microsoft of een andere dienst dat jij de eigenaar van het domein bent. - DKIM en DMARC — technische handtekeningen en beleidsregels voor mail, meestal op subdomeinen als
default._domainkeyen_dmarc.
Herken je een TXT-record niet? Laat het staan. Die cryptische regel is vrijwel altijd ooit met een reden toegevoegd, en het verwijderen ervan kan een koppeling of je mailbezorging breken zonder dat je het meteen merkt.
NS-record: wie is hier de baas
NS-records wijzen aan welke nameservers jouw hele domein beheren. Voorbeeld: jouwbedrijf.nl → NS → ns1.jouwhoster.nl en ns2.jouwhoster.nl.
Dit is het zwaarste record van allemaal. Wijzig je je NS-records, dan verplaats je niet één instelling maar het beheer van alles: je A-records, MX-records, TXT-records — de complete zone verhuist naar de nieuwe partij. Vanaf dat moment telt alleen nog wat dáár staat. Alles wat bij de oude partij stond en niet is overgenomen, bestaat effectief niet meer.
Daarom geldt: nooit nameservers wijzigen zonder dat de nieuwe zone eerst compleet is opgebouwd. Eerst alle records overzetten en controleren, dán pas de NS-wijziging doorvoeren.
TTL: hoe lang de wereld je oude antwoord onthoudt
Elk record heeft een TTL (time to live): het aantal seconden dat servers wereldwijd het antwoord mogen onthouden voordat ze opnieuw komen vragen. Een TTL van 3600 betekent: een uur onthouden. 86400 is een etmaal.
Dat onthouden is nuttig — het maakt internet snel en ontlast de nameservers — maar het heeft een keerzijde: wijzig je een record met een TTL van 24 uur, dan kunnen bezoekers en mailservers nog tot 24 uur het óúde antwoord gebruiken. De één ziet je nieuwe site al, de ander nog de oude. Dat is de "uitrol-tijd" waar je hoster het over heeft.
De truc: verlaag de TTL vóór een geplande wijziging. Zet hem een dag van tevoren op bijvoorbeeld 300 seconden (5 minuten). Tegen de tijd dat je de echte wijziging doorvoert, is de oude, lange onthoudtermijn overal verlopen en pikt iedereen je wijziging binnen minuten op. Gaat er iets mis, dan draai je het ook binnen minuten terug. Na afloop zet je de TTL weer op een normale waarde.
De drie gevaarlijkste fouten
In twintig jaar hosting zie je alle DNS-ongelukken voorbijkomen. Deze drie richten de meeste schade aan:
1. MX-records wissen of meenemen bij een sitemigratie
De klassieker. Een website verhuist naar een nieuwe hoster, iemand richt daar de DNS in "zoals het hoort" — en zet de MX-records naar de mailserver van de nieuwe hoster, of vergeet ze helemaal. Alleen: de mail van dat bedrijf draaide helemaal niet bij de oude hoster, maar bij Microsoft 365 of een aparte mailpartij. Resultaat: de site doet het prima, maar de mail komt aan op een server waar geen mailboxen bestaan. Berichten stuiteren of verdwijnen, en vaak merkt de eigenaar het pas na dagen — "het is zo stil in mijn inbox."
Uit de praktijk: dit is verreweg de vaakst voorkomende DNS-schade die ik voorbij zie komen. Daarom controleer ik bij elke migratie éérst waar de MX-records heen wijzen voordat er ook maar één record wordt aangepast. Wijzen ze naar een externe mailpartij, dan blijven ze exact zo staan in de nieuwe zone. De regel is simpel: een sitemigratie gaat over A-records, niet over MX-records.
2. Nameservers wijzigen terwijl de nieuwe zone niet compleet is
Zoals hierboven beschreven: een NS-wijziging verplaatst álles. Wie de nameservers omzet terwijl bij de nieuwe partij alleen een A-record voor de website is aangemaakt, gooit in één klap zijn MX-records, SPF, verificaties en subdomeinen weg. Bouw eerst de complete zone op — record voor record vergeleken met de oude — en zet dan pas de nameservers om.
3. Records "opruimen" die je niet herkent
Een DNS-zone die al jaren meedraait, ziet er rommelig uit: cryptische TXT-regels, CNAME's naar diensten waarvan niemand meer weet wat ze doen, subdomeinen die nergens naar lijken te verwijzen. De verleiding om op te schonen is begrijpelijk — en bijna altijd een slecht idee. Die vage TXT-regel is de verificatie waarmee je Google Workspace draait. Die onbekende CNAME houdt je nieuwsbrieftool in de lucht. Verwijderen kost twee seconden; erachter komen wat er kapot is gegaan kost soms dagen. Wil je écht opruimen, zoek dan per record uit waarvoor het dient, of vraag het na bij je hoster.
Zo bekijk je je huidige records
Voordat je iets wijzigt, wil je weten wat er nú staat. Dat kan zonder ergens in te loggen, met een gratis online lookup-tool. Bekende opties zijn dnschecker.org en mxtoolbox.com — vul je domeinnaam in en kies het recordtype dat je wilt zien.
Een praktische controleroutine voor je aan een wijziging begint:
- NS-records — welke partij beheert de zone? Daar moet je zijn om iets te wijzigen.
- A-record (van het kale domein én van www) — waar draait de site nu?
- MX-records — waar draait de mail? Is dat dezelfde partij als de site, of een andere? Schrijf dit op.
- TXT-records — welke SPF- en verificatieregels staan er? Maak een kopie (screenshot of tekstbestand) van de complete zone voordat je iets aanraakt.
Die kopie vooraf is je verzekering: gaat er iets mis, dan weet je exact hoe het stond.
Samengevat
DNS is geen tovenarij: A-records voor je site, MX-records voor je mail, CNAME's als doorverwijzing, TXT voor tekstregels met een functie, en NS-records die bepalen wie het geheel beheert. De vuistregels: wijzig alleen wat bij je klus hoort, blijf van de MX-records af bij een siteverhuizing, verlaag de TTL vóór een geplande wijziging, en verwijder nooit iets dat je niet kunt thuisbrengen.
Twijfel je waar je moet zijn of wat een record doet? Kijk eerst met een lookup-tool en maak een kopie van je zone voordat je iets aanpast.