DKIM feiler, men DNS-en din ser riktig ut — det er sannsynligvis selektoren

Dette er en av de mest frustrerende tilstandene i et e-postoppsett: leverandøren din sier at DKIM ikke er verifisert, SPF og DMARC går begge gjennom, og når du slår opp DNS-en din ligger DKIM-nøkkelen rett der. Alle offentlige DKIM-sjekkere er enige om at posten er gyldig.

De har alle rett. Og posten blir fortsatt ikke signert slik avsenderen din forventer.

Hva en selektor faktisk er

DKIM-nøkler bor ikke i roten av domenet. De bor under en selektor, på <selektor>._domainkey.dittdomene.no. Selektoren er en merkelapp som lar ett domene publisere mange nøkler samtidig — én for e-postverten din, én for faktureringssystemet, én for markedsføringsplattformen.

Det er hele fella. Et domene kan helt legitimt ha flere gyldige DKIM-nøkler, og en sjekker som finner en nøkkel sier gjerne at DKIM er satt opp. Men signaturverifisering handler ikke om hvorvidt domenet har en nøkkel:

1. Avsendersystemet signerer meldingen og stempler selektoren det brukte inn i headeren: DKIM-Signature: … s=zc1; d=dittdomene.no.
2. Mottakeren leser den selektoren, slår opp zc1._domainkey.dittdomene.no og verifiserer mot den nøkkelen.

Signerer avsenderen din med zc1, og den eneste nøkkelen du har publisert ligger under smtp, slår mottakeren opp zc1._domainkey, finner ingenting, og signaturen feiler.

Hvorfor det skjer så ofte

Fordi den feil nøkkelen vanligvis er en ekte nøkkel som noe annet la der av god grunn. Hostes postboksene dine et sted, har den leverandøren nesten sikkert satt opp DKIM for sin egen utgående post, under sin egen selektor. Du legger så til en markedsførings- eller transaksjonsplattform, ser at "DKIM" allerede står i DNS-en din, og konkluderer rimelig nok med at det er på plass. Det er på plass for e-postleverandøren din — ikke for den nye avsenderen.

Slik diagnostiserer du det på to minutter

Send deg selv én ekte melding gjennom avsenderen som feiler, og les de rå headerne. I Gmail: Vis original. Se etter:

DKIM-Signature: v=1; a=rsa-sha256; s=zc1; d=dittdomene.no; …

Verdien i s= er selektoren avsenderen faktisk bruker — ikke hva DNS-panelet viser. Slå opp nøyaktig det navnet:

dig +short zc1._domainkey.dittdomene.no TXT
dig +short zc1._domainkey.dittdomene.no CNAME

Tomt output er svaret ditt.

Det som gjør det verre: DMARC

Feiler DKIM og DMARC-policyen din er p=quarantine eller p=reject, mangler du ikke bare en signatur — du instruerer aktivt e-postleverandører i å mistro posten. Rekkefølgen som virker: publiser nøkkelen, verifiser signaturen på en ekte melding, og deretter stram DMARC. Bli på p=none mens du fortsatt retter autentisering.

Hva godt verktøy bør fortelle deg

"Ikke verifisert" er sant av minst fire ulike grunner — ingen post i det hele tatt, en post under en annen selektor, et CNAME mot feil mål, eller at plattformens egen nøkkelvert ikke kan nås — og bare én av dem er noe du kan rette i DNS-panelet ditt.

WeZends domeneverifisering returnerer en maskinlesbar reason sammen med hver sjekk pluss et menneskelig hint — så wrong_selector sier hvilken selektor du har publisert under og hvilken vi signerer med, og esp_target_unresolved sier rett ut at problemet er vårt. Se E-post: domener, DNS & utsending, eller kjør et domene gjennom den gratis SPF-, DKIM- & DMARC-sjekkeren.

Kort fortalt

• En gyldig DKIM-nøkkel i DNS-en din betyr ikke den riktige nøkkelen for avsenderen du feilsøker.
• Verdien i s= i en ekte meldings DKIM-Signature-header er den eneste selektoren som betyr noe.
• Kjør dig på nøyaktig det <selektor>._domainkey-navnet. Tomt betyr at du har funnet feilen.
• Rett autentiseringen før du strammer DMARC, ikke etter.