En autentiseringshendelse inneholder ofte flere klokker: en rapports dekkede intervall, rapportens ankomst, en DNS endring, en applikasjonsdistribusjon og en kontrollert test. Å sette dem på én tidslinje er bare nyttig hvis hver hendelse beholder sin opprinnelige betydning. En daglig samlet rapport kan vanligvis ikke fortelle deg det nøyaktige minuttet når hver inkluderte melding mislyktes.
Etabler et felles tidsgrunnlag
Referanser: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normaliser viste tidsstempler til en deklarert tidssone mens du beholder opprinnelige verdier og presisjon. Registrer klokkekilder og kjent usikkerhet. Skille rapportintervallet fra tidsstempler for ankomst og inntak. Sen rapportlevering skal ikke plottes inn som en ny sending i det øyeblikket vedlegget kom.
Omfang undersøkelsen til et forfatterdomene og verifisert tjeneste der det er mulig. Hold uklassifiserte kilder atskilt. Bevar reporter- og rapportidentitet, meldingstall, kildegrupper og evaluerte identiteter, sammen med dupliserte og overlappende beslutninger. Disse detaljene avgjør hvilke observasjoner som legitimt kan sammenlignes.
Legg til DNS bevis uten å omskrive historien
Referanser: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Registrer den godkjente endringen, tiltenkt publiseringstidspunkt, autoritative observasjoner og eventuelle resolverprøver, inkludert oppslagstid og returnert TTL. Et nåværende DNS svar fastslår hva oppslaget observerte nå; det er ikke en fullstendig historie om hva hver mottaker så tidligere.
DNS bufring er viktig under RFC 1034 §3.6; kvalifiserende serve-foreldet oppførsel under RFC 8767 §4 kan utvide cache-bruken utover normal friskhet. Ikke påstå at alle mottakere byttet ved publiseringsøyeblikket eller nøyaktig en som ble vist TTL senere. Ta vare på tidligere konfigurasjon, endringslogg og bevisgrenser. Der et rapportintervall spenner over en policyendring, merk det som blandet eller potensielt blandet i stedet for å tilordne hver observasjon til den endelige policyen.
Legg til søknad og mottakerbevis
Referanser: RFC 5321 §4.2.5.
Plasser applikasjonsimplementeringer, gatewayendringer og signeringsendringer ved siden av DNS hendelsene. Hold kontrollerte tester som individuelle observasjoner med deres faktiske rute, mottaker og resultat. En søknadslogg kan vise innsending eller aksept på et hop; det etablerer ikke nødvendigvis endelig levering.
Bruk disse bevistypene for å teste konkurrerende forklaringer. En feiløkning etter en DNS redigering kan også falle sammen med en ny mal som endrer signert innhold. Korrelasjon begrenser etterforskningen, men identifiserer ikke årsaken uten ytterligere bevis.
Arbeid gjennom en avgrenset tidslinje
Illustrerende case: en rapport dekker 00:00 til 24:00 UTC. En policyendring registreres kl. 12.00, og en kontrollert test kl. 12.20 passerer. DKIM. Rapporten inneholder 80 beståtte og 20 sviktende observasjoner, som ankommer neste morgen klokken 05:00.
Du kan oppgi intervalltotalene og den vellykkede testen klokken 12:20. Du kan ikke tilordne alle de 20 feilene til før kl. 12.00 bare fordi testen bestod senere. Neste handling er å skaffe smalere mottaker- eller søknadsbevis, eller kjøre ytterligere representative tester. Ankomst kl. 05.00 er en innsamlingshendelse, ikke tidspunktet for de 20 feilene.
Avslutt med en årsakserklæring om rett styrke
Merk konklusjonene som observert, bekreftet eller fortsatt hypotetiske. Nevn bevisene som støtter den mistenkte årsaken og enhver konkurrerende forklaring som ikke er utelukket. Hvis nøyaktig kobling er umulig, behold usikkerheten i stedet for å tegne en presis feilgrense på kartet.
Lagre tidslinjen med kildereferanser, spørringsrevisjoner, inkluderte intervaller og eierskapsklassifiseringer. Registrer neste bekreftelsesutløser, for eksempel den første komplette sammenlignbare rapporteringsperioden etter en reparasjon. En gjenbrukbar tidslinje bør tillate en annen analytiker å rekonstruere både fakta og grensene for konklusjonen.
Fortsett etterforskningen
Bruk gjennomgang av samlet rapport for de underliggende feltene og alignment diagnose guide når rå autentiseringssuksess ikke tilfredsstiller DMARC.
Hold illustrasjonen innenfor bevisene
For det fiktive 80-pass/20-fail-intervallet, hold alle 20 feiltider ukjente. 12:20-testen er en senere observasjon og 05:00-ankomsten er en samlingshendelse. Ingen reell DNS oppslag eller autentiseringstest ble utført, og tidslinjen finner ikke en bevist årsaksovergang.