TXT-records til verifikationer: Google, Meta og resten

Kort svar: Når Google, Meta eller en anden tjeneste beder dig verificere dit domæne, skal du som regel indsætte en TXT-record: en lille tekstlinje i domænets DNS-zone, som beviser, at du kontrollerer domænet. Opret recorden præcis som tjenesten viser – navn og værdi kopieres bogstavret – vent på at den slår igennem, og klik verificér. TXT-records gør ingen skade i sig selv, så lad verifikationerne blive stående, og ryd kun op i dem, du positivt ved er døde.

Fagligt gennemgået: 2. oktober 2026

TXT-recorden er DNS’ens frie tekstfelt og internettets foretrukne måde at stille spørgsmålet „ejer du virkelig det domæne?“. Søgemaskiner, mailtjenester, cloudplatforme og certifikatudstedere bruger alle samme mekanik.

Denne guide viser, hvordan du indsætter recorden rigtigt første gang, kontrollerer den bagefter – og holder zonen ren uden at knække noget.

Før du ændrer noget: Tag et screenshot eller en eksport af hele DNS-zonen, før du tilføjer eller sletter records. Ret aldrig i eksisterende SPF-, DKIM- eller DMARC-records som en del af en verifikation – de styrer, om jeres mail bliver leveret. Tilføj verifikationen som en ny, separat TXT-record.

Sådan virker domæneverifikation

Tjenesten genererer en unik tekststreng (fx google-site-verification=abc123…) og beder dig lægge den i domænets DNS. Kun den, der kontrollerer zonen, kan det, så når tjenesten bagefter slår domænet op og finder strengen, er kontrollen bevist.

Flere TXT-records på samme navn er helt normalt. Dit hoveddomæne har typisk både SPF og en håndfuld verifikationer side om side, mens DKIM og DMARC ligger på deres egne undernavne:

Andre TXT-records, du vil møde i zonen

Ikke alle TXT-records er verifikationer. Kend de vigtigste, så du ikke sletter dem ved en fejl:

• v=spf1 … på roden: listen over servere, der må sende mail fra domænet.
• v=DKIM1 … på selektor._domainkey: den offentlige nøgle, der bekræfter mailens signatur.
• v=DMARC1 … på _dmarc: politikken for, hvad modtagere skal gøre med mails, der fejler SPF og DKIM.
• v=STSv1 … på _mta-sts: hvis domænet bruger MTA-STS til krypteret mailtransport.

Alle fire er drift. De hører til mailopsætningen og skal ikke røres, når du arbejder med verifikationer.

Typiske verifikationsformater

Tjeneste	Værdien starter typisk med	Navn/host
Google (Search Console, Workspace)	google-site-verification=	Roden (@)
Meta (Business-domæneverifikation)	facebook-domain-verification=	Roden (@)
Microsoft 365	MS=ms	Roden (@)
Atlassian	atlassian-domain-verification=	Roden (@)
Tjenester med præfiks	Varierer	Et undernavn, fx _tjeneste

Brug altid den præcise værdi og det præcise navn, tjenesten viser dig – tabellen er kun til at genkende recordsene, når du senere rydder op.

Indsæt recorden rigtigt

1. Navn/host

Beder tjenesten om recorden på „ditdomæne.dk“ eller „@“, betyder begge rodniveauet. Beder den om et præfiks (fx _tjeneste.ditdomæne.dk), skriver du typisk kun præfikset i navnefeltet, fordi DNS-panelet selv tilføjer domænet. Skriv aldrig domænet dobbelt – klassikeren er _tjeneste.ditdomæne.dk.ditdomæne.dk.

2. Værdi

Kopiér hele strengen bogstavret, uden ekstra mellemrum eller manglende tegn. Nogle paneler sætter selv anførselstegn om værdien; tilføj dem ikke dobbelt.

3. TTL

Standardværdien er fin. Verifikationer er ikke tidskritiske, og en lav TTL gør kun en forskel, hvis du forventer at rette i recorden igen.

4. Gem, vent og verificér

Tjek selv med et opslag, før du klikker på tjenestens verificér-knap. Så ved du, om ventetiden skyldes DNS-propagering eller en fejl i recorden.

Kontrollér recorden selv

Med dig (macOS og Linux) eller nslookup (Windows) kan du se, hvad verden ser:

dig TXT ditdomæne.dk +short
dig NS ditdomæne.dk +short
dig TXT ditdomæne.dk @ns1.din-dns-udbyder.dk +short
nslookup -type=TXT ditdomæne.dk

