A DKIM no-key diagnostik betyder i allmänhet att verifieraren inte kunde hitta den erforderliga verifieringsnyckeln för en signatur. Den användbara utgångspunkten är meddelandets faktiska väljare och signeringsdomän. Att gissa en vanlig väljare eller fråga efter den synliga From-domänen kan leda till ett helt korrekt svar på fel DNS fråga.
Bevara det ursprungliga mottagna meddelandet och dess betrodda autentiseringsresultat. Anteckna observationstiden, eftersom nyckeln kan ha ändrats sedan leveransen. Undersök sedan den exakta signaturen som anges i resultatet; meddelanden kan bära flera signaturer med olika uppslagsnamn och resultat.
Härled den exakta DNS frågan
Läs s och d från DKIM-Signature. Med s=campaign7 och d=mailer.example, är sökningen campaign7._domainkey.mailer.example . Väljaren är inte ett universellt leverantörsnamn, och signeringsdomänen behöver inte vara densamma som den synliga From-domänen. RFC 6376 §3.1, RFC 6376 §3.5 och RFC 6376 §3.6.2.1 definiera dessa element.
Fråga namnet och posttypen som förväntas av den konfiguration som stöds. Under RFC 1034 §3.6.2, om tjänsten använder en CNAME, följ den till verifieringsdata och fånga det mellanliggande målet. Kontrollera om det finns fel i DNS-redigeraren, till exempel ett suffix som har lagts till två gånger, ett rekord publiceras i fel zon eller en väljare kopierad från en annan hyresgäst.
Skilj frånvaro från otillgänglighet
Ett negativt svar som inte fastställer någon motsvarande nyckel skiljer sig från en fråga med tidsgräns. RFC 6376 §6.1.2 kräver PERMFAIL för en frånvarande nyckel och tillåter TEMPFAIL när nyckelfrågan inte svarar. Dessa är verifieringsbearbetningsresultat; den exakta etiketten som visas i en diagnostisk produkt kan skilja sig åt.
Fånga DNS svarskoden och svara, inte bara en röd indikator. Jämför auktoritativa svar med den rekursiva synen som är relevant för den misslyckade mottagaren där bevis finns. En framgångsrik sökning från din bärbara dator senare bevisar inte att nyckeln var tillgänglig vid den ursprungliga utvärderingstiden.
Använd ett tregrenat diagnosträd
Först, om meddelandet inte innehåller någon DKIM-Signature , undersök signeringskonfigurationen snarare än en väljarsökning. Det finns inga meddelandespecifika s- och d-par att hämta. För det andra, om en signatur finns och dess nyckel saknas, inspektera publicerings-, migrerings- och pensionshistorik. För det tredje, om nyckeln är tillgänglig men body hash eller signaturen misslyckas, flytta till innehåll, nyckelmatchning eller kryptografiska kontroller.
Illustrativt fall: ett meddelande namnger väljaren old7, medan DNS endast innehåller new8. Att publicera new8 korrekt kan inte verifiera den gamla7-signaturen. Om old7 avsiktligt togs bort, kan felet förväntas för försenad eller arkiverad e-post. Om old7 av misstag togs bort och dess nyckel fortfarande är pålitlig, kan återställning av korrekt verifieringsdata vara en lämplig godkänd reparation. Det här är diagnostiska scenarier, inte utförda test av hyresgäster.
Kontrollera nyckelns giltighet efter hämtning
Att hitta ett TXT svar avslutar inte verifieringen; RFC 6376 §3.6.1 och RFC 6376 §6.1.2 definiera nyckelsyntax och validering. En felaktig nyckel, ett tomt p-värde som indikerar återkallelse eller inkompatibelt nyckelmaterial är inte en användbar verifieringsnyckel. Under RFC 4592 §3.3.3, ett jokertecken TXT post kan också producera ett svar som är irrelevant för DKIM . Ändra inte varje oanvändbart svar som en saknad väljare.
Använd leverantörens exakta aktuella postvärde eller en känd, auktoriserad konfigurationsbackup. Generera aldrig en slumpmässig publik nyckel för att tillfredsställa uppslagningen: den matchar inte den privata nyckeln som skapade signaturen. Undvik att ersätta poster vid en delad sökning utan att granska andra avsändare och försenade meddelanden.
Verifiera korrigeringen med nya bevis
Efter en auktoriserad reparation, inspektera DNS och skicka ny kontrollerad post via den berörda vägen. Bevara det mottagna resultatet, signaturidentitet och inriktning värdering. Om det ursprungliga provet nu verifierar, registrera det som en senare omkontroll istället för att skriva om dess historiska mottagarresultat.
Stäng incidenten med saknat namn, orsak, återställt beroende och förebyggande åtgärd. En väljarinventering och en checklista för pensionering minskar återfall mer effektivt än att upprepade gånger lägga till poster när en checker rapporterar rött.
Bevara en begränsad slutsats
För old7 kontra new8, bevara den gamla signaturens uppslag istället för att kopiera den aktuella väljaren till incidentposten. En frånvarande old7-nyckel, en timeout och en tom-p-återkallelse är olika observationer. En senare framgångsrik omkontroll måste behålla sin senare tid. Ingen reparation eller signaturverifiering utfördes för undervisningsscenariot.