DNS-records uitgelegd: A, CNAME, MX, TXT en CAA goed instellen

DNS-records zijn de regels in de zone van je domein die het internet vertellen waar de website staat (A, AAAA), welke naam een alias is van een andere (CNAME), waar de mail naartoe gaat (MX) en welke teksten het eigendom bewijzen of de mail beschermen (TXT, CAA). Alleen de records op de nameservers waar de NS-records van je domein naar wijzen tellen mee. Pas ze dus daar aan, in het paneel van je DNS-hosting of registrar, en controleer het resultaat met dig voordat je ergens op gaat wachten.

Hoe DNS een domeinnaam omzet in een adres

Als je example.com in de adresbalk typt, gebeurt het volgende:

1. Browser en besturingssysteem kijken eerst in hun eigen cache.
2. De vraag gaat naar een recursieve resolver: de DNS-server van je internetprovider of een publieke, zoals 8.8.8.8 of 1.1.1.1.
3. Heeft de resolver het antwoord niet in de cache, dan vraagt hij het aan de rootservers, daarna aan de servers van het topleveldomein (.com) en ten slotte aan de gezaghebbende servers uit de NS-records van het domein.
4. De gezaghebbende server geeft het A- of AAAA-record terug met de TTL: het aantal seconden dat de resolver het antwoord mag bewaren.
5. De browser maakt verbinding met dat IP-adres en laadt de pagina.

Klopt een van deze records niet, dan krijgt de browser een verkeerd adres of helemaal geen. Een typisch symptoom is de fout DNS_PROBE_FINISHED_NXDOMAIN: volgens de resolver bestaat de naam dan niet.

De belangrijkste recordtypes en wanneer je ze nodig hebt

Deze records vind je in vrijwel elk DNS-paneel. De voorbeeldwaarden gebruiken adressen die voor documentatie zijn gereserveerd.

Vaak kun je records op twee plekken bewerken: bij de registrar waar je het domein kocht en bij je hostingprovider. Alleen de zone op de nameservers uit de NS-records wordt gebruikt; wijzigingen elders hebben geen effect. Verhuis je de DNS, kopieer dan eerst alle records naar de nieuwe zone en wijzig daarna de nameservers van het domein. Voor het registreren van een domeinnaam kun je terecht op onze domeinenpagina.

Records controleren met dig: wat we op 30-10-2026 zagen

dig (Linux, macOS, Windows via WSL of de BIND-tools) laat precies zien wat een resolver teruggeeft; op Windows werkt ook nslookup. Deze commando’s dekken alle types uit de tabel:

dig A example.com +short
dig AAAA example.com +short
dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig CAA google.com +short
dig SRV _submission._tcp.gmail.com +short
dig NS example.com +short
dig A example.com @8.8.8.8 +noall +answer
nslookup -type=mx example.com

Dezelfde queries hebben we op 30-10-2026 uitgevoerd via Google Public DNS. Ingekort resultaat:

Er vallen drie dingen op. example.com publiceert een null-MX (0 .), de manier uit RFC 7505 om aan te geven dat een domein geen mail accepteert, plus SPF met -all en een strikt DMARC-beleid: de gebruikelijke instelling voor een domein dat nooit mail verstuurt. Naast SPF staat er een tweede TXT-record met een verificatietoken; meerdere TXT-records op één naam zijn normaal. De antwoorden voor MX en CAA hebben ‘scheve’ TTL-waarden (195, 1976): ze kwamen uit de cache van de resolver, en die teller loopt elke seconde terug tot het record opnieuw wordt opgehaald.

TTL: hoe lang een wijziging echt duurt

De TTL is het aantal seconden dat een resolver een record in de cache mag houden. RFC 2181 noemt het een maximale, geen verplichte duur, en begrenst het op 2147483647. Daarom is ‘wacht 24 tot 48 uur’ maar half waar:

• Een gewijzigd A-, MX- of TXT-record is uiterlijk overal zichtbaar als de oude TTL is verlopen: bij 300 is dat 5 minuten, bij 3600 een uur.
• Verlaag de TTL een dag voor een geplande verhuizing naar 300 en zet hem daarna weer hoger, bijvoorbeeld op 3600.
• Een naam die iemand opvroeg voordat jij hem aanmaakte, wordt als ‘bestaat niet’ in de cache bewaard, volgens RFC 2308 voor de laagste waarde van de SOA-TTL en het SOA-veld MINIMUM. Bij example.com is dat 1800 seconden.
• Een wijziging van nameservers hangt af van de TTL van de delegatie in de TLD-zone: bij .com en .net 172800 seconden, dus tot 48 uur, bij .org maar 3600 (gemeten in onze handleiding om nameservers te wijzigen). Daar komen de beroemde 24 tot 48 uur vandaan.

