Sette opp DKIM uten å gjette DNS-verdier

DKIM er ikke én standardverdi du kan kopiere fra en guide. Hver e-postleverandør eller avsendertjeneste lager en selector, et signeringsdomene og en DNS-verdi for akkurat deres oppsett. Noen bruker TXT, andre ber deg opprette CNAME.

Den sikre arbeidsrekkefølgen er å kartlegge alle avsendere, hente verdiene hos hver leverandør, publisere DNS, aktivere signeringen og kontrollere en ekte melding fra hver strøm.

Hva DKIM faktisk kontrollerer

Avsendersystemet lager en kryptografisk signatur over utvalgte meldingshoder og meldingsinnholdet. Mottakeren bruker feltene i DKIM-Signature til å slå opp offentlig nøkkel og kontrollere signaturen.

Viktige felt er:

Felt	Betydning
`d=`	domenet som tar ansvar for DKIM-signaturen
`s=`	selector som peker til riktig nøkkel i DNS
`h=`	meldingshoder signaturen dekker
`bh=`	hash av meldingsinnholdet etter DKIM-reglene
`b=`	selve signaturen
`c=`	kanonisering av meldingshode og innhold

Nøkkelen slås normalt opp på:

<selector>._domainkey.<signeringsdomene>

Hvis s=selector1 og d=example.no, blir oppslaget selector1._domainkey.example.no. Bruk verdiene fra den faktiske meldingen eller leverandøren, ikke ordene i eksemplet.

RFC 6376 beskriver DKIM-signaturen og DNS-oppslaget.

DKIM beviser ikke alt

En godkjent signatur viser at:

systemet med privatnøkkelen signerte meldingen
de signerte feltene og innholdet ikke er endret på en måte som bryter signaturen
offentlig nøkkel kunne hentes fra domenet i d=

Den viser ikke alene at:

personen i synlig Fra-felt godkjente meldingen
meldingen er sann eller ufarlig
signeringsdomenet er det samme som synlig Fra-domene
kontoen eller avsendertjenesten ikke er kompromittert
meldingen skal leveres til innboksen

Det er DMARC som vurderer om DKIM-domenet er justert mot synlig Fra-domene. En melding kan derfor ha dkim=pass og likevel feile DMARC.

Før oppsett: finn alle som sender

Lag én rad per avsenderstrøm:

Avsender	Synlig Fra-domene	Teknisk tjeneste	Eier	DKIM-status
personpost	`bedrift.no`	e-postleverandør	IT	ikke testet
kontaktskjema	`bedrift.no` eller tjenestedomene	nettside/SMTP-tjeneste	nettstedseier	ikke testet
faktura	`bedrift.no`	økonomisystem	økonomi	ikke testet
nyhetsbrev	`nytt.bedrift.no`	utsendelsesplattform	marked	ikke testet
support	`bedrift.no`	saksverktøy	kundeservice	ikke testet

DMARC-rapporter, leverandørregister, DNS og meldinger i Sendt kan hjelpe, men ingen kilde er nødvendigvis komplett. Ukjente avsendere skal undersøkes før strengere policy.

DKIM-oppsett i ti trinn

1. Velg riktig domene hos leverandøren

Legg til eller bekreft domenet i avsendertjenesten. Hvis tjenesten bare signerer med sitt eget domene, kan DKIM bestå uten å være justert for DMARC. Se etter funksjon som kalles custom DKIM, domain authentication eller tilsvarende.

2. Generer verdiene i avsendertjenesten

Leverandøren skal oppgi:

posttype, vanligvis TXT eller CNAME
fullt navn eller host
selector
mål eller offentlig nøkkel
eventuelt TTL
om signering må aktiveres etter DNS-kontroll

Ikke generer egen privatnøkkel med mindre dere drifter signeringssystemet selv eller leverandøren uttrykkelig krever det. Privatnøkkelen skal ikke inn i DNS, e-post eller supportsak.

3. Avklar hvordan DNS-panelet tolker navn

