TXT-poster forklart: SPF, DKIM, DMARC og verifisering

En TXT-post lagrer tekst på et bestemt navn i DNS. Selve posttypen vet ikke om teksten er SPF, DKIM, DMARC eller en verifiseringskode. Det er formatet på verdien og navnet posten publiseres på som gir teksten mening.

Dette skillet forklarer de fleste TXT-feil: En helt korrekt verdi virker ikke hvis den ligger på feil navn, og en riktig plassert post kan fortsatt være ugyldig for tjenesten som skal lese den.

Det korte svaret

En TXT-post består av fire praktiske deler:

Syntaksen i DNS-panelet varierer. @ betyr rotdomenet hos mange leverandører, men ikke alle. Noen paneler vil ha bare _dmarc, andre viser eller krever hele navnet _dmarc.eksempel.no.

Hva er en TXT-post teknisk?

RFC 1035 definerer TXT som en DNS-ressurspost med én eller flere tekststrenger. Når en tjeneste bruker TXT til strukturerte data, lager den sin egen syntaks oppå denne generelle posttypen.

Et DNS-oppslag kan for eksempel returnere:

eksempel.no. 3600 IN TXT "google-site-verification=eksempel-token"
eksempel.no. 3600 IN TXT "v=spf1 include:_spf.example.net -all"

Dette er to forskjellige TXT-poster på samme navn. Det er lov fordi de brukes til ulike formål. En SPF-mottaker velger verdien som starter med v=spf1, mens verifiseringstjenesten leter etter sitt token.

TXT-poster er offentlige. Ikke lagre passord, private nøkler, API-hemmeligheter eller andre data som skal være hemmelige i DNS.

Vanlige bruksområder

Kopier alltid både navn og verdi fra den konkrete leverandørens instruksjon. Et eksempel fra en annen plattform er ikke en universell mal.

TXT for SPF

SPF bruker TXT til å beskrive hvilke systemer som kan sende e-post med et bestemt avsenderdomene.

Et enkelt eksempel kan se slik ut:

eksempel.no. TXT "v=spf1 include:_spf.example.net -all"

Det viktige er ikke at posten er TXT, men at verdien følger SPF-syntaks og representerer alle legitime avsendere.

RFC 7208 krever at SPF-policyen finnes i én valgt TXT-post for det aktuelle navnet. To separate poster som begge starter med v=spf1, gir permanent SPF-feil. Andre TXT-poster på samme navn er tillatt.

Feil:

eksempel.no. TXT "v=spf1 include:_spf.example.net -all"
eksempel.no. TXT "v=spf1 include:mail.example.org -all"

Riktig løsning er å lage én samlet policy som bare inkluderer avsenderne virksomheten faktisk bruker. Ikke lim sammen verdier uten å forstå mekanismene, DNS-oppslagsgrensen og hva all betyr.

Les hele guiden til SPF-poster før dere endrer en aktiv avsenderpolicy.

TXT for DKIM

DKIM publiserer en offentlig nøkkel i DNS. Mottakeren bruker den til å kontrollere en signatur som e-posttjenesten har lagt på meldingen.

Navnet inneholder en selector:

selector1._domainkey.eksempel.no. TXT "v=DKIM1; k=rsa; p=OFFENTLIG_NOKKEL"

Selektoren velges av e-postleverandøren. selector1 er bare et eksempel. Bruk nøyaktig navnet og verdien leverandøren gir dere.

Den offentlige nøkkelen kan være lang. DNS-leverandøren kan vise den som flere tekstsegmenter:

"v=DKIM1; k=rsa; p=FORSTE_DEL" "ANDRE_DEL"

I én TXT-post skal segmentene tolkes som sammenhengende tekst uten at DNS legger til mellomrom. RFC 7208s forklaring av flere tekststrenger gjelder det underliggende TXT-formatet og viser hvorfor lange verdier kan deles i visningen.

Ikke legg inn et ekstra mellomrom mellom nøkkeldelene. Ikke publiser DKIMs private nøkkel; bare den offentlige verdien leverandøren har oppgitt.

Les DKIM-oppsett steg for steg for kontroll av signeringen.

TXT for DMARC

DMARC ligger på _dmarc foran domenet:

_dmarc.eksempel.no. TXT "v=DMARC1; p=none"

