Samlet rapportering er retrospektive bevis. Et dashbord kan være aktuelt som et innsamlingssystem mens de nyeste observasjonene fortsatt beskriver gårsdagens post. Spor klokkene separat slik at en forsinket rapport ikke forveksles med en gjeldende sendingsfeil, og en gjeldende feil ikke skjules bak gamle sunne data.
Behold tre tidsstempler
Referanser: RFC 9990 §3.1.1.4, RFC 9990 §3.1.
Ta vare på rapportens start- og slutttidsstempler, mottakssystemets ankomsttidsstempel og innsamlerens behandlingstidsstempel. Tolk rapportintervallet i UTC og vis enhver konvertering av visningstidssone eksplisitt. Filendringstid er ikke en erstatning for observasjonsvinduet.
RFC 9990 beskriver periodisk samlet tilbakemelding og inkluderer den dekkede datoperioden i rapportens metadata. Det skaper ikke en universell sanntidsovervåkingstjeneste. En rapport som kommer for sent kan fortsatt være nyttig bevis for det opprinnelige intervallet.
Mål forsinkelse av reporter
For operasjonell overvåking, beregn mottaksforsinkelse fra rapportslutt til ankomst og behandlingsforsinkelse fra ankomst til vellykket import. Hold separate distribusjoner etter reporter og innsamlingsbane. Dette er lokale driftsmålinger, ikke protokollgarantier. Definer varslingsterskler fra observert atferd og forretningsbeslutningen som krever tidsriktige data.
Overvåk også inntaksfeil og det nyeste dekkede intervallet. En jevn strøm av dupliserte eller gamle filer bør ikke gjøre friskhetsvisningen grønn. Merk foreløpige rapporteringsvinduer til den dokumenterte prosessen med sen ankomst lukker dem.
Skille et strømbrudd ved å bruke gjeldende bevis
Når brukere rapporterer manglende tilbakestilling av passord, inspiser gjeldende sendekøer, SMTP svar og kontrollerte mottatte meldinger. Ikke vent til morgendagens rapport for å begynne feilsøkingen. Omvendt, hvis nåværende tester lykkes, men aggregerte data er gamle, undersøk rapporteringsbanen uten å erklære sendetjenesten nede.
Illustrerende tidslinje: en rapport dekker mandag 00:00–24:00 UTC, ankommer tirsdag kl. 05:00 og importeres kl. 08:00. Kvitteringsforsinkelsen er fem timer; behandlingsforsinkelsen er tre timer. Ingen av tallene måler hvor lang tid det tok før en individuell mandagsmelding kom. Disse syntetiske verdiene illustrerer regnskapsmetoden, ikke et anbefalt tjenestemål.
Håndter sene ankomster uten å omskrive historien stille
Referanser: RFC 9990 §3.5.4.
Behold et tidsstempel for eksporterte beregninger og versjoner eventuelle reviderte totaler. Reprosessering bør være idempotent, slik at et nytt forsøk ikke teller de samme observasjonene igjen. Behold originale intervaller i stedet for å legge inn alle sene filer på ankomstdagen.
Eskaler en savnet forventet reporter, en voksende behandlingskø og en direkte avsenderfeil som forskjellige hendelser. Lukk hver med relevante bevis. Rapportens oppdatering er meningsfull bare når den navngir hvilken populasjon og intervall som faktisk er tilgjengelig.
Publiser et handlingsverdig friskhetspanel
Vis det siste dekkede intervallet, ankomsttid og importtid for hver viktige reporter, pluss størrelsen og eldste alder på behandlingsetterslepet. Ta med den siste oppdateringen av selve overvåkingssystemet. Et frossent dashbord skal ikke virke sunt fordi dets siste lagrede status var grønn. Tildel separate eiere for kvitteringsfeil og behandlingsfeil. Før du bruker en varslingsterskel, dokumenter observasjonsperioden som basislinjen ble utledet fra og hvilken handling et varsel skal utløse. Se den på nytt etter samlermigrasjoner.
Fortsett etterforskningen
Bruk gjennomgang av samlet rapport å tolke de underliggende feltene og alignment diagnose guide når et rågodkjenningspass ikke tilfredsstiller DMARC.
Henrettet syntetisk bevis
Følgende er en lokalt rekjørt, offline syntetisk armatur, ikke en live DNS , SMTP eller kundeobservasjon. XML-inndataene ble analysert med Pythons standardbibliotek, og påstander sjekket de resulterende feltene og beregningene. De simulerte DNS og e-poststadiene er levert testinnganger, ikke bevis på at en ekte mottaker utførte disse operasjonene. Fullstendig skjemavalidering og produksjonskildeautentisering er utenfor denne lille armaturen; levende bevis gjenstår.
Den oppgitte forespørselen er _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Disse reserverte eksempeldomenene antas å være separate organisasjonsdomener i armaturet. De to syntetiske autorisasjonssvarene er brand.example._report._dmarc.collector.example TXT "v=DMARC1" og brand.example._report._dmarc.archive.example TXT "v=DMARC1". Den lokale modellen samsvarer med både oppgitte autorisasjonseiernavn og deres versjonsverdier under RFC 9990 §4. Den utfører ikke DNS spørringer eller den komplette autorisasjonsalgoritmen. En produksjonsimplementering må utføre den fullstendige oppdagelses- og autorisasjonsprosedyren i stedet for å anta disse domenegrensene.
Den beholdte rapporten har ID R1, policydomene brand.example , date_range start 1772409600 and end 1772496000, source IP 192.0.2.10 og count 100. Dens evaluert justert DKIM resultatet er bestått og justert SPF er mislykkes. Det rå SPF resultatet er pass for vendor.example , som illustrerer hvorfor råsuksess ikke er justert suksess. Disse feltene analyseres fra XML i stedet for å utledes fra et dashbord.
Armaturet setter ankomst til å rapportere slutt pluss 18 000 sekunder og fullført import til å rapportere slutt pluss 28 800 sekunder. Utført subtraksjon gir fem timers mottaksforsinkelse og tre timers behandlingsforsinkelse. Både destinasjoner og tillatelsesinndata forblir de samme, så beregningen kan følges fra publisert forespørsel gjennom analysert intervall og samletidsstempler. Disse verdiene er testinndata, ikke målt latens eller en SLA. RFC 9990 §3.1.1.4 leverer semantikk for UTC-datointervall; forsinkelsesformlene er denne arbeidsflytens operasjonelle definisjoner.
Hold resultatet innenfor det testede omfanget
Den medfølgende lokale demonstrasjonen verifiserer kun den lille syntetiske parseren, medfølgende sceneinnganger og beregninger. Ingen reell DNS autorisasjon, SMTP levering, samlermigrering, leverandørdeltakelse eller produksjonsdatabaseatferd ble testet. Originale inndata forblir arkivert, og enhver direkte sammenligning trenger sine egne beskyttede bevis og ansvarlig godkjenning.