Mail: MX, SPF, DKIM en DMARC

Komt mail niet aan terwijl het adres klopt, dan zit de oorzaak bijna altijd in deze records. Controleer:

• MX wijst naar een hostnaam, niet naar een IP-adres en niet naar een CNAME (RFC 2181, sectie 10.3); die hostnaam heeft een eigen A- of AAAA-record nodig.
• Prioriteit: het laagste getal wordt eerst geprobeerd (RFC 5321). Gelijke getallen verdelen de belasting.
• SPF: precies één TXT-record dat begint met v=spf1 per domein. Met twee van zulke records mislukt de controle met permerror (RFC 7208).
• DKIM: de publieke sleutel staat als TXT op selector._domainkey.example.com; de selector krijg je van je mailprovider.
• DMARC: TXT op _dmarc.example.com. De actuele specificatie is RFC 9989 van mei 2026, die RFC 7489 heeft vervangen.

De records stap voor stap, met voorbeelden, vind je in onze handleiding SPF, DKIM en DMARC instellen, en servernamen en poorten voor mailprogramma’s in het artikel over IMAP- en SMTP-instellingen.

Subdomeinen en CNAME: wat wel en niet kan

Voor een blog, webshop of testkopie heb je geen nieuw domein nodig, een subdomein is genoeg. Dat krijgt een eigen A-record of een CNAME naar een andere naam, bijvoorbeeld als de webshop op een extern platform draait.

Belangrijk: een naam met een CNAME mag geen andere records hebben (RFC 1034, sectie 3.6.2; RFC 2181, sectie 10.1). Het kale domein heeft altijd SOA- en NS-records, dus een CNAME op @ is in standaard-DNS niet toegestaan. Sommige DNS-providers bieden daarvoor eigen types zoals ALIAS/ANAME of ‘CNAME flattening’: zij lossen het doel op de server op en geven gewone A-records terug. Een typische zone ziet er zo uit:

$TTL 3600
@                 IN  A      203.0.113.10
@                 IN  AAAA   2001:db8::10
www               IN  CNAME  example.com.
shop              IN  CNAME  shop.example.net.
@                 IN  MX     10 mail.example.com.
@                 IN  MX     20 mail2.example.com.
mail              IN  A      203.0.113.20
mail2             IN  A      198.51.100.20
@                 IN  TXT    "v=spf1 mx -all"
_dmarc            IN  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
@                 IN  CAA    0 issue "letsencrypt.org"
_submission._tcp  IN  SRV    0 1 587 mail.example.com.

Het kale domein heeft A en AAAA, www is een CNAME daarnaartoe, voor mail zijn er twee MX-servers waarvan één reserve, plus SPF, DMARC, CAA en een SRV-record voor verzendpoort 587. Vervang de documentatieadressen door de waarden uit je hostingpaneel.

HTTPS: TXT en CAA voor certificaten

Let’s Encrypt en andere certificaatautoriteiten moeten controleren dat jij het domein beheert. Bij de methode DNS-01 voeg je een TXT-record toe op _acme-challenge.example.com. Wildcardcertificaten (*.example.com) kunnen alleen zo worden uitgegeven. Volgens Let’s Encrypt hebben sommige DNS-providers tijd nodig voordat de wijziging al hun servers bereikt; zonder API laat je de client tot ongeveer een uur wachten. Verwijder oude challenge-records, anders wordt het antwoord te groot.

Heeft het domein CAA-records, dan mogen alleen de genoemde autoriteiten certificaten uitgeven (RFC 8659). Een CAA met alleen pki.goog blokkeert Let’s Encrypt. Op de hosting van RichHost zijn Let’s Encrypt-certificaten gratis; wat commerciële certificaten kosten en wanneer ze de moeite waard zijn, lees je in ons artikel over wat een SSL-certificaat kost.

Drie DNS-fouten die we op een testserver hebben nagebootst

De regels hierboven kun je zelf eenvoudig controleren. We hebben drie veelvoorkomende fouten nagebootst op een testopstelling: een Ubuntu 24.04-container, BIND 9.18.39, zonecontrole met named-checkzone en SPF-evaluatie met de bibliotheek pyspf 2.0.14 via een lokale DNS-server (11.11.2026). De domeinen zijn testdomeinen (.test) en de IP-adressen komen uit de reeksen voor documentatie.

