DKIM misslyckas men din DNS ser rätt ut — det är troligen selektorn

Det här är ett av de mest frustrerande tillstånden i en e-postuppsättning: din leverantör säger att DKIM inte är verifierat, SPF och DMARC går båda igenom, och när du slår upp din DNS ligger DKIM-nyckeln precis där. Varje offentligt DKIM-kontrollverktyg är enigt om att posten är giltig.

De har alla rätt. Och posten signeras fortfarande inte som din avsändare förväntar sig.

Vad en selektor faktiskt är

DKIM-nycklar bor inte i domänens rot. De bor under en selektor, på <selektor>._domainkey.dindomän.se. Selektorn är en etikett som låter en domän publicera många nycklar samtidigt — en för din e-postvärd, en för ditt faktureringssystem, en för din marknadsplattform.

Det är hela fällan. En domän kan fullt legitimt ha flera giltiga DKIM-nycklar, och ett verktyg som hittar en nyckel säger gärna att DKIM är konfigurerat. Men signaturverifiering handlar inte om huruvida domänen har en nyckel:

1. Avsändarsystemet signerar meddelandet och stämplar in selektorn det använde i headern: DKIM-Signature: … s=zc1; d=dindomän.se.
2. Mottagaren läser den selektorn, slår upp zc1._domainkey.dindomän.se och verifierar mot den nyckeln.

Signerar din avsändare med zc1 och den enda nyckeln du publicerat ligger under smtp, slår mottagaren upp zc1._domainkey, hittar inget, och signaturen misslyckas.

Varför det händer så ofta

Därför att den felaktiga nyckeln oftast är en riktig nyckel som något annat lagt dit av goda skäl. Hostas dina brevlådor någonstans har den leverantören nästan säkert satt upp DKIM för sin egen utgående post, under sin egen selektor. Du lägger sedan till en marknads- eller transaktionsplattform, ser att "DKIM" redan finns i din DNS och drar den rimliga slutsatsen att det är klart. Det är klart för din e-postleverantör — inte för din nya avsändare.

Så diagnostiserar du det på två minuter

Skicka ett riktigt meddelande genom avsändaren som misslyckas och läs de råa headerna. I Gmail: Visa original. Leta efter:

DKIM-Signature: v=1; a=rsa-sha256; s=zc1; d=dindomän.se; …

Värdet i s= är selektorn din avsändare faktiskt använder — inte vad din DNS-panel visar. Slå upp exakt det namnet:

dig +short zc1._domainkey.dindomän.se TXT
dig +short zc1._domainkey.dindomän.se CNAME

Tom utmatning är ditt svar.

Det som gör det värre: DMARC

Misslyckas DKIM och din DMARC-policy är p=quarantine eller p=reject, saknar du inte bara en signatur — du instruerar aktivt e-postleverantörer att misstro posten. Ordningen som fungerar: publicera nyckeln, verifiera signaturen på ett riktigt meddelande, och därefter skärp DMARC. Stanna på p=none medan du fortfarande fixar autentisering.

Vad bra verktyg bör berätta

"Inte verifierat" är sant av minst fyra olika skäl — ingen post alls, en post under en annan selektor, ett CNAME mot fel mål, eller att plattformens egen nyckelvärd inte kan nås — och bara ett av dem är något du kan åtgärda i din DNS-panel.

WeZends domänverifiering returnerar en maskinläsbar reason tillsammans med varje kontroll plus ett mänskligt hint — så wrong_selector säger vilken selektor du publicerat under och vilken vi signerar med, och esp_target_unresolved säger rent ut att problemet är vårt. Se E-post: domäner, DNS & utskick, eller kör en domän genom den fria SPF-, DKIM- & DMARC-kontrollen.

Kort sagt

• En giltig DKIM-nyckel i din DNS betyder inte den rätta nyckeln för avsändaren du felsöker.
• Värdet i s= i ett riktigt meddelandes DKIM-Signature-header är den enda selektor som spelar roll.
• Kör dig på exakt det <selektor>._domainkey-namnet. Tomt betyder att du hittat felet.
• Åtgärda autentiseringen innan du skärper DMARC, inte efter.