Det første opslag viser TXT-records via din normale resolver. Det andet viser, hvilke navneservere der er autoritative for domænet. Det tredje spørger direkte den autoritative navneserver – erstat navnet med det, opslag nummer to viste – og omgår dermed cache hos resolverne. Ses recorden i det tredje opslag, men ikke i det første, er det bare et spørgsmål om tid.

Når verifikationen fejler

Fire forklaringer dækker næsten alt:

1. Recorden er ikke slået igennem endnu. Vent, og test direkte mod den autoritative navneserver.
2. Navnet er forkert. Dobbelt domæne eller manglende præfiks – svarer opslaget på det navn, tjenesten bad om?
3. Værdien er beskåret. Et usynligt mellemrum eller et manglende tegn fra kopieringen er nok til, at strengen ikke matcher.
4. Recorden ligger i den forkerte zone. Domænets DNS styres reelt et andet sted. Tjek med dig NS, hvem der er autoritativ, og se guiden om domæner, der peger forkert, hvis navneserverne overrasker.

Lange værdier og 255-tegns-grænsen

En enkelt tekststreng i en TXT-record må højst være 255 tegn. Længere værdier – typisk DKIM-nøgler, men også enkelte verifikationer – deles derfor i flere strenge i samme record, som modtageren sætter sammen. De fleste DNS-paneler gør det automatisk; skal du gøre det selv, står hver del i sine egne anførselstegn uden mellemrum imellem. Opretter du i stedet to separate records, bliver værdien ikke sat sammen, og verifikationen fejler.

CNAME og TXT på samme navn

Et navn, der har en CNAME-record, kan ikke have andre records ved siden af. Beder en tjeneste om en TXT-record på et undernavn, der allerede er en CNAME, vil panelet afvise den, eller den bliver ignoreret. Løsningen er at bruge et andet navn, som tjenesten accepterer, eller at vælge tjenestens alternative verifikationsmetode. Bruger du Cloudflare, påvirker den orange proxy-sky ikke TXT-records – de leveres altid, som de er; se orange eller grå sky i Cloudflare.

Oprydning uden ulykker

Reglen for oprydning er enkel: verifikationer skal ofte blive stående. Flere tjenester, bl.a. Googles Search Console, genkontrollerer løbende og trækker adgangen tilbage, hvis recorden forsvinder. Slet derfor kun records, hvor du positivt ved, at tjenesten er opsagt.

Lad SPF-, DKIM- og DMARC-records være i fred – de er drift, ikke verifikation. Er du i tvivl om SPF’ens indhold, hører den til i guiden til SPF-fejlen „too many DNS lookups“.

Står du med en zone fuld af ukendte records efter år og udbyderskift, så dokumentér, før du sletter: én record ad gangen, med et par ugers mellemrum, så en eventuel konsekvens kan spores tilbage.

Verifikation

Opgaven er løst, når tjenesten melder verificeret, dit eget opslag viser strengen på det rigtige navn – og recorden er noteret i jeres driftsdokumentation med tjeneste og dato. Det sidste er den egentlige investering: næste års oprydning, domæneflytning eller migrering bliver langt enklere, når hver TXT-record har et navn og et formål.

Læs også

• Hub: Domæner, DNS og SSL
• Subdomæner: opret og peg dem rigtigt
• SPF-fejlen „too many DNS lookups“
• DNS-propagering – hvorfor ændringen ikke slår igennem med det samme
• DNS hosting med høj oppetid
• WordPress hosting hos Hostious – dansk support døgnet rundt og gratis migrering

Ofte stillede spørgsmål om TXT-records

Kan for mange TXT-records skade domænet?

Nej – de fylder kun i overblikket. Den ene undtagelse: der må kun være ÉN record, der starter med v=spf1; to SPF-records er en fejl, som giver mailproblemer.

Må jeg slette verifikationen, når tjenesten er verificeret?

Frarådes – flere tjenester genkontrollerer og mister adgangen, hvis recorden er væk. Lad den stå; den koster intet. Slet kun, når tjenesten er endeligt opsagt.

Tjenesten tilbyder også CNAME- eller metatag-verifikation – hvad er bedst?

TXT i DNS er den mest robuste: den overlever temaskift og site-ændringer (i modsætning til metatags) og lægger ikke beslag på et navn (i modsætning til CNAME). Vælg TXT, når du kan.

Hvor lang tid tager det, før verifikationen virker?

Ofte få minutter, men det afhænger af DNS-udbyderen og af, om tjenesten har slået navnet op tidligere og har et gammelt svar i cache. Ses recorden ved et opslag direkte mod den autoritative navneserver, er den korrekt oprettet, og så handler resten om at vente og prøve igen.