En autentificeringshændelse indeholder ofte flere ure: en rapports dækkede interval, rapportens ankomst, en DNS ændring, en applikationsimplementering og en kontrolleret test. At placere dem på én tidslinje er kun nyttigt, hvis hver begivenhed beholder sin oprindelige betydning. En daglig samlet rapport kan normalt ikke fortælle dig det nøjagtige minut, hvor hver inkluderet meddelelse mislykkedes.
Etabler et fælles tidsgrundlag
Referencer: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normaliser viste tidsstempler til en erklæret tidszone, mens du bevarer originale værdier og præcision. Optag urkilder og kendt usikkerhed. Skelne rapportintervallet fra ankomst- og indtagelsestidsstempler. Forsinket rapportlevering bør ikke plottes som en ny afsendelsesserie i det øjeblik, hvor den vedhæftede fil ankom.
Omfang undersøgelsen til et forfatterdomæne og verificeret tjeneste, hvor det er muligt. Hold uklassificerede kilder adskilt. Bevar reporter- og rapportidentitet, beskedantal, kildegrupper og evaluerede identiteter sammen med duplikat- og overlappende beslutninger. Disse detaljer afgør, hvilke observationer der lovligt kan sammenlignes.
Tilføj DNS bevis uden at omskrive historien
Referencer: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Registrer den godkendte ændring, påtænkt udgivelsestid, autoritative observationer og eventuelle resolverprøver, inklusive opslagstid og returneret TTL. Et aktuelt DNS svar fastslår, hvad det opslag observerede nu; det er ikke en komplet historie om, hvad hver modtager så tidligere.
DNS -cache har betydning under RFC 1034 §3.6; kvalificerende serve-forældet adfærd under RFC 8767 §4 kan udvide cachebrug ud over normal friskhed. Påstå ikke, at alle modtagere skiftede i det øjeblik, de blev offentliggjort, eller præcis én, der blev vist TTL senere. Bevar den tidligere konfiguration, ændringslog og bevisgrænser. Hvor et rapportinterval strækker sig over en politikændring, skal du markere det som blandet eller potentielt blandet i stedet for at tildele hver observation til den endelige politik.
Tilføj ansøgning og modtagerbevis
Referencer: RFC 5321 §4.2.5.
Placer applikationsimplementeringer, gatewayændringer og signeringsændringer ved siden af DNS begivenhederne. Hold kontrollerede tests som individuelle observationer med deres faktiske rute, modtager og resultat. En ansøgningslog kan vise indsendelse eller accept ved et hop; det etablerer ikke nødvendigvis endelig levering.
Brug disse bevistyper til at teste konkurrerende forklaringer. En stigning i fejl efter en DNS redigering kan også falde sammen med en ny skabelon, der ændrer signeret indhold. Korrelation indsnævrer undersøgelsen, men identificerer ikke årsagen uden yderligere beviser.
Arbejd gennem en afgrænset tidslinje
Illustrerende case: en rapport dækker 00:00 til 24:00 UTC. En politikændring registreres kl. 12:00, og en kontrolleret test kl. 12:20 passerer justeret DKIM. Rapporten indeholder 80 beståede og 20 svigtende observationer, der ankommer næste morgen kl. 05:00.
Du kan angive intervaltotaler og den vellykkede test kl. 12:20. Du kan ikke tildele alle 20 fejl til før middag, blot fordi testen bestod senere. Den næste handling er at opnå smallere modtager- eller ansøgningsbeviser eller køre yderligere repræsentative tests. Ankomsten kl. 05:00 er en indsamlingsbegivenhed, ikke tidspunktet for de 20 fejl.
Afslut med en årsagserklæring om den rigtige styrke
Mærk konklusioner som observerede, bekræftede eller stadig hypotetiske. Nævn de beviser, der understøtter den formodede årsag, og enhver konkurrerende forklaring, der ikke er udelukket. Hvis nøjagtig kobling er umulig, skal du bevare usikkerheden i stedet for at tegne en præcis fejlgrænse på kortet.
Gem tidslinjen med kildehenvisninger, forespørgselsrevision, inkluderede intervaller og ejerskabsklassifikationer. Registrer den næste verifikationstrigger, såsom den første komplette sammenlignelige rapporteringsperiode efter en reparation. En genanvendelig tidslinje bør give en anden analytiker mulighed for at rekonstruere både fakta og grænserne for konklusionen.
Fortsæt undersøgelsen
Brug gennemgang af samlet rapport for de underliggende felter og alignment diagnose guide når rå autentificeringssucces ikke tilfredsstiller DMARC.
Hold illustrationen inden for dens beviser
For det fiktive 80-pass/20-fail-interval skal du holde alle 20 fejltider ukendte. 12:20-testen er en senere observation, og ankomsten kl. 05:00 er en indsamlingsbegivenhed. Der blev ikke udført et rigtigt DNS opslag eller en godkendelsestest, og tidslinjen finder ikke en bevist kausal cutover.