En publicerad rua-förfrågan ger inte en fullständig folkräkning för varje destination. En mottagare kanske inte deltar i rapporteringen, kanske inte har relevanta observationer eller kan stöta på ett genererings- eller leveransproblem. Behandla en frånvarande reporter som en utredningsfråga, inte bevis på noll post eller noll missbruk.
Definiera den förväntade mottagarpopulationen
Börja med att skicka loggar och verifierade destinationer för intervallet som granskas. Gruppera dem efter faktisk mottagande infrastruktur där det är känt; en mottagardomän och en rapportgenererande identitet behöver inte ha en en-till-en-relation. Outsourcade e-posthosting och gateways kan göra en varumärkesbaserad reporterlista missvisande.
Registrera vad som stödjer varje förväntning: en tidigare rapport, aktuell förstapartsdokumentation, en kontrollerad leverans eller en avsändarlogg. Håll separata antaganden. Uppfinn inte en leverantörs rapporteringsschema eller förmåga från en annan leverantörs beteende.
Uteslut förfrågnings- och inkassofel
Referenser: RFC 9990 §4, RFC 9990 §3.5.
Verifiera tillämplig policy och rua-destination och krävde sedan extern auktorisering. Kontrollera mottagande postlådeloggar, karantän och parserfel. Om en rapport nådde insamlaren men inte visades, rapporterade mottagaren; gapet tillhör insamlingsprocessen.
Ett färskt kontrollerat meddelande till en samtyckande testbrevlåda kan fastställa att en speciell sökväg tog emot post. Dess betrodda autentiseringsresultat hjälper till att diagnostisera meddelandet, men de bevisar inte att en samlad rapport kommer att genereras eller anlända vid en garanterad tidpunkt.
Klassificera osäkerhet ärligt
Referenser: RFC 9990 §3.1, RFC 9989 §5.3.8.
Använd distinkta statuser som tidigare rapporterad men sen, begäran ogiltig, leverans avvisad, parser misslyckades och deltagande obekräftat. Detta förhindrar olika lag från att behandla varje saknad inlägg som samma avbrott. RFC 9990 beskriver daglig eller oftare återkoppling, men praktisk täckning beror fortfarande på faktiska deltagande system och framgångsrik insamling.
Illustrativt fall: rapporter kommer från mottagare A och B, medan avsändarloggar även visar accepterad post vid C. Ingen rapport från C finns. Utan ytterligare bevis, klassificera C som oobserverad i aggregerad rapportering. Tilldela inte en felfrekvens på noll till C och dra inte slutledning av dess policyimplementering från A:s rapporter.
Ta beslut med tillgängliga bevis
Prioritera saknad täckning för kritiska flöden, senaste infrastrukturförändringar och mottagare som tidigare bidragit tillförlitligt. Använd avsändarloggar, auktoriserade meddelandeprover och leveransdiagnostik för att komplettera rapporter. Ändra inte en giltig post upprepade gånger bara för att få en obekräftad reporter att dyka upp.
Publicera både de observerade fynden och täckningsbegränsningen. Om den frånvarande mottagaren väsentligt påverkar ett verkställighetsbeslut, skaffa bättre bevis för den vägen eller dokumentera den återstående osäkerheten och beslutsägaren. Resultatet borde vara en försvarbar beviskarta snarare än ett löfte om att varje postlådeleverantör är representerad.
Upprätthåll det förväntade reporterregistret
För varje viktig mottagare, registrera varför deltagande förväntas, det senast observerade intervallet, historiskt ankomstbeteende och aktuell beviskvalitet. Separera ett verifierat leverantörsbyte från en lokal gissning baserat på en saknad fil. Granska registret efter migrering av avsändare eller ändringar av mottagare-värd, eftersom den relevanta rapporteringsinfrastrukturen kan ändras utan att kundens e-postadress ändras. En förväntning som inte kan styrkas bör betecknas som obekräftad. Detta ger nästa analytiker en konkret utgångspunkt istället för en återkommande oförklarad varning.
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.
Den positiva kontrollen receiver.example har ett simulerat accepterat kvitto och ett analyserat antal på 100. Den andra syntetiska mottagaren, unobserved.example , har 20 tillhandahållna avsändarsändningar men inget kvitto och inget analyserat antal. Påståendet bevarar det som räknas som null snarare än noll. Den ifyllda positiva kontrollen för begäran-till-parser visar att modellens samlare kan behandla en rapport; det fastställer inte att den saknade mottagaren deltagit eller försökt leverera. En liveutredning måste skaffa sin egen brevlåda och leverantörsbevis innan den ändrar klassificeringen.
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.