Domeinverificatie met TXT-records: hoe het werkt en waarom het mislukt

Beginner⏱ 3 min leestijdBijgewerkt op 13 oktober 2026

Google, Microsoft, Meta, Apple en tientallen andere diensten vragen je: „voeg dit TXT-record toe om je domein te verifiëren”. Het is het eenvoudigste bewijs van controle dat er is: alleen wie de DNS van het domein kan bewerken, kan een willekeurige tekenreeks publiceren die hij kreeg. Als het werkt, kost het twee minuten. Als het niet werkt, is de oorzaak bijna altijd een van vijf.

Hoe het werkt

De dienst geeft je een willekeurig token. Je publiceert het als TXT-record, de dienst vraagt het record op via publieke DNS, en vindt hij het token, dan is het domein wat hem betreft van jou. De meeste diensten gebruiken het domein zelf (@); een paar een aparte naam.

Dienst	Naam	Waarde
Google (Search Console, Workspace)	`@`	`google-site-verification=…`
Microsoft 365	`@`	`MS=ms…`
Meta (Facebook, Instagram)	`@`	`facebook-domain-verification=…`
Apple (iCloud+ Custom Email Domain)	`@`	`apple-domain=…`
Atlassian	`@`	`atlassian-domain-verification=…`
Let's Encrypt (DNS-01)	`_acme-challenge`	`<token>`

Stap voor stap

0 van 6 gedaan

Kopieer het token exact, zonder spaties ervoor of erna.
Voeg het TXT-record toe waar de DNS van het domein echt wordt gehost — bij de provider uit de NS-records, niet altijd de registrar.
Vul in het naamveld @ in (of laat het leeg) voor het domein zelf. De meeste panelen plakken het domein er zelf achter, dus example.com intypen maakt example.com.example.com.
Plak de waarde zonder aanhalingstekens, tenzij het paneel erom vraagt.
Sla op en controleer het record met een TXT-lookup voordat je op „Verifiëren” klikt.
Laat het record daarna staan als de dienst dat zegt: Google en Microsoft controleren het later opnieuw.

Meerdere TXT-records onder dezelfde naam zijn prima

Een domein kan elk aantal TXT-records op @ hebben, en elke dienst vindt de zijne aan het voorvoegsel. Voeg elk token als apart record toe:

example.com.  3600 IN TXT "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
example.com.  3600 IN TXT "MS=ms48213307"
example.com.  3600 IN TXT "facebook-domain-verification=w7k2p9d4x1q8z3m6n5b0c2v7"
example.com.  3600 IN TXT "v=spf1 include:_spf.google.com ~all"     ; SPF stays a separate record

Pas op: Plak nooit een verificatietoken in je SPF-record en maak nooit een tweede record dat met v=spf1 begint. SPF is het enige TXT-record dat uniek moet zijn; ze mengen breekt je e-mailauthenticatie.

Waarom de verificatie „record niet gevonden” meldt

Verkeerde plek. Het record is bij de registrar toegevoegd, maar de nameservers van het domein wijzen naar Cloudflare of een hostingbedrijf. Controleer eerst NS — dat is de meest voorkomende oorzaak.
Verkeerde naam. Het paneel plakte het domein erachter, wat example.com.example.com opleverde, of het record kwam op www in plaats van op het domein.
Te vroeg. De dienst keek voordat het record bestond, en zijn resolver bewaarde „geen record” — voor de negatieve-cachetijd uit de SOA van de zone, vaak een uur. Wacht en probeer opnieuw.
Verminkte waarde. Dubbele aanhalingstekens (""token""), een ontbrekend teken of een spatie die met het token mee is gekopieerd.
Lange waarden verkeerd gesplitst. TXT-tekenreeksen van meer dan 255 tekens worden in meerdere delen tussen aanhalingstekens gesplitst; sommige panelen doen dat fout. Bij verificatietokens zelden, bij DKIM-sleutels vaak.

# what the world sees — is the token there, exactly once, without extra quotes?
dig +short example.com TXT
# where does the domain's DNS really live? Edit the records there.
dig +short example.com NS

Ruim oude tokens op

Tokens van diensten die je niet meer gebruikt, kunnen technisch geen kwaad, maar vertellen iedereen die kijkt welke tools je gebruikt — aanvallers lezen ze bij het voorbereiden van phishing — en ze maken het TXT-antwoord groter. Verwijder een token als je een dienst verlaat, en laat de tokens staan die diensten opnieuw controleren.

Tip: De TXT-lookup van PixDNS toont alle TXT-records van een domein en markeert bekende verificatietokens, zodat je makkelijk ziet welke bij diensten horen die je nog gebruikt.

De TXT-records van een domein opzoeken →Verder: TXT-records uitgelegd →

Veelgestelde vragen

Mag ik het verificatierecord na het verifiëren verwijderen?

Alleen als de dienst zegt dat het een eenmalige controle is. Google Search Console, Google Workspace en Microsoft 365 controleren het opnieuw, en verwijderen kan de verificatie ongedaan maken.

Heeft een TXT-verificatierecord invloed op mijn website of e-mail?

Nee. Alleen de dienst die erom vroeg, leest het. De enige TXT-records die de afhandeling van e-mail veranderen, zijn SPF, DKIM en DMARC.

Hoeveel TXT-records kan een domein hebben?

Er is geen vaste limiet. Tientallen werken; heel grote TXT-antwoorden zijn trager en hebben soms TCP nodig — nog een reden om ongebruikte tokens te verwijderen.

Is verificatie via een CNAME anders?

Sommige diensten bieden een CNAME in plaats van een TXT-record. Dat bewijst hetzelfde, maar een CNAME mag niet op de apex staan en zijn naam niet met andere records delen; daarom is TXT de standaard.

Probeer het op je domein

Zie de theorie in de praktijk — voer TXT-lookup uit voor je eigen domein.

Bijgewerkt op 13 oktober 2026

Bronnen