Noen paneler forventer bare selector._domainkey, mens andre forventer hele navnet selector._domainkey.example.no. Hvis sonen legges til automatisk og du limer inn hele navnet, kan resultatet bli dobbelt domene.

Kontroller også om panelet:

legger anførselstegn rundt TXT automatisk
splitter en lang TXT-verdi i flere tekststrenger
avviser eller endrer mellomrom
bruker @ for rotdomenet

Ikke legg inn synlige linjeskift eller ekstra mellomrom i nøkkelverdien med mindre leverandøren dokumenterer det.

4. Publiser posten nøyaktig

For TXT kan leverandørverdien ligne:

v=DKIM1; k=rsa; p=<offentlig-nøkkel>

For CNAME kan oppsettet i stedet peke selectoren til et navn leverandøren styrer:

selector._domainkey.example.no CNAME selector.provider.example

Dette er formatillustrasjoner, ikke verdier som skal kopieres. Publiser aldri p=<offentlig-nøkkel> bokstavelig.

5. Kontroller DNS før aktivering

Spør den autoritative DNS-en og en offentlig resolver:

dig TXT selector._domainkey.example.no +short
dig CNAME selector._domainkey.example.no +short

Bruk bare oppslaget som passer posttypen. Kontroller at navnet og verdien samsvarer med leverandørens instruks. En nettbasert DNS-kontroll kan også brukes, men ikke last opp private meldinger eller nøkler til et tilfeldig testverktøy.

Ventetiden styres blant annet av gammel TTL, cache og leverandørens kontroll. Ikke lov at alle resolverne ser endringen etter et bestemt antall minutter.

6. Be leverandøren verifisere domenet

Bruk leverandørens verifiseringsknapp eller status. «DNS-post funnet» betyr fortsatt ikke nødvendigvis at utgående meldinger signeres.

7. Aktiver DKIM-signering

Noen plattformer begynner automatisk, andre krever en egen bryter. Dokumenter dato, selector, signeringsdomene og hvem som aktiverte.

8. Send gjennom hver virkelige avsenderstrøm

Test til en ekstern postboks dere kontrollerer:

vanlig melding fra en bruker
melding fra delt postkasse eller alias
faktura eller systemmelding
kontaktskjema
nyhetsbrev
svar og videresending der arbeidsflyten trenger det

Ikke bruk sensitive produksjonsdata i testen.

9. Les meldingshodet

Finn Authentication-Results og DKIM-Signature. Kontroller:

dkim=pass
forventet header.d=
forventet header.s=
synlig Fra-domene
om DMARC består gjennom DKIM- eller SPF-justering

Mottakere kan legge til flere Authentication-Results. Stol på resultatet fra systemet som faktisk vurderte meldingen ved mottak, ikke en tilfeldig linje lagt til tidligere i ruten.

10. Følg DMARC-rapportene

Se om den nye kilden består med riktig volum. En enkelt vellykket test dekker ikke alle servere, regioner, underdomener eller meldingsvarianter.

Guiden til DMARC-rapporter forklarer hvordan dataene leses.

DKIM og DMARC-justering

Ved avslappet justering kan d=mailer.example.no passe med synlig Fra-domene example.no fordi organisasjonsdomenet er det samme. Ved streng justering må domenene samsvare mer nøyaktig.

Eksempler:

Synlig Fra	DKIM `d=`	Avslappet justering	Kommentar
`example.no`	`example.no`	ja	direkte samsvar
`example.no`	`mailer.example.no`	normalt ja	samme organisasjonsdomene
`example.no`	`provider.example`	nei	DKIM kan bestå uten DMARC-justering
`news.example.no`	`example.no`	normalt ja	vurder underdomenepolicy og ønsket isolasjon

Bruk faktisk DMARC-resultat i meldingshode og rapport, særlig for landskodedomener og kompliserte suffikser. Ikke bygg egen justeringslogikk ut fra «de to siste delene» av domenet.

Vanlige feil