En DMARC-post består av tagger adskilt med semikolon. v=DMARC1 identifiserer formatet, mens p= angir policy. En produksjonspolicy bør bygge på kartlagte avsendere og rapporter, ikke kopieres blindt fra et eksempel.

Vanlige DMARC-feil er:

• posten ligger på rotdomenet i stedet for _dmarc
• flere DMARC-poster finnes på samme navn
• tagger er feilstavet eller har ugyldige verdier
• rapportadresse eller ekstern rapportgodkjenning er feil
• streng policy aktiveres før SPF- og DKIM-alignment er kontrollert

Les DMARC-poster forklart før p=quarantine eller p=reject publiseres.

TXT for domeneverifisering

Tjenester bruker TXT for å kontrollere at du kan endre DNS for domenet. Google Search Console viser for eksempel en verdi som starter med google-site-verification= ved DNS-verifisering. Google dokumenterer at verdien skal kopieres til DNS-leverandøren.

En typisk instruksjon inneholder:

• posttype: TXT
• navn eller vert: ofte @ eller tomt felt
• verdi: et unikt token
• TTL: standard eller leverandørens anbefaling

Kontroller om tokenet må bli stående. Enkelte tjenester kan miste bekreftet status hvis posten slettes, mens andre bare bruker den ved første kontroll.

Et verifiseringstoken er synlig offentlig. Det skal bevise DNS-kontroll, ikke fungere som et privat passord.

Navn: den vanligste kilden til feil

Anta at leverandøren ber om:

_dmarc.eksempel.no

Hvis DNS-panelet automatisk legger til eksempel.no, skal du kanskje skrive bare:

_dmarc

Skriver du hele navnet i et slikt panel, kan resultatet bli:

_dmarc.eksempel.no.eksempel.no

Det samme skjer ofte med DKIM-selektorer og _acme-challenge.

Før lagring bør panelet vise det endelige fullstendige navnet, eller leverandørens dokumentasjon bør forklare feltet. Etter lagring skal dere slå opp akkurat det fullstendige navnet tjenesten forventer.

Anførselstegn og lange verdier

Anførselstegn er del av presentasjonen i en sonefil og i mange DNS-verktøy. DNS-paneler håndterer dem forskjellig:

• noen forventer bare tekstinnholdet og legger til anførselstegn selv
• noen viser anførselstegn etter lagring
• noen importverktøy forventer sonefilsyntaks

Ikke legg til eller fjern tegn basert på hvordan dig ser ut alene. Følg feltinstruksjonen og kontroller den faktiske returnerte teksten.

Lange TXT-verdier kan deles i flere tekststrenger i samme post. Mottakeren setter segmentene sammen uten ekstra mellomrom. Det er forskjell på:

• én TXT-post med flere segmenter, som kan være gyldig
• flere separate TXT-poster med hver sin del, som vanligvis ikke er det leverandøren ba om

Slik publiserer du en TXT-post trygt

1. Finn den autoritative DNS-leverandøren

Se på domenets navnetjenere. Det er hos leverandøren for den aktive DNS-sonen posten må legges inn. En post i et gammelt registrar- eller webhotellpanel gjør ingenting hvis domenet bruker andre navnetjenere.

2. Dokumenter nåsituasjonen

Ta vare på eksisterende poster med samme navn og type. Dette er særlig viktig for SPF og verifiseringer. Ikke erstatt alle TXT-poster på rotdomenet bare fordi en leverandør gir dere én ny verdi.

3. Kopier navn og verdi separat

Kontroller:

• riktig domene
• riktig navn eller selector
• posttype TXT
• hele verdien uten linjeskift
• om DNS-panelet legger til domenet
• TTL

4. Gjør én forståelig endring

Ikke kombiner e-postmigrering, navnetjenerbytte og flere policyendringer hvis dere kan unngå det. Én avgrenset endring er lettere å kontrollere og tilbakeføre.

5. Slå opp hos autoritativ navnetjener

Finn navnetjenerne:

dig eksempel.no NS +short

Spør deretter en autoritativ navnetjener direkte:

dig @ns1.dnsleverandor.no eksempel.no TXT +short
dig @ns1.dnsleverandor.no _dmarc.eksempel.no TXT +short
dig @ns1.dnsleverandor.no selector1._domainkey.eksempel.no TXT +short

