Sammanlagd rapportering är retrospektiva bevis. En instrumentpanel kan vara aktuell som ett insamlingssystem medan dess senaste observationer fortfarande beskriver gårdagens post. Spåra klockorna separat så att en fördröjd rapport inte misstas för ett aktuellt sändningsfel, och ett aktuellt fel inte döljs bakom gamla hälsosamma data.
Behåll tre tidsstämplar
Referenser: RFC 9990 §3.1.1.4, RFC 9990 §3.1.
Bevara rapportens start- och sluttidsstämplar, det mottagande systemets ankomsttidsstämpel och insamlarens bearbetningstidsstämpel. Tolka rapportintervallet i UTC och visa alla visnings-tidszonsomvandlingar explicit. Filändringstid är inte en ersättning för observationsfönstret.
RFC 9990 beskriver periodisk samlad feedback och inkluderar det täckta datumintervallet i rapportens metadata. Det skapar inte en universell övervakningstjänst i realtid. En rapport som kommer sent kan fortfarande vara ett användbart bevis för dess ursprungliga intervall.
Mät försening av reportern
För driftövervakning, beräkna mottagningsfördröjning från rapportens slut till ankomst och bearbetningsfördröjning från ankomst till framgångsrik import. Håll separata distributioner efter reporter och insamlingsväg. Dessa är lokala driftsmått, inte protokollgarantier. Definiera varningströsklar från observerat beteende och affärsbeslut som kräver snabba data.
Övervaka även intagsfel och det senaste täckta intervallet. Ett jämnt flöde av dubbletter eller gamla filer bör inte göra visningen av färskhet grön. Markera provisoriska rapporteringsfönster tills din dokumenterade sena ankomstprocess stänger dem.
Särskilj ett avbrott med aktuella bevis
När användare rapporterar saknade lösenordsåterställningar, inspektera aktuella sändningsköer, SMTP svar och kontrollerade mottagna meddelanden. Vänta inte på morgondagens rapport för att börja felsökningen. Omvänt, om nuvarande tester lyckas men aggregerad data är gammal, undersök rapporteringsvägen utan att förklara den sändande tjänsten nere.
Belysande tidslinje: en rapport täcker måndag 00:00–24:00 UTC, anländer tisdag kl. 05:00 och importeras kl. 08:00. Kvittofördröjningen är fem timmar; bearbetningsfördröjningen är tre timmar. Inget av siffrorna mäter hur lång tid ett enskilt måndagsmeddelande tog att komma fram. Dessa syntetiska värden illustrerar redovisningsmetoden, inte ett rekommenderat servicemål.
Hantera sena ankomster utan att skriva om historien tyst
Referenser: RFC 9990 §3.5.4.
Behåll en tidsstämpel för exporterade mätvärden och version av eventuella reviderade totaler. Återupparbetning bör vara idempotent så ett nytt försök räknar inte samma observationer igen. Behåll ursprungliga intervall istället för att placera alla sena filer på ankomstdagen.
Eskalera en saknad förväntad reporter, en växande bearbetningskö och ett liveavsändarfel som olika incidenter. Stäng var och en med relevant bevis. Rapportens färskhet är meningsfull endast när den namnger vilken population och intervall som faktiskt är tillgängliga.
Publicera en handlingsbar fräschörspanel
Visa det senaste täckta intervallet, ankomsttid och importtid för varje viktig reporter, plus storleken och den äldsta åldern på eftersläpningen. Inkludera den sista uppdateringen av själva övervakningssystemet. En frusen instrumentpanel bör inte se frisk ut eftersom dess senaste lagrade status var grön. Tilldela separata ägare för kvittofel och bearbetningsfel. Innan du använder en varningströskel, dokumentera observationsperioden från vilken dess baslinje härleddes och vilken åtgärd en varning ska utlösa. Besök det igen efter samlarmigreringar.
Fortsätt undersökningen
Använd genomgång av sammanlagd rapport att tolka de underliggande fälten och guide för inriktningsdiagnos när ett obearbetat autentiseringspass inte uppfyller DMARC.
Avrättade syntetiska bevis
Följande är en lokalt återkörd offline syntetisk fixtur, inte en live DNS , SMTP eller kundobservation. Dess XML-indata analyserades med Pythons standardbibliotek, och påståenden kontrollerade de resulterande fälten och beräkningarna. De simulerade DNS och e-poststegen är levererade testingångar, inte bevis på att en riktig mottagare utförde dessa operationer. Fullständig schemavalidering och produktionskälla-autentisering är utanför denna lilla fixtur; levande bevis kvarstår.
Den angivna begäran är _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Dessa reserverade exempeldomäner antas vara separata organisatoriska domäner i fixturen. De två syntetiska auktorisationssvaren är brand.example._report._dmarc.collector.example TXT "v=DMARC1" och brand.example._report._dmarc.archive.example TXT "v=DMARC1". Den lokala modellen matchar både de angivna auktoriseringsägarnas namn och deras versionsvärden under RFC 9990 §4. Den exekverar inte DNS frågor eller hela auktoriseringsalgoritmen. En produktionsimplementering måste utföra hela upptäckten och auktoriseringsproceduren snarare än att anta dessa domängränser.
Den bevarade rapporten har ID R1, policydomän brand.example , date_range begin 1772409600 and end 1772496000, source IP 192.0.2.10 och count 100. Dess utvärderade justerade DKIM resultatet är godkänt och justerat SPF är misslyckad. Det råa SPF resultatet är godkänt för vendor.example , vilket illustrerar varför råframgång inte är anpassad framgång. Dessa fält tolkas från XML snarare än härledda från en instrumentpanel.
Fixturen anger ankomst för att rapportera slut plus 18 000 sekunder och slutförd import för att rapportera slut plus 28 800 sekunder. Utförd subtraktion ger fem timmars mottagningsfördröjning och tre timmars bearbetningsfördröjning. Både destinationer och behörighetsinmatningar förblir desamma, så beräkningen kan följas från publicerad begäran genom tolkat intervall och samlartidsstämplar. Dessa värden är testingångar, inte uppmätt latens eller en SLA. RFC 9990 §3.1.1.4 tillhandahåller semantik för UTC-datumintervall; fördröjningsformlerna är detta arbetsflödes operativa definitioner.
Håll resultatet inom det testade omfånget
Den medföljande lokala demonstrationen verifierar endast dess lilla syntetiska parser, medföljande stegingångar och beräkningar. Ingen riktig DNS auktorisering, SMTP leverans, samlarmigrering, leverantörsdeltagande eller produktionsdatabasbeteende testades. Ursprungliga indata förblir arkiverade och alla livejämförelser behöver sina egna skyddade bevis och ansvarsfullt godkännande.