DKIM fejler, men dit DNS ser rigtigt ud — det er sandsynligvis selectoren

Det her er en af de mest frustrerende tilstande i en email-opsætning: din udbyder siger, at DKIM ikke er verificeret, SPF og DMARC går begge igennem, og når du slår dit DNS op, ligger DKIM-nøglen lige der. Alle offentlige DKIM-tjekkere er enige om, at recorden er gyldig.

De har alle ret. Og mailen bliver stadig ikke signeret, som din afsender forventer.

Hvad en selector faktisk er

DKIM-nøgler bor ikke i roden af dit domæne. De bor under en selector, på <selector>._domainkey.ditdomæne.dk. Selectoren er en etiket, der lader ét domæne publicere mange nøgler på samme tid — én til din mailhost, én til dit faktureringssystem, én til din marketingplatform.

Det er hele fælden. Et domæne kan helt legitimt have flere gyldige DKIM-nøgler, og en tjekker, der finder en nøgle, vil gladeligt fortælle dig, at DKIM er sat op. Men signaturverificering handler ikke om, hvorvidt domænet har en nøgle. Den går sådan:

1. Afsendersystemet signerer beskeden og stempler den selector, det brugte, ind i headeren: DKIM-Signature: … s=zc1; d=ditdomæne.dk.
2. Modtageren læser den selector, slår zc1._domainkey.ditdomæne.dk op og verificerer mod den nøgle.

Signerer din afsender med zc1, og den eneste nøgle du har publiceret ligger under smtp, så slår modtageren zc1._domainkey op, finder intet, og signaturen fejler. Imens ligger smtp._domainkey og er fuldstændig gyldig og fuldstændig irrelevant.

Hvorfor det sker så ofte

Fordi den forkerte nøgle typisk er en rigtig nøgle, som noget andet har lagt der af en god grund.

Hostes dine mailbokse et sted — en webmail-udbyder, Microsoft 365, et hostingselskab — så har den udbyder næsten helt sikkert sat DKIM op til sin egen udgående mail, under sin egen selector. Du tilføjer derefter en marketing- eller transaktionsplatform, ser at "DKIM" allerede står i dit DNS, og konkluderer rimeligt nok, at det er på plads.

Det er på plads for din mailudbyder. Det er ikke på plads for din nye afsender. Det er to separate signaturer med to separate selectors, og de erstatter ikke hinanden.

Sådan diagnosticerer du det på to minutter

Send dig selv én rigtig besked gennem den afsender, der fejler, og læs de rå headers. I Gmail: Vis original. Se efter:

DKIM-Signature: v=1; a=rsa-sha256; s=zc1; d=ditdomæne.dk; …

Værdien i s= er den selector, din afsender reelt bruger. Det er sandheden — ikke hvad dit DNS-panel viser, ikke hvad en tjekker siger. Slå så præcis det navn op:

dig +short zc1._domainkey.ditdomæne.dk TXT
dig +short zc1._domainkey.ditdomæne.dk CNAME

Tomt output er dit svar. Publicér den record, din afsender bad dig publicere, under den selector den signerer med, og signaturen verificerer.

Et nyttigt sidetjek, mens du er i headerne: Authentication-Results vil sige dkim=fail eller dkim=none — og none betyder specifikt "der er ingen signatur at tjekke for den selector", hvilket er et andet problem end en signatur, der fejlede kryptografisk.

Det, der gør det værre: DMARC

Fejler DKIM, og din DMARC-politik er p=quarantine eller p=reject, mangler du ikke bare en signatur — du instruerer aktivt mailudbydere i at mistro mailen.

DMARC går igennem, når SPF eller DKIM går igennem og aligner med From-domænet. Så et brudt DKIM alene er til at overleve, hvis SPF aligner. Men kombinationen folk rammer er: SPF alignet ad én vej, DKIM fejlende, DMARC sat til reject, og en afsendelsesplatform hvis envelope-afsender ikke er deres eget domæne — og så fejler alignment på begge fronter, og mailen ryger i spam eller ingenting.

Rækkefølgen der virker: publicér nøglen, verificér signaturen på en rigtig besked, og derefter stram DMARC. Bliv på p=none, mens du stadig retter autentificering. p=none indsamler stadig rapporter; den straffer dig bare ikke for en opsætning, der ikke er færdig.

Hvad godt værktøj bør fortælle dig

Et verificeringstjek, der returnerer et rødt kryds og intet andet, er tæt på ubrugeligt her, fordi fejlen og løsningen ikke er synlige fra samme sted. "Ikke verificeret" er sandt af mindst fire forskellige grunde — slet ingen record, en record under en anden selector, et CNAME der peger på det forkerte mål, eller at afsendelsesplatformens egen nøgle-host ikke kan nås — og kun én af dem er noget, du kan rette i dit DNS-panel.

Den sidste betyder mere, end den lyder. Ligger fejlen hos platformen, vil en tjekker, der formulerer alt som din fejl, sende dig på rov i DNS, du aldrig behøvede at røre.

WeZends domæneverificering returnerer en maskinlæsbar reason sammen med hvert tjek plus et menneskeligt hint — så wrong_selector fortæller dig, hvilken selector du har publiceret under, og hvilken vi signerer med, og esp_target_unresolved siger lige ud, at problemet er vores. Se Email: domæner, DNS & afsendelse for svarformatet, eller kør et domæne gennem den gratis SPF-, DKIM- & DMARC-tjekker.

Kort fortalt

• En gyldig DKIM-nøgle i dit DNS betyder ikke den rigtige nøgle til den afsender, du debugger.
• Værdien i s= i en rigtig beskeds DKIM-Signature-header er den eneste selector, der betyder noget.
• Kør dig på præcis det <selector>._domainkey-navn. Tomt betyder fundet.
• Ret autentificering før du strammer DMARC, ikke efter.