Heb je het hoofdstuk over DNS-recordtypen gelezen, dan weet je dat elk record in je DNS-zone een specifieke taak heeft. A-records verwijzen naar IP-adressen. MX-records regelen de e-mailroutering. Een TXT-record doet geen van beide. Het bevat een regel platte tekst die andere systemen iets vertelt over je domein. Die tekst kan zeggen "deze e-mailaanbieder mag namens mij versturen" of "ja, ik ben de eigenaar van dit domein" of "dit is de sleutel om mijn berichten te verifiëren".
Zie het als een briefje op je voordeur. Het verandert niets aan hoe je huis werkt. Maar iedereen die komt en het leest, leert iets belangrijks over wie er woont en wat diegene heeft toegestaan.
Hoe ziet een TXT-record eruit?
Een TXT-record heeft vier delen, net als andere DNS-records. Dit doet elk deel.
- Hostnaam (naam) is het domein of subdomein waarop het record van toepassing is. Voor je hoofddomein is dit meestal "@" of blanco. Voor een subdomein zoals mail.jouwdomein.com is de hostnaam "mail"
- Type vertelt het DNS-systeem dat dit een TXT-record is
- Waarde is de tekstinhoud zelf. Dit kan een verificatiecode zijn, een e-mailbeleid, een publieke sleutel of een andere tekenreeks van maximaal 255 tekens per segment
- TTL (time to live) bepaalt hoe lang DNS-servers dit record in de cache houden voordat ze op updates controleren. De standaard is meestal 3600 seconden, wat een uur is
Zo ziet een simpel TXT-record eruit in een DNS-instellingenpaneel.
- Hostnaam ingesteld op @
- Type ingesteld op TXT
- Waarde ingesteld op "v=spf1 include:_spf.example.com ~all"
- TTL ingesteld op 3600
Dat voorbeeld is een SPF-record, een van de meest voorkomende typen TXT-record. In de secties hieronder lees je wat SPF betekent en hoe andere e-mailbeveiligingsrecords werken.
Hoe wordt een TXT-record gebruikt voor domeinverificatie?
Dit is het simpelste gebruik van een TXT-record. Een dienst heeft bewijs nodig dat je een domein bezit. Dat bewijs lever je door een record toe te voegen dat alleen de domeineigenaar kan toevoegen.
Zo werkt het proces.
- Je meldt je aan bij een dienst en geeft je domeinnaam op
- De dienst geeft je een unieke verificatiecode
- Je logt in op je DNS-instellingen en voegt een TXT-record toe met die code als waarde
- De dienst controleert je DNS op het TXT-record
- Vindt hij de code, dan is de verificatie klaar
Waarom werkt dit? Omdat alleen iemand met toegang tot je DNS-instellingen daar records kan toevoegen. De verificatiecode betekent zelf niets. Hij bewijst alleen dat je de sleutels van de DNS-zone hebt.
Wat is een SPF-record?
Waar SPF voor staat
SPF staat voor Sender Policy Framework. Het is een TXT-record met een lijst van mailservers die e-mail mogen versturen onder je domeinnaam. Als iemand een e-mail van jou ontvangt, controleert zijn mailserver je SPF-record om te zien of de verzendende server op de goedgekeurde lijst staat.
Wat een SPF-record doet
Zonder SPF-record kan iedereen een e-mail versturen die lijkt te komen van je domein. Dit heet e-mailspoofing. Het is een van de oudste trucs uit het phishing-handboek, en het werkt omdat de ontvangende server niet kan controleren of de afzender is wie hij beweert te zijn.
Een SPF-record lost dat op. Het is alsof je het postkantoor een lijst geeft van koeriers die namens jou pakketten mogen versturen. Komt er een pakket van een koerier die niet op de lijst staat, dan weet het postkantoor dat er iets niet klopt.
Hier is een voorbeeld.
v=spf1 include:_spf.mailprovider.com ~all
Dit zegt drie dingen.
- v=spf1 geeft aan dat dit een SPF-record is
- include:_spf.mailprovider.com betekent "de servers die deze mailaanbieder opgeeft mogen e-mail voor mijn domein versturen"
- ~all betekent "komt een e-mail van een andere server, behandel hem dan als verdacht maar weiger hem niet meteen"
Verander je "~all" in "-all", dan wordt de regel strenger. Dan vertel je ontvangende servers dat ze alles wat niet op de goedgekeurde lijst staat meteen moeten weigeren.
Wat is een DKIM-record?
Waar DKIM voor staat
DKIM staat voor DomainKeys Identified Mail. Waar SPF controleert wie de e-mail heeft verstuurd, controleert DKIM of er onderweg naar je inbox met de e-mail is geknoeid.
Hoe de publieke sleutel werkt
Zie DKIM als een lakzegel op een brief. Als je mailserver een e-mail verstuurt, zet hij er een verborgen handtekening op. Die handtekening wordt gemaakt met een privésleutel die alleen je server kent. De bijbehorende publieke sleutel staat in een TXT-record op je domein, zichtbaar voor iedereen die kijkt.
Ontvangt de ontvangende server de e-mail, dan leest hij je publieke sleutel uit DNS en vergelijkt die met de handtekening. Komen ze overeen, dan is de e-mail geverifieerd als echt en ongewijzigd. Komen ze niet overeen, dan is de e-mail mogelijk onderweg aangepast.
Je hoeft de sleutel zelf niet te begrijpen. Je e-mailaanbieder genereert hem en vertelt je precies wat je in je DNS-instellingen moet plakken. Het DKIM TXT-record staat meestal op een subdomein dat eruitziet als "selector._domainkey.jouwdomein.com".
Wat is een DMARC-record?
Hoe DMARC SPF en DKIM samenbrengt
SPF controleert waar de e-mail vandaan komt. DKIM controleert dat hij niet is aangepast. Maar wat gebeurt er als een van die controles mislukt? Zonder DMARC beslist elke ontvangende server zelf. Sommige sturen de e-mail naar spam. Sommige laten hem door. Sommige weigeren hem. Je hebt nul controle.
DMARC staat voor Domain-based Message Authentication, Reporting, and Conformance. Het is een TXT-record dat jou de leiding geeft. Jij stelt de regels in voor wat er gebeurt als een e-mail SPF of DKIM niet doorstaat.
Wat de DMARC-beleidsopties betekenen
Een DMARC-record voeg je toe als TXT-record op het subdomein "_dmarc.jouwdomein.com". Hier is een simpel voorbeeld.
v=DMARC1; p=quarantine; rua=mailto:reports@jouwdomein.com
Dit vertelt ontvangende servers drie dingen.
- v=DMARC1 geeft aan dat dit een DMARC-record is
- p=quarantine is het beleid. Het zegt tegen de ontvangende server dat e-mails die de authenticatie niet doorstaan naar de spammap moeten in plaats van naar de inbox
- rua=mailto:reports@jouwdomein.com zegt tegen servers dat ze authenticatierapporten naar dit e-mailadres moeten sturen, zodat je kunt zien wie e-mail verstuurt via je domein
Het beleidsveld (p=) heeft drie opties.
- none betekent geen actie ondernemen, alleen rapporten sturen. Dit is handig als je DMARC net instelt en eerst wilt monitoren voordat je gaat afdwingen
- quarantine betekent dat mislukte e-mails naar spam gaan
- reject betekent dat mislukte e-mails volledig worden geblokkeerd en de ontvanger nooit bereiken
Samen vormen SPF, DKIM en DMARC drie lagen e-mailbescherming. SPF is de gastenlijst. DKIM is het lakzegel. DMARC is de portier die beslist wat er gebeurt als iemand de eerste twee controles niet doorstaat. Als je eigen e-mail instelt met je domein, zijn alle drie de records belangrijk.
Wat kunnen TXT-records nog meer?
E-mailbeveiliging en domeinverificatie zijn de twee grootste toepassingen, maar TXT-records komen ook op andere plekken voor.
- Verificatie door zoekmachines. Zoekmachines vragen je een TXT-record toe te voegen om te bewijzen dat je een domein bezit voordat je toegang krijgt tot gegevens over zoekprestaties
- Beveiligingsbeleid. Sommige organisaties gebruiken TXT-records om beveiligingscontactgegevens of voorkeuren voor certificeringsinstanties te publiceren
- Authenticatie van diensten. Analyticsplatforms, advertentiediensten en andere tools vragen vaak om een TXT-record om je domein aan je account te koppelen
- Eigen metadata. Alle tekstinformatie die andere servers of diensten over je domein moeten lezen, kan in een TXT-record staan
TXT-records zijn het zakmes van DNS. Moet een dienst iets over je domein verifiëren, authenticeren of communiceren, dan is de kans groot dat hij daar een TXT-record voor gebruikt.
Hoe voeg je een TXT-record toe?
Een TXT-record toevoegen volgt dezelfde stappen als elk ander DNS-record. Heb je al eens een A-record of MX-record toegevoegd, dan komt dit je bekend voor.
- Log in op het DNS-beheerpaneel waar de nameservers van je domein zijn ingesteld. Dat is meestal je domeinregistrar of je hostingaanbieder
- Zoek de sectie met DNS-records of de DNS-zone-editor
- Klik op de optie om een nieuw record toe te voegen
- Kies TXT als recordtype
- Voer de hostnaam in. Gebruik "@" voor het hoofddomein of de naam van een specifiek subdomein als de dienst dat vraagt
- Plak de exacte waarde die de dienst geeft die je instelt. Typ hem niet met de hand over
- Stel de TTL in. Weet je het niet zeker, gebruik dan de standaardwaarde die je aanbieder voorstelt of stel 3600 in
- Sla het record op
Houd één ding in gedachten. DNS-wijzigingen kunnen van een paar minuten tot 48 uur duren voordat ze zich over internet hebben verspreid. Dit heet DNS-propagatie. In die tijd zien sommige servers misschien nog de oude instellingen en anderen de nieuwe. Meer details over dit proces lees je in het hoofdstuk over hoe DNS werkt.
Wat zijn veelgemaakte fouten met TXT-records?
TXT-records zijn eenvoudig toe te voegen, maar een paar steeds terugkerende fouten laten mensen struikelen.
- De verkeerde waarde plakken. TXT-recordwaarden zijn vaak lange reeksen willekeurige tekens. Mis je één teken of voeg je een extra spatie toe, dan werkt het hele record niet meer. Kopieer en plak altijd rechtstreeks uit de dienst die je de waarde gaf
- Meerdere SPF-records op hetzelfde domein. Je mag maar één SPF-record per domein hebben. Moet je meerdere mailaanbieders autoriseren, voeg ze dan samen in één SPF-record met meerdere "include"-opdrachten. Twee aparte SPF-records zorgen voor onvoorspelbaar gedrag en mislukte e-mailbezorging
- Het record op de verkeerde hostnaam zetten. Sommige TXT-records horen op het hoofddomein (@), andere op een specifiek subdomein zoals "_dmarc" of "selector._domainkey". Zet je het record op de verkeerde plek, dan vindt de dienst die ernaar zoekt het niet
- Vergeten op te slaan. Het klinkt basaal, maar veel DNS-panelen vragen je na het invoeren van het record op een knop Opslaan of Bevestigen te klikken. Sluit je de pagina voordat je opslaat, dan wordt het record niet aangemaakt
- Niet wachten op propagatie. Na het toevoegen van een TXT-record kan de verificatiedienst het niet meteen vinden. Geef het minstens 15 tot 30 minuten voordat je de controle opnieuw probeert
Wat gebeurt er als TXT-records fout zijn of ontbreken?
De gevolgen hangen af van welk TXT-record het betreft.
- Is je SPF-record afwezig of onjuist, dan komen je e-mails vaker in spam terecht. Ontvangende servers kunnen niet bevestigen dat je mailserver is geautoriseerd, dus ze gaan op safe
- Ontbreekt je DKIM-record, dan missen je e-mails een verifieerbare handtekening. Sommige ontvangers accepteren ze nog steeds, maar spamfilters worden argwanender
- Ontbreekt je DMARC-record, dan heb je geen controle over wat er gebeurt met e-mails die SPF- of DKIM-controles niet doorstaan. Elke ontvangende server beslist zelf
- Wordt een verificatie-TXT-record verwijderd, dan kan de dienst die het vroeg je toegang intrekken of een waarschuwing tonen dat het domeineigendom niet langer is bevestigd
Geen van deze problemen haalt je website offline. TXT-records hebben geen invloed op hoe je site laadt of hoe bezoekers die bereiken. Maar ontbrekende of kapotte TXT-records kunnen je e-mailbezorging en je mogelijkheid om diensten aan je domein te koppelen schaden.
Zo regelt WEMASY TXT-records
Als je een eigen domein aan je WEMASY-website koppelt, loodst WEMASY je langs de DNS-records die je moet toevoegen. Bevat je abonnement e-mailfuncties of verifieer je je domein voor zoektools, dan vertelt WEMASY je precies welke TXT-records je moet maken, inclusief de hostnaam en de waarde om te plakken.
WEMASY regelt SSL en hosting aan zijn kant, dus de TXT-records die je toevoegt gaan over verificatie en e-mailbeveiliging in plaats van routering. Staan je records er en is DNS gepropageerd, dan verbindt alles automatisch. Bekijk wat er in elk abonnement zit op de prijzenpagina van WEMASY.
Hoe nu verder
Nu je begrijpt hoe TXT-records werken voor verificatie en e-mailbeveiliging, behandelt het volgende hoofdstuk NS-records. NS-records bepalen welke nameservers verantwoordelijk zijn voor de hele DNS-zone van je domein, en ze vormen de basis van hoe al je andere records worden gevonden. Voor een overzicht van alle recordtypen en wanneer je welk gebruikt, lees je het hoofdstuk over DNS-recordtypen.
Veelgestelde vragen
Kun je meerdere TXT-records op hetzelfde domein hebben?
Ja. Een domein kan tegelijk veel TXT-records hebben. Je hebt er bijvoorbeeld een voor SPF, een voor domeinverificatie en een voor DKIM op een subdomein. De enige uitzondering is SPF. Je mag maar één SPF-record per domein hebben. Moet je meerdere mailaanbieders autoriseren, voeg ze dan samen in één SPF-record. Met de websitebouwer van WEMASY stel je dit direct op je website in.
Beïnvloedt een TXT-record hoe snel je website laadt?
Nee. TXT-records spelen geen rol bij het routeren van websiteverkeer. Ze worden alleen gelezen door diensten die er specifiek naar zoeken, zoals mailservers die SPF controleren of verificatietools die eigendom controleren. De snelheid van je website wordt bepaald door je A-record, je server en je hostingopzet, niet door je TXT-records.
Hoe lang duurt het voordat een TXT-record werkt?
Dat hangt af van DNS-propagatie en de TTL van eerdere records. In de meeste gevallen is een nieuw TXT-record binnen 15 tot 30 minuten zichtbaar. Volledige propagatie over alle DNS-servers wereldwijd kan tot 48 uur duren, al is dat zeldzaam bij nieuwe records die er eerder niet waren.
Wat is de maximale lengte van een TXT-recordwaarde?
Een enkele TXT-recordtekenreeks kan maximaal 255 tekens lang zijn. Moet de waarde langer zijn, dan wordt hij binnen hetzelfde record opgesplitst in meerdere tekenreeksen. Je DNS-aanbieder regelt die splitsing meestal automatisch. Diensten die lange TXT-waarden genereren, zoals DKIM-sleutels, houden rekening met deze limiet als ze het record voor je maken.
Heb je TXT-records nodig als je geen e-mail vanaf je domein verstuurt?
Het is nog steeds een goed idee. Ook als je geen e-mail verstuurt, voorkom je met een SPF-record dat zegt dat geen enkele server is geautoriseerd (v=spf1 -all) dat spammers je domein spoofen. Zonder e-mailauthenticatierecords kan iedereen e-mails versturen die lijken te komen van je domein, wat je reputatie kan schaden.