Het domein staat bij iemand anders

De site is af. Nu moet hij op een adres komen dat al bestaat, waar al mail op binnenkomt, en waarvan iemand anders het wachtwoord heeft. Eén verkeerd gezette knop en je hebt niet de site stukgemaakt maar de mail.

Bijgewerkt 8 september 2026 · geen account, niets verlaat je toestel

De koppeling

Welke records moet ik zetten?

Vier vragen. De uitkomst zegt of je bij het huidige DNS-beheer kunt blijven, of dat je de nameservers moet verhuizen — en dat laatste is de stap waar de mail sneuvelt.

Welk adres moet de site dragen?

Waar staat de site?

Waar wordt de DNS van dit domein nu beheerd? Niet waar het domein gekocht is, maar wie de nameservers draait. Zie stap 1 van de diagnose als je het niet weet.

Komt er mail binnen op dit domein? Ook een enkele doorstuuradres telt. Bij twijfel: ja.

Waarom kan een CNAME niet op het kale domein?

Omdat de DNS-standaard het verbiedt. RFC 1034 zegt dat er naast een CNAME op een naam geen andere gegevens mogen staan, en op de top van een zone staan altijd al een SOA-record en de NS-records van de nameservers. Een CNAME daarnaast is dus per definitie ongeldig. RFC 2181 herhaalt dat nog eens expliciet.

Daarom bieden veel DNS-diensten een eigen truc aan: een ALIAS- of ANAME-record, of CNAME-flattening. Dat is geen echt DNS-recordtype maar een kunstgreep van die ene dienst — hij zoekt het doel voor je op en antwoordt met het IP-adres alsof er een A-record stond. Dat werkt alleen als jouw DNS-dienst het aanbiedt, en het is precies de reden dat de ene host wél en de andere níet op het kale domein kan zonder verhuizing.

De mail

Wat er mee moet als je de nameservers verhuist

Een nameserver-wissel is geen wijziging maar een vervanging. Je nieuwe DNS-dienst begint met een lege zone, en alles wat je niet overneemt bestaat vanaf dat moment niet meer. De meeste diensten scannen bij het toevoegen automatisch mee, maar ze vinden alleen wat ze kunnen raden: een DKIM-selector die ze niet kennen vinden ze niet.

Vraag daarom bij je huidige DNS-beheerder om een zone-export in plaats van naar het paneel te kijken. En vink hieronder af.

De reden dat dit misgaat is de vertraging.

Een kapotte site zie je binnen een minuut, want je kijkt ernaar. Kapotte mail merk je niet: jouw eigen post blijft gewoon werken zolang je client nog is ingelogd, en wat er misgaat is dat post van buiten nergens meer heen kan. De eerste die het merkt is iemand die je mailde en een bounce terugkreeg — en die belt niet meteen. Reken op dagen.

Daarom staat hierboven bij elk record wat de gebruiker merkt, en niet wat er technisch stukgaat.

De omschakeling

Hoe lang duurt het, en hoe kort kan het?

Een DNS-antwoord blijft in de caches van de wereld staan zolang de TTL zegt. Verlaag je die vóór de omschakeling, dan verkort je het venster waarin bezoekers nog de oude site zien — maar die verlaging heeft zelf ook de oude TTL nodig om overal aan te komen.

Wat is de TTL van het record dat je gaat wijzigen? Staat naast het record in je DNS-paneel. Twijfel je: 3600 is de meest voorkomende standaard.

Waar zet je hem tijdelijk naartoe?

Het doet niets

Vier vragen, in deze volgorde

Het adres laadt niet, of het laadt het verkeerde. De verleiding is om te wachten en het op propagatie te gooien. Doe dat pas als vraag 1 tot en met 4 een antwoord hebben, want drie van de vier oorzaken hieronder gaan vanzelf nooit over.

Staat het record er werkelijk, bij de nameserver die erover gaat?
Niet kijken in het paneel maar het antwoord opvragen bij de gezaghebbende nameserver zelf. Dat sluit elke cache-verklaring uit.
```
dig +short NS jouwdomein.nl
dig +short @<die-nameserver> www.jouwdomein.nl CNAME
```
Krijg je niets terug, dan is het record er niet — hoe stellig degene die het gezet heeft ook is. Het beslissende bewijsstuk is het serienummer van de zone: dat hoort bij elke publicatie op te lopen.
```
dig +short SOA jouwdomein.nl
```
Staat daar een datum van vóór de wijziging, dan is er niets gepubliceerd. Dat is geen verwijt: sommige beheerpanelen bewaren een wijziging pas bij een aparte publiceer- of activeer-stap, en tot die klik is er in de zone niets gebeurd. Met dit serienummer in de hand is dat gesprek een feit in plaats van een welles-nietes.
Weet de host van dit domein af?
De koppeling heeft twee kanten en ze moeten allebei staan. Wijst je DNS naar de host terwijl het domein daar niet is toegevoegd, dan krijg je een foutpagina van de host zelf — bij Cloudflare Pages een 522. Dat leest als een DNS-probleem terwijl de DNS juist klopt.

Andersom is de stillere variant: het domein staat wél bij de host, maar wacht op een DNS-record dat nooit komt. Zo'n wachtstand blijft niet eeuwig hangen — na weken ruimt de host hem op, en dan doet het correcte record dat later alsnog wordt gezet nog steeds niets. Zit je in een wachtstand die lang duurt, controleer dan altijd beide kanten voordat je concludeert dat de ander iets fout doet.
Is dit een certificaatfout of een DNS-fout?
Een waarschuwing over een onveilige verbinding betekent dat de DNS klopt: je bent aangekomen. Het certificaat voor een nieuw gekoppeld domein wordt pas aangevraagd nádat de host het record ziet, en dat duurt daarna nog even.

