DKIM-post i DNS – navn, selector og nøkkel
En DKIM-post publiserer nøkkelen som mottakeren bruker til å kontrollere en signatur. Selector og signeringsdomene bestemmer hvilket DNS-navn som slås opp.
Vymo · · 5 min lesing
En DKIM-post er den offentlige delen av en signeringsløsning for e-post. Avsendersystemet beholder privatnøkkelen og legger en signatur i meldingen. Mottakeren bruker signaturen til å finne riktig offentlig nøkkel i DNS og kontrollere om de signerte delene av meldingen fortsatt stemmer.
Det finnes ingen universell DKIM-verdi du kan kopiere. Selector, signeringsdomene og nøkkel må komme fra systemet som faktisk skal signere e-posten.
Slik finner mottakeren posten
En DKIM-signatur inneholder blant annet:
d=: domenet som står bak signaturens=: selector som velger nøkkelen
DNS-navnet bygges slik:
<selector>._domainkey.<domenet i d=>
Hvis meldingen har:
d=example.no; s=mail2026;
slår mottakeren opp:
mail2026._domainkey.example.no
Dette er en av de viktigste detaljene i DKIM-feilsøking. DNS-posten kan ligge helt riktig for selector1, men meldingen feiler hvis avsendersystemet bruker s=selector2.
Hvordan en DKIM TXT-post ser ut
En forenklet post kan se slik ut:
mail2026._domainkey.example.no. TXT "v=DKIM1; k=rsa; p=<offentlig-nøkkel>"
Feltene betyr:
| Del | Betydning |
|---|---|
mail2026 | selector som avsendersystemet bruker |
_domainkey | fast navnedel for DKIM-oppslag |
example.no | signeringsdomenet fra d= |
v=DKIM1 | identifiserer DKIM-nøkkelposten |
k=rsa | nøkkeltypen i dette eksemplet |
p= | den offentlige nøkkelen |
Ikke publiser teksten <offentlig-nøkkel>. Leverandøren skal gi deg den virkelige verdien. Privatnøkkelen skal aldri inn i DNS, e-post eller et kontaktskjema.
En tom p=-verdi betyr at nøkkelen er tilbakekalt. Den er ikke en ufarlig plassholder for «kommer senere».
Hvis du først trenger å forstå feltene i et DNS-panel, anførselstegn og hvordan lange tekstverdier vises, les TXT-poster i DNS forklart .
TXT eller CNAME?
DKIM-nøkkelen hentes som en TXT-post, men mange leverandører ber kunden opprette en CNAME på selectornavnet. CNAME-en peker da til et navn leverandøren styrer, hvor den faktiske nøkkelposten kan ligge.
Eksempel på prinsippet:
mail2026._domainkey.example.no. CNAME customer123.keys.provider.example.
Forskjellen er operativ:
| Løsning | Hvem publiserer nøkkelverdien? | Konsekvens ved rotasjon |
|---|---|---|
| TXT i kundens sone | Kunden eller DNS-ansvarlig | DNS-posten må normalt oppdateres hos kunden |
| CNAME til leverandør | Leverandøren på målnavnet | Leverandøren kan ofte rotere nøkkelen uten ny kundeverdi |
Bruk posttypen leverandøren ber om. Ikke konverter CNAME til TXT på eget initiativ, og ikke legg en CNAME på et navn som allerede har andre poster. DNS-reglene tillater normalt ikke at CNAME deler navn med andre data.
Hvorfor flere DKIM-poster er normalt
Selectoren gjør at ett domene kan ha flere nøkler samtidig. Det er nyttig når virksomheten har:
- vanlig e-post hos én leverandør
- faktura fra et økonomisystem
- nyhetsbrev fra en utsendelsesplattform
- gammel og ny nøkkel under en kontrollert rotasjon
Hver tjeneste kan få sin egen selector og privatnøkkel. Da kan én tilgang fjernes eller roteres uten å forstyrre alle andre avsendere.
Dette skiller DKIM fra SPF. DKIM-postene ligger på separate selectornavn, mens et bestemt navn bare skal ha én samlet SPF-policy.
Hva et DKIM-resultat faktisk beviser
Når DKIM består, har mottakeren kontrollert at:
- signaturen kan verifiseres med nøkkelen under
s=ogd= - de signerte meldingshodene og innholdet ikke er endret på en måte som bryter signaturen
- systemet som hadde privatnøkkelen kunne lage signaturen
Det beviser ikke alene at:
- personen i det synlige Fra-feltet sendte meldingen
- meldingen er sann eller trygg
- kontoen eller avsendertjenesten ikke er kompromittert
- DKIM-domenet samsvarer med synlig Fra-domene
- meldingen skal havne i innboksen
En angriper som får tilgang til en legitim konto eller privatnøkkel kan også lage gyldige signaturer. DKIM må derfor kombineres med tilgangskontroll, hendelseshåndtering og DMARC.
DKIM-pass er ikke alltid DMARC-pass
DMARC kontrollerer om signeringsdomenet i d= er aligned med domenet brukeren ser i Fra-feltet. En leverandør kan signere gyldig med sitt eget domene, men likevel ikke gi DKIM-alignment for kundens domene.
Eksempel:
| Synlig Fra-domene | DKIM d= | DKIM | DKIM-alignment for DMARC |
|---|---|---|---|
example.no | example.no | kan bestå | ja |
example.no | mail.example.no | kan bestå | normalt ja ved avslappet alignment |
example.no | provider.example | kan bestå | nei |
Derfor må du kontrollere både dkim=pass og DMARC-resultatet i en faktisk mottatt melding. Se SPF, DKIM og DMARC forklart
for sammenhengen.
Fire lag som alle må virke
En DNS-post alene aktiverer ikke DKIM. Hele kjeden må være på plass:
| Lag | Kontrollspørsmål |
|---|---|
| Nøkkel | Har avsendersystemet riktig privatnøkkel? |
| Signering | Legger den faktiske avsenderstrømmen til DKIM-Signature? |
| DNS | Finner mottakeren riktig offentlig nøkkel for s= og d=? |
| Alignment | Passer d= med synlig Fra-domene etter DMARC-reglene? |
«DKIM-post funnet» er derfor ikke det samme som «DKIM er ferdig satt opp».
Vanlige DNS-feil
| Symptom | Typisk feil | Kontroll |
|---|---|---|
| Nøkkelen finnes ikke | Feil selector eller signeringsdomene | Sammenlign s= og d= i meldingen med DNS-navnet |
| Navnet ender med domenet to ganger | DNS-panelet la til sonen automatisk | Se autoritativt DNS-svar, ikke bare skjemafeltet |
| Uventet CNAME-resultat | Feil mål eller leverandøren har fjernet nøkkelen | Følg CNAME-kjeden til TXT-svaret |
| Nøkkelen ser avkortet ut | Verdi ble limt inn feil eller vises i tekstbiter | Sammenlign hele DNS-svaret med leverandørverdien |
| Nøkkelen finnes, men ingen signatur | Signering er ikke aktivert eller meldingen bruker en annen rute | Undersøk meldingshodet og faktisk avsendersystem |
dkim=pass, men dmarc=fail | d= er ikke aligned med synlig Fra | Sett opp kundedomene hos avsendertjenesten |
| Bare noen meldinger feiler | Flere servere, selectorer eller strømmer | Grupper feilen etter selector og avsenderkilde |
En lang TXT-verdi kan vises som flere tekststrenger i DNS-verktøy. Det betyr ikke nødvendigvis at den er ødelagt; DNS-programvaren kan sette delene sammen ved svar. Kontroller den ferdige verdien med et egnet oppslag og leverandørens verifisering.
Slik kontrollerer du posten
Hvis du kjenner selector og signeringsdomene, kan du spørre DNS:
dig TXT mail2026._domainkey.example.no +short
dig CNAME mail2026._domainkey.example.no +short
Kjør bare kommandoen som er relevant for posttypen, eller bruk begge for å forstå en ukjent konfigurasjon. Et offentlig DNS-oppslag viser om posten kan finnes; det viser ikke om meldinger faktisk signeres.
Den avgjørende testen er en melding gjennom den virkelige avsenderstrømmen. Kontroller DKIM-Signature, Authentication-Results, d=, s= og DMARC-alignment hos en ekstern mottaker dere kontrollerer.
Oppsett og rotasjon
Denne siden forklarer selve DNS-posten. For en komplett arbeidsrekkefølge—kartlegging av avsendere, publisering, aktivering, testing, DMARC-kontroll og nøkkelrotasjon—bruk DKIM-oppsett steg for steg .
Den tekniske standarden er dokumentert i RFC 6376 . Leverandørens verdier og aktiveringssteg må likevel følges for den aktuelle tjenesten.
Har bedriften funnet riktig navn?
Sjekk om .no-domenet er ledig. Et .no-domene koster 199,- per år, også ved fornyelse.