DKIM verifiering beror på att offentligt verifieringsmaterial hämtas via DNS . En signatur kan vara kryptografiskt välformad men ändå förbli omöjlig att verifiera när den relevanta sökningen inte är tillgänglig. Undersök DNS sökvägen och tidpunkten för mottagarens försök innan du byter ut nycklar eller ändrar meddelandeinnehåll.
En lyckad uppslagning efter en incident är användbar återställningsbevis, men den fastställer inte vad som hände under det misslyckade försöket. Bevara det ursprungliga autentiseringsresultatet, meddelandet, tidsstämpeln och alla tillgängliga resolverloggar. Syftet är att förklara det observerade felet utan att göra anspråk på insyn i en mottagares infrastruktur som du inte har.
Fastställ den exakta sökningen och resultatet
Läs d och s från den drabbade DKIM-Signature och konstruera väljare slå upp under _domainkey för d. Under RFC 6376 §3.6.2.1 och RFC 1034 §3.6.2, om den stödda konfigurationen använder en CNAME, fånga kedjan och det slutliga verifieringssvaret. Inkludera svarskod, tid, resolver och auktoritativ server där tillgänglig.
RFC 6376 §6.1.2 särskiljer en fråga som inte svarar från en nyckelpost som inte finns. Den förra kan ge TEMPFAIL och ett senare försök; den senare kräver en no-key PERMFAIL för den signaturen. RFC 8601 §2.7.1 temperror beskriver likaså ett troligt övergående verifieringsfel. Förvandla inte alla DNS-relaterade fel till en enda diagnos.
Jämför åsikter utan att överdriva dem
Kontrollera den auktoritativa zonen och representativa rekursiva resolvers. En skillnad kan peka på inaktuella cachelagrade data, delegeringsinkonsekvenser eller problem med att nå en del av DNS sökvägen. Om ett leverantörshanterat mål är inblandat, undersök det målet såväl som det kundkontrollerade aliaset.
Registrera bevis för potentiella orsaker istället för att välja en från enbart feletiketten. En resolvers SERVFAIL behöver till exempel ytterligare diagnos; det är inte bevis på att nyckeln raderades. DNSSEC validering (se RFC 4035 §5.5), kan delegerings- och transportproblem kräva DNS operatörens loggar och expertis. Inaktivera inte validering som standardfix bara för att få en sökning att lyckas.
Följ ett tidsbaserat exempel
Illustrativ sekvens: en mottagare försöker hämta active1._domainkey.sender.example kl. 10:00 och rapporterar ett tillfälligt nyckelhämtningsfel. Klockan 10:05 hämtar en administratör en giltig nyckel från en annan resolver. Båda observationerna kan vara sanna. Den andra fastställer tillgänglighet för den frågan klockan 10:05, inte tillgänglighet för den första mottagaren fem minuter tidigare.
Däremot, om det auktoritativa svaret vid händelsen fastställer att den aktiva väljaren är frånvarande, kanske det inte löser konfigurationsproblemet att vänta på att ett övergående avbrott ska åtgärdas. Om posten återställs, negativ cachelagring under RFC 2308 §5 kan också påverka när andra resolvers observerar det. Exemplet är en diagnostisk tidslinje, inte ett uppmätt avbrott eller ett utlovat återhämtningsintervall.
Kontrollera resten av verifieringen efter återställning
Följande RFC 6376 §6.1.2 och RFC 6376 §6.1.3, när nyckelhämtning fungerar, bekräfta att den returnerade posten är användbar och motsvarar undertecknaren. En hämtad nyckel kan fortfarande återkallas, vara felaktig eller inkompatibel. En matchande nyckel kan inte kompensera för innehåll som ändrats efter signering. Håll uppslag, nyckelvalidering, body-hash-verifiering och signaturverifiering som separata steg i incidentregistret.
När flera signaturer finns, tar en misslyckad uppslagning inte nödvändigtvis bort alla justerade autentiseringsvägar. Under RFC 9989 §5.3.5, inspektera de andra signaturerna och SPF innan man avslutar det DMARC misslyckades. Under RFC 6376 §6.3 och RFC 9989 §5.4, mottagarens leveranspolicy är ett annat separat beslut; ett övergående DKIM problem garanterar inte vare sig uppskov eller acceptans.
Stäng avbrottet med kontrollerade tester
Efter DNS operatörens auktoriserade reparation, testa den berörda uppslagningen genom relevanta vyer och skicka nya meddelanden via den ursprungliga rutten. Registrera förväntade och observerade resultat. Be om DNS och leverantörsincidentbevis när orsaken ligger utanför din administrativa räckvidd.
Håll en inventering av delegerade väljarmål och deras ägare så att nästa varning når rätt team. Övervaka beroendet som faktiskt misslyckades, men beskriv övervakningsomfånget ärligt: en periodisk offentlig förfrågan reproducerar inte varje mottagares cache, nätverk eller valideringsbeteende. Avslutning bör ange vad som återhämtats, vilka bevis som stöder diagnosen och vad som förblir obemärkt.
Bevara en begränsad slutsats
Behåll 10:00-misslyckandet och 10:05-framgången som två poster, var och en med resolver, frågenamn, resultat och synlighetsgränser. Mellanrummet på fem minuter är illustrativt, inte ett återhämtningsmål. DNS TTL är ett färskhetsintervall, inte en global återkallelsesfrist: RFC 8767 §4 tillåter kvalificerad inaktuell användning. Inget resolveravbrott, återhämtning eller posttest uppmättes.