Bytt ut navnene med faktiske verdier. Et autoritativt svar viser om den aktive sonen har posten. En vanlig resolver kan fortsatt vise et eldre svar til TTL-en er ute.

6. Kontroller hos tjenesten

At dig viser posten, beviser bare DNS-publisering. Bruk deretter verifiseringsknappen eller diagnostikken hos e-post-, analyse- eller sertifikattjenesten. Den kan oppdage ugyldig syntaks eller policy.

7. Dokumenter endringen

Noter bestiller, formål, kilde til verdien, tidspunkt, tidligere verdi og kontrollresultat. For e-postposter bør dere også vite hvem som oppdaterer dem når en leverandør avsluttes.

Vanlige feil og riktig diagnose

Ikke slett andre TXT-poster ukritisk

Mange TXT-poster kan ligge på rotdomenet samtidig. Når en ny e-postleverandør sier «legg til denne TXT-posten», betyr det ikke «erstatt alle TXT-poster».

Før sletting, identifiser:

• hvilken tjeneste som opprettet posten
• om tjenesten fortsatt brukes
• om tokenet må bestå for verifisering
• om verdien er del av e-postautentisering
• hvem som godkjenner fjerningen

Gamle verifiseringer bør ryddes når de ikke lenger trengs, men etter dokumentert kontroll.

TXT-poster hos Vymo

Vymo har ikke et selvbetjent DNS-panel. Hvis Vymo håndterer DNS-endringen, send domenenavn, fullstendig postnavn, posttype, offentlig verdi og kilden til instruksjonen .

Ikke send:

• passord
• private DKIM-nøkler
• API-hemmeligheter
• aktive flyttekoder
• private meldinger eller persondata

En TXT-verdi som skal publiseres i DNS er offentlig, men vi må fortsatt vite hvilken tjeneste som har gitt den og hvilket navn den skal ligge på. Vymo bekrefter fremgangsmåte før endring.

Trenger virksomheten postkasser på eget domene, kan dere se Vymos e-postpakker . E-post Basis koster 19 kroner per måned per konto inkludert merverdiavgift og har 15 GB lagring. DNS-oppsettet må tilpasses de faktiske tjenestene domenet bruker.

Vanlige spørsmål

Kan et navn ha flere TXT-poster?

Ja. Et rotdomene kan for eksempel ha både SPF og flere verifiseringstokens. Men enkelte protokoller krever én valgt policy: To separate v=spf1-poster er ugyldig for SPF, og flere DMARC-policyer på _dmarc skaper feil.

Er TXT-poster hemmelige?

Nei. DNS-svar er offentlige. Publiser bare verdier som er ment for offentlig DNS.

Skal jeg skrive @ eller domenet?

Det avhenger av DNS-panelet. @ betyr rot hos mange leverandører. Kontroller hvordan panelet bygger det endelige navnet.

Skal verdien ha anførselstegn?

Følg DNS-leverandørens feltformat. Mange paneler legger til sonefilens anførselstegn automatisk. Kontroller teksten som returneres i DNS etter lagring.

Hvor raskt blir posten synlig?

Den aktive autoritative navnetjeneren bør vise endringen når sonen er publisert. Mellomlagrede resolvere kan vise gammel verdi til tidligere TTL er utløpt.

Kan jeg ha to SPF-poster?

Nei, ikke to separate TXT-poster som begge velges som SPF-policy for samme navn. Samle autoriserte avsendere i én gyldig policy.

Hvorfor viser dig DKIM som flere biter?

Én TXT-post kan bestå av flere tekstsegmenter. De tolkes sammen uten ekstra mellomrom. Kontroller at det er segmenter i én post, ikke flere uavhengige poster.

Må verifiseringsposten slettes etterpå?

Følg tjenestens dokumentasjon. Noen tjenester kontrollerer posten igjen og kan miste verifisert status hvis den fjernes.

Kontroller navn, verdi og formål

En TXT-post er enkel å publisere, men lett å legge på feil navn eller duplisere på en måte protokollen ikke tillater. Behandle leverandørens instruksjon som fire separate data: navn, type, verdi og TTL. Kontroller deretter både DNS-svaret og tjenesten som skal tolke det.

Ved e-postoppsett bør dere starte med den samlede guiden til SPF, DKIM og DMARC slik at TXT-postene beskriver én helhetlig avsenderarkitektur.