Kort svar: Når Google, Meta eller en anden tjeneste beder dig “verificere dit domæne”, skal du indsætte en TXT-record: en lille tekstlinje i din DNS-zone, som beviser, at du kontrollerer domænet. Opret recorden præcis som tjenesten viser (navn/host og værdi kopieres bogstavret), vent på propagering, og klik verificér. TXT-records gør ingen skade i sig selv – men lad verifikationerne blive stående, og ryd kun op i dem, du positivt ved er døde.
TXT-recorden er DNS’ens frie tekstfelt – og internettets foretrukne måde at stille spørgsmålet “ejer du virkelig det domæne?”. Søgekonsol, mailtjenester, cloudplatforme og certifikater bruger alle samme mekanik. Denne guide viser, hvordan du indsætter dem rigtigt første gang, læser dem bagefter – og holder zonen ren uden at knække noget.
Kontrolramme: Vejledningen er skrevet pr. 30. august 2026. Terminaleksemplet er genskabt med et anonymiseret domæne.
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 ejerskabet bevist. Flere TXT-records på samme navn er helt normalt: dit hoveddomæne har typisk både SPF, en håndfuld verifikationer og måske en DMARC-relateret record boende side om side:
_tjeneste.ditdomæne.dk), skriver du typisk kun præfikset i navnefeltet – dit DNS-panel tilføjer selv domænet. Skriv aldrig domænet dobbelt (klassikeren: _tjeneste.ditdomæne.dk.ditdomæne.dk).Fire forklaringer dækker næsten alt: recorden er endnu ikke propageret (vent, og test med dig direkte mod dine navneservere); navnet er forkert (dobbelt domæne eller manglende præfiks – se opslaget: svarer navnet med din streng?); værdien er beskåret eller har fået et usynligt mellemrum med i kopieringen; eller recorden er lagt i den forkerte zone – typisk fordi domænets DNS reelt styres et andet sted (tjek med dig NS ditdomæne.dk, hvem der er autoritativ – og se peger-forkert-guiden, hvis navneserverne overrasker).
Reglen for TXT-oprydning: verifikationer skal ofte blive stående – flere tjenester (bl.a. Søgekonsollen) genkontrollerer løbende og trækker adgangen tilbage, hvis recorden forsvinder. Slet derfor kun records, hvor du positivt ved, at tjenesten er opsagt – og 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 SPF-guiden). 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.
Opgaven er løst, når tjenesten melder verificeret, dit eget dig-opslag viser strengen på det rigtige navn – og recorden er noteret i jeres driftsdokument med tjeneste og dato. Det sidste er den egentlige investering: næste års oprydning, domæneflytning eller migrering bliver triviel, når hver TXT-record har et navn og et formål.
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.
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.
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.