En autentiseringsincident innehåller ofta flera klockor: en rapports täckta intervall, rapportens ankomst, en DNS ändring, en applikationsdistribution och ett kontrollerat test. Att placera dem på en tidslinje är bara till hjälp om varje händelse behåller sin ursprungliga betydelse. En daglig samlad rapport kan vanligtvis inte berätta den exakta minuten när varje inkluderat meddelande misslyckades.
Upprätta en gemensam tidsbas
Referenser: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normalisera visade tidsstämplar till en deklarerad tidszon med bibehållen ursprungliga värden och precision. Spela in klockkällor och känd osäkerhet. Skilj rapportintervallet från ankomst- och intagstidstämplar. Sen rapportleverans ska inte plottas som en ny sändning i det ögonblick då bilagan kom.
Omfattning undersökningen till en författare domän och verifierad tjänst där det är möjligt. Håll oklassificerade källor åtskilda. Bevara reporter- och rapportidentitet, meddelandeantal, källgrupper och utvärderade identiteter, tillsammans med dubbletter och överlappande beslut. Dessa detaljer avgör vilka observationer som med rätta kan jämföras.
Lägg till DNS bevis utan att skriva om historiken
Referenser: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Registrera den godkända ändringen, avsedd publiceringstid, auktoritativa observationer och eventuella resolverprover, inklusive uppslagstid och returnerad TTL. Ett aktuellt DNS svar fastställer vad den uppslagningen observerade nu; det är inte en fullständig historik över vad varje mottagare såg tidigare.
DNS cache är viktigt under RFC 1034 §3.6; kvalificerande serve-stale beteende under RFC 8767 §4 kan utöka cacheminnet utöver normal färskhet. Påstå inte att alla mottagare bytte vid publiceringsögonblicket eller exakt en som visas senare. Bevara tidigare konfiguration, ändringslogg och bevisgränser. Om ett rapportintervall sträcker sig över en policyändring, märk den som blandad eller potentiellt blandad i stället för att tilldela varje observation till den slutliga policyn.
Lägg till ansökan och mottagarbevis
Referenser: RFC 5321 §4.2.5.
Placera applikationsdistributioner, gatewayändringar och signeringsändringar bredvid DNS händelserna. Håll kontrollerade tester som individuella observationer med deras faktiska rutt, mottagare och resultat. En ansökningslogg kan visa inlämning eller acceptans vid ett hopp; det innebär inte nödvändigtvis slutleverans.
Använd dessa bevistyper för att testa konkurrerande förklaringar. En ökning av fel efter en DNS redigering kan också sammanfalla med en ny mall som ändrar signerat innehåll. Korrelation begränsar utredningen men identifierar inte orsaken utan ytterligare bevis.
Arbeta genom en avgränsad tidslinje
Illustrativt fall: en rapport täcker 00:00 till 24:00 UTC. En policyändring registreras kl. 12.00 och ett kontrollerat test kl. 12.20 godkänns. DKIM. Rapporten innehåller 80 passerande och 20 underkända observationer, som anländer nästa morgon klockan 05:00.
Du kan ange intervallsummor och det lyckade testet kl. 12:20. Du kan inte tilldela alla 20 misslyckanden före kl. 12.00 bara för att testet blev godkänt senare. Nästa åtgärd är att skaffa snävare mottagare eller applikationsbevis, eller köra ytterligare representativa tester. Ankomsten kl. 05.00 är en insamlingshändelse, inte tiden för de 20 misslyckandena.
Avsluta med ett kausalt uttalande om rätt styrka
Märk slutsatser som observerade, bekräftade eller fortfarande hypotetiska. Nämn bevisen som stöder den misstänkta orsaken och eventuella konkurrerande förklaringar som inte är uteslutna. Om exakt koppling är omöjlig, behåll osäkerheten istället för att rita en exakt felgräns på diagrammet.
Spara tidslinjen med källhänvisningar, frågeversion, inkluderade intervall och ägarklassificeringar. Registrera nästa verifieringsutlösare, till exempel den första fullständiga jämförbara rapportperioden efter en reparation. En återanvändbar tidslinje bör tillåta en annan analytiker att rekonstruera både fakta och gränserna för slutsatsen.
Fortsätt undersökningen
Använd genomgång av sammanlagd rapport för de underliggande fälten och guide för inriktningsdiagnos när den råa autentiseringsframgången inte uppfyller DMARC.
Håll illustrationen inom dess bevis
För det fiktiva 80-pass/20-faill-intervallet, behåll alla 20 feltider okända. 12:20-testet är en senare observation och 05:00-ankomsten är en insamlingshändelse. Ingen riktig DNS sökning eller autentiseringstest utfördes, och tidslinjen hittar inte en bevisad orsaksövergång.