Zit het domein achter een proxy die je zelf aan of uit kunt zetten, kijk dan of hij aan staat. Een record dat rechtstreeks doorwijst in plaats van via de proxy geeft een certificaatfout die precies zo oogt.
Zit je vast in een negatieve cache?
Deze verklaart de gevallen waarin je het record aantoonbaar goed hebt gezet en het toch niet werkt. Een resolver onthoudt niet alleen antwoorden maar ook het ontbreken ervan. Heb je het adres opgevraagd vóórdat het record bestond, dan staat er «bestaat niet» in de cache, en dat blijft daar staan.

Hoe lang, bepaalt de zone zelf: het minimum uit het SOA-record. RFC 2308 zegt dat één tot drie uur goed werkt als standaard en dat waarden boven een dag problematisch blijken. Vergelijk daarom altijd een publieke resolver met de gezaghebbende nameserver:
```
dig +short @1.1.1.1 www.jouwdomein.nl
dig +short @<gezaghebbende-ns> www.jouwdomein.nl
```
Verschillen ze, dan is er niets stuk en hoef je alleen te wachten. Zijn ze gelijk en allebei leeg, dan ligt het probleem bij vraag 1.

Het eigenaarschap

Drie knoppen die steeds door elkaar worden gehaald

Bij elk account — de registrar, de DNS, de hosting, de mail — zijn dit drie losse instellingen. Ze worden meestal als één ding behandeld, en dat is precies waar sites zoekraken.

1. Op wiens naam staat het. Wie juridisch eigenaar is. Hoort de organisatie of de klant te zijn, nooit de bouwer. Dit is de enige knop die je niet later even omzet: verhuizen kost een verhuiscode en de medewerking van degene die er nu bij kan.

2. Waar wachtwoordherstel binnenkomt. Het accountadres. Hier gaat het bijna altijd mis, want dit staat vaak op het privéadres van degene die het account ooit aanmaakte. Verdwijnt die persoon, dan is het account onbereikbaar terwijl het gewoon op de juiste naam staat. Zet er een rolmailbox op die naar minstens twee mensen doorstuurt.

3. Wie er dagelijks inlogt. Het beheer. Dit mag prima één persoon zijn — jij, of een vrijwilliger — zolang knop 1 en 2 kloppen. Een gedeeld wachtwoord dat ooit in een vergadering is doorgegeven regelt de bereikbaarheid, niet de borging: het hangt aan een persoon en niet aan een rol.

Hangt dit nog aan jou?

Vijf vragen. De toets die eronder ligt is simpel: kan iemand anders dit overnemen zonder jou te bellen?

Misvattingen

Zes dingen die vaker niet dan wel kloppen

«Ik moet de nameservers verhuizen om de site te koppelen.» Bijna nooit. Voor www en elk ander subdomein volstaat één CNAME in het bestaande paneel. Verhuizen is alleen nodig als je host het kale domein niet anders aankan, en zelfs dan is er een uitweg: laat het kale domein doorsturen naar www. Dat is bij de meeste registrars een instelling van één regel en het raakt de mail niet.

«Verhuizen naar een andere DNS-dienst raakt mijn mailbox.» Je mailbox verhuist niet mee — die staat bij je mailprovider en blijft daar. Wat verhuist is de wegwijzer ernaartoe. Neem je de MX-records mee, dan verandert er niets aan je mail; vergeet je ze, dan blijft je mailbox intact terwijl niemand hem nog kan bereiken.

«Propagatie duurt 24 tot 48 uur.» Dat is geen wet maar de TTL die jij zelf hebt ingesteld. Nieuwe bezoekers die het adres nog nooit hebben opgevraagd, krijgen het nieuwe antwoord meteen. Wat wacht is de cache van wie er al was — dus precies de duur van je TTL, niet meer.

«Het IP-adres van mijn host haal ik uit een handleiding.» Voor sommige hosts geldt dat inderdaad, maar niet meer overal. Vercel geeft per project een eigen CNAME-doelwaarde, en de oude adressen uit blogposts zijn niet automatisch nog de jouwe. Neem de waarde over die op je eigen dashboard staat.

«De registrar is de partij die mijn DNS doet.» Alleen als je hem daarvoor gebruikt. Waar het domein gekocht is en wie de nameservers draait, zijn twee losse dingen — en ze zitten vaak bij twee verschillende bedrijven. Zet je een record bij de registrar terwijl de nameservers elders staan, dan gebeurt er precies niets, zonder foutmelding.

«Het staat goed, het moet alleen nog propageren.» De helft van de keren is dit waar en dan lost het zichzelf op. De andere helft dekt het een record dat nooit gepubliceerd is, een host die niets van je domein weet, of een negatieve cache. Alle drie gaan ze nooit vanzelf over. Dat is waarom de diagnose hierboven met het serienummer van de zone begint en niet met wachten.

Bronnen. CNAME-beperking: RFC 1034 §3.6.2 en RFC 2181 §10.1. Negatieve caching en het SOA-minimum: RFC 2308 §5. Recordwaarden per host: de eigen documentatie van Cloudflare Pages, Netlify, Vercel en GitHub Pages, geraadpleegd 8 september 2026. Google Workspace adviseert sinds 2023 één MX-record naar smtp.google.com met prioriteit 1; oudere domeinen hebben de vijf records die met aspmx beginnen, en die blijven werken.

De IP-adressen en CNAME-doelen op deze pagina zijn een hulpmiddel om te herkennen wát je zoekt, geen vervanging van het dashboard van je eigen host. Verandert er iets, dan verandert het daar het eerst.