DNS records lookup
Bekijk alle DNS-records van een domein zonder lokale DNS-cache. A, AAAA, MX, NS, TXT, CNAME, SOA en CAA — via Cloudflare DNS-over-HTTPS, hetzelfde wat Google's nameservers vertellen.
Wanneer gebruik je deze DNS-lookup?
Een DNS-record-lookup is mijn eerste stap bij bijna elk technisch probleem dat met domeinen of mail te maken heeft. Als ik een ticket binnenkrijg met "mail komt niet aan" of "site is offline", begin ik altijd hier — vóórdat ik in plugins of logs duik. Vijf scenario's waarin deze tool het werk versnelt:
- Na een DNS-wijzigingDirect verifiëren of het nieuwe record actief is, zonder te wachten tot je eigen ISP de oude waarde uit cache laat vallen.
- Bij mailproblemenMX-records checken om te zien welke mailserver verkeer ontvangt, en TXT-records om SPF/DKIM/DMARC-config te lezen.
- Tijdens sitemigratieOude en nieuwe IP's van A-records vergelijken om te zien of de DNS-switch al doorgevoerd is.
- Bij SSL-issuance foutenCAA-records checken — als deze een verkeerde CA toestaat, weigert Let's Encrypt een certificaat uit te geven.
- Domein-verificatieVoor Google Search Console, Microsoft 365 of Mailgun de verificatie-TXT bekijken zonder admin-toegang nodig.
Hoe lees je het resultaat?
Elke record-type vertelt iets anders over hoe het domein werkt. Hieronder per type wat het betekent en wat ik er meestal mee doe:
- A Het IPv4-adres waar het domein naartoe wijst. Meerdere A-records = round-robin DNS, browser kiest er één. Als de waarde niet matcht met je hosting-IP, staat het domein nog op de oude server.
- AAAA Het IPv6-adres. Niet kritiek voor werking, maar best practice anno 2026. Als 'ie ontbreekt geeft dat soms een lichte SEO-penalty op moderne netwerken.
- MX Welke mailservers mail accepteren. Lager priority-getal = voorkeur. Microsoft 365 gebruikt
*-mail.protection.outlook.com, Google Workspace gebruiktaspmx.l.google.com. - NS De nameservers die de zone beheren. Deze moeten matchen met wat je registrar laat zien in WHOIS — mismatch hier = DNS werkt niet.
- TXT Vrije tekst-records. Hier zit alles van SPF (
v=spf1), DMARC (v=DMARC1) tot domein-verificaties (Google, Microsoft, Mailgun, Stripe). DKIM-records staan op selector-subdomeinen, niet op het hoofddomein. - CNAME Een alias naar een andere naam. Werkt alleen op subdomeinen, niet op het apex/root-domein. Veel gebruikt voor
www,autodiscoveren CDN-targets. - SOA Start of Authority — meta-info over de zone (refresh-intervals, contact-mailadres van de DNS-beheerder, serial-nummer). Vooral handig om te zien wanneer de zone het laatst is bijgewerkt.
- CAA Welke certificaat-uitgevers (Let's Encrypt, GlobalSign, etc.) voor jouw domein een SSL-cert mogen uitgeven. Te streng = SSL-issuance faalt.
Wat ik vaak tegenkom
Twee SPF-records die elkaar bijten. Iemand heeft jaren geleden een SPF voor de oude mailprovider gezet, en bij switch naar M365 is een twééde SPF erbij geplakt. Resultaat: Gmail rejecteert alle mail. Je ziet dit direct in de TXT-output — twee regels die beide met v=spf1 beginnen.
CAA-record blokkeert Let's Encrypt. Klant belde paniek: "SSL faalt sinds gisteren". CAA stond op 0 issue "globalsign.com" waardoor Let's Encrypt geen cert mocht uitgeven. Eenmaal de tweede CAA toegevoegd voor letsencrypt.org, was het binnen 5 minuten opgelost.
NS-mismatch met registrar. Klant verhuisde naar Cloudflare maar vergat de nameservers bij de registrar (TransIP) te wijzigen. De DNS-changes deed Cloudflare braaf, maar niemand keek mee. NS-output toonde nog de oude TransIP-nameservers.
Veelgestelde vragen
Waarom toont deze tool andere records dan ik via mijn ISP zie?
Je internet-provider houdt DNS-resultaten lokaal in cache, vaak voor uren tegelijk om eigen verkeer te besparen. Deze tool praat rechtstreeks met Cloudflare's resolver (1.1.1.1) zonder tussenliggende cache, dus je ziet de actuele records van de autoritaire nameservers.
Voor een nog completer beeld — controleren of een wijziging wereldwijd is doorgevoerd — gebruik je de DNS propagation checker die simultaan 8 resolvers wereldwijd raadpleegt.
Werkt deze tool ook voor subdomeinen?
Ja. Voer bijvoorbeeld mail.voorbeeld.nl of autodiscover.voorbeeld.nl in en je krijgt de records voor dat specifieke subdomein, niet voor het hoofddomein. Dat is precies hoe je DKIM-records ophaalt — via selector1._domainkey.voorbeeld.nl.
Hoe lang duurt het voor een DNS-wijziging zichtbaar is?
Dat hangt af van de TTL (Time To Live) van het record dat je wijzigt. Bij een TTL van 3600 seconden kan het tot een uur duren voordat caching-resolvers de oude waarde laten vallen. Bij een TTL van 60 seconden is het binnen een minuut overal door.
Praktijktip: zet de TTL al een dag van tevoren laag (bijv. 300 seconden) vóór een geplande migratie. Dan rolt de wijziging snel door, zonder dat klanten een halve dag aan oude data hangen.
Waarom zie ik geen DKIM-record in de TXT-output?
DKIM-records staan op een specifieke selector-subdomein, niet op het hoofddomein. Microsoft 365 gebruikt selector1._domainkey.voorbeeld.nl en selector2._domainkey.voorbeeld.nl. Voor Google Workspace is dit google._domainkey.voorbeeld.nl. Voer die als domein in om DKIM te zien.
Voor een complete check van SPF + DKIM + DMARC tegelijk, gebruik de SPF/DKIM/DMARC checker — die kent de gangbare selectors al.
Worden mijn opzoekingen ergens opgeslagen?
Nee. Geen log, geen tracking, geen analytics-cookie, geen advertentie-pixels. De query gaat via een lichte PHP-backend naar Cloudflare's DoH-endpoint en het resultaat wordt direct in je browser getoond. Wel is er een rate-limit van 30 lookups per minuut per IP-adres om misbruik tegen te gaan.
Kan ik deze tool gebruiken voor klant-domeinen zonder hun toestemming?
Technisch wel — DNS-records zijn publieke informatie en iedereen ter wereld kan ze opvragen. Het is dezelfde data die elke browser, mailserver en spam-filter al raadpleegt om je site of mail te bereiken. Geen specifieke toestemming nodig.