Symptom	Sannsynlig årsak	Kontroll
ingen `DKIM-Signature`	signering er ikke aktivert eller strømmen går via annet system	spor faktisk avsendertjeneste og aktiver der
nøkkel finnes ikke	feil selector, feil domene eller dobbelt sonenavn	sammenlign `s=` og `d=` med DNS-oppslaget
nøkkel er avkortet	TXT-verdien ble endret i panelet	hent autoritativt svar og sammenlign uten formateringsstøy
body hash feiler	gateway, footer, liste eller annet system endrer innholdet etter signering	signer etter endringen eller juster flyten
bare noen meldinger feiler	flere servere, selectorer eller ruter	grupper på kilde, selector og meldingsvariant
`dkim=pass`, `dmarc=fail`	signeringsdomenet er ikke justert	aktiver custom DKIM eller få SPF-justering etter plan
midlertidig DNS-feil	resolver eller autoritativ DNS svarer ikke stabilt	undersøk DNS-drift før policy skjerpes
gammel selector brukes	rotasjon er bare delvis aktivert	kontroller alle signeringsnoder og køer

En e-postliste eller sikkerhetsgateway kan legitimt endre meldingen etter signering. Løsningen er å forstå rekkefølgen, ikke å publisere enda en tilfeldig nøkkel.

Flere avsendertjenester

Hver tjeneste bør normalt få sin egen selector. Da kan virksomheten:

trekke tilbake én leverandør uten å påvirke alle
rotere nøkler uavhengig
se hvilken tjeneste en signatur tilhører
unngå deling av privatnøkkel

Det er normalt å ha mange DKIM-poster fordi selectorene gir ulike DNS-navn. Dette skiller DKIM fra SPF, som skal ha én SPF-policy per navn.

For markedsføring og store utsendelser kan et eget underdomene gi tydeligere ansvar og omdømmeskille. Det må fortsatt settes opp med riktige Fra-adresser, DKIM, SPF, DMARC, returdomene og lenkedomener.

Nøkkelvalg og rotasjon

RFC 8301 oppdaterer kryptografiske krav for DKIM. I praksis bør virksomheten bruke leverandørens vedlikeholdte anbefaling og sterkeste bredt støttede valg som passer mottakerne.

Ved rotasjon:

Opprett en ny selector og nøkkel.
Publiser den nye offentlige posten.
Kontroller DNS fra flere steder.
Aktiver ny signering på alle noder.
Test alle avsenderstrømmer og DMARC-justering.
Overvåk om gammel selector fortsatt brukes.
Vent minst gammel TTL og dokumentert maksimal meldingskø før sletting.
Fjern gammel nøkkel og DNS-post når den ikke lenger trengs.

Roter straks ved mulig privatnøkkelkompromittering eller uautorisert leverandørtilgang. Planlagt rotasjonsfrekvens bør følge leverandørstøtte, risiko og virksomhetens nøkkellivssyklus – ikke en tilfeldig kalenderregel uten test.

Før DMARC håndheves

alle legitime kilder er kartlagt
hver strøm signerer med forventet domene
DMARC-rapportene viser volum og feil
videresending og tredjepartsflyt er forstått
ansvarlig kan rulle tilbake endringen
kundeservice vet hvordan leveringsfeil rapporteres
underdomenepolicy og rapportadresser er bevisst valgt

Følg planen for gradvis DMARC-policy fremfor å hoppe rett til p=reject.

DKIM hos Vymo

Vymos publiserte e-postplaner oppgir ikke selector, DNS-verdi, nøkkelalgoritme, rotasjonsrutine eller om kunden kan administrere DKIM selv. Ikke bruk eksempelverdier eller anta at én bestemt Vymo-post gjelder alle domener.

Før DNS endres, be om de nøyaktige DKIM-opplysningene for domenet . Oppgi domenenavn, avsendertjenester og hvem som styrer DNS. Ikke send privatnøkkel, passord eller en sensitiv testmelding i skjemaet.