1. CNAME op het hoofddomein. BIND weigerde zo’n zone te laden met de fout CNAME and other data (RFC 1034, sectie 3.6.2; RFC 2181, sectie 10.1). Vraagt een dienst bij het instellen van een CDN om een CNAME op het hoofddomein, zet de CNAME dan op www en gebruik voor het hoofddomein een A-record of ALIAS.
2. MX die naar een CNAME of een IP-adres wijst. BIND laadde de zone, maar waarschuwde: MX 'mail.mx.test' is a CNAME (illegal). Een IP-adres in de MX gaf twee waarschuwingen, MX is an address en has no address records: afzenders zouden de niet-bestaande naam 192.0.2.10.mxip.test opzoeken. Goed is een MX naar een hostnaam met een eigen A-record, zoals bij zakelijke e-mail op een eigen domein.
3. Twee SPF-records of meer dan 10 DNS-lookups in SPF. RFC 7208 staat één v=spf1-record per domein toe en hooguit 10 mechanismen die DNS-lookups veroorzaken: include, a, mx, ptr, exists en de modifier redirect (sectie 4.6.4). pyspf gaf permerror voor een domein met twee v=spf1-records en ook voor een domein met 11 include-mechanismen.

$ named-checkzone apex.test apex.test.zone
dns_master_load: apex.test.zone:4: apex.test: CNAME and other data
zone apex.test/IN: not loaded due to errors.
$ named-checkzone mx.test mx.test.zone
zone mx.test/IN: mx.test/MX 'mail.mx.test' is a CNAME (illegal)
$ python3 spfcheck2.py
two.spf.test ip=198.51.100.1 -> ('permerror', 'SPF Permanent Error: Two or more type TXT spf records found.')
eleven.spf.test ip=198.51.100.11 -> ('permerror', 'SPF Permanent Error: Too many DNS lookups')
eleven.spf.test ip=198.51.100.1 -> ('pass', 'sender SPF authorized')

De laatste regel laat zien waarom de lookuplimiet verraderlijk is: voor een afzender uit de eerste include gaf hetzelfde record pass, omdat de evaluatie bij de eerste match stopt; de fout treft dus maar een deel van de mails. Twee records ontstaan meestal wanneer een nieuwe verzenddienst vraagt om “SPF toe te voegen” en er een apart TXT-record wordt aangemaakt. Voeg de include liever toe aan het bestaande record en tel de lookups inclusief geneste mee: elke include kan er zelf weer een paar meebrengen.

Diagnose in 10 minuten: symptoom, controle, oplossing

Vervang example.com door je domein en ns1.dns-host.example door een van je nameservers. Webtools zoals whatsmydns.net tonen het antwoord vanuit veel regio’s, mxtoolbox.com controleert MX, SPF en DMARC.

Gewoontes die tijd besparen

• Exporteer de zone of kopieer alle records voor elke wijziging: herstellen kost dan minuten in plaats van uren.
• Verlaag de TTL een dag voor een verhuizing naar 300 en zet hem daarna weer hoger.
• Minstens twee nameservers, liefst in verschillende netwerken: RFC 1034 eist dat elke zone op minstens twee servers beschikbaar is.
• Bewaak belangrijke records (NS, A, MX) met een monitoringdienst die alarm slaat als het antwoord verandert.

Veelgestelde vragen

Hoe lang duurt een DNS-wijziging?

Bij een gewoon record tot de oude TTL is verlopen, vaak 5 tot 60 minuten. Bij een wijziging van nameservers tot 48 uur, door de TTL van de delegatie in de TLD-zone.

Kan ik een CNAME op het kale domein zetten?

In standaard-DNS niet, omdat het kale domein SOA- en NS-records heeft. Gebruik A/AAAA of, als je provider het aanbiedt, ALIAS/ANAME of CNAME flattening.

Heb ik een AAAA-record nodig?

Alleen als je server echt via IPv6 bereikbaar is. Een fout AAAA-record is erger dan geen: IPv6-gebruikers kunnen de site dan niet openen.

Waarom hebben mijn wijzigingen geen effect?

Meestal heb je de zone bij de registrar bewerkt terwijl de NS-records naar de hostingprovider wijzen, of andersom. Controleer met dig NS welke servers verantwoordelijk zijn.