Een gepubliceerd rua-verzoek levert geen volledige telling van elke bestemming op. Het kan zijn dat een ontvanger niet meewerkt aan de berichtgeving, geen relevante observaties heeft of een generatie- of leveringsprobleem tegenkomt. Behandel een afwezige verslaggever als een onderzoeksvraag, niet als bewijs van nulmail of nulmisbruik.
Definieer de verwachte ontvangerpopulatie
Begin met het verzenden van logboeken en geverifieerde bestemmingen voor het beoordeelde interval. Groepeer ze op feitelijke ontvangstinfrastructuur, voor zover dat bekend is; een ontvangend domein en een rapportgeneratoridentiteit hoeven geen één-op-één-relatie te hebben. Uitbestede mailhosting en gateways kunnen een op merken gebaseerde reporterlijst misleidend maken.
Leg vast wat elke verwachting ondersteunt: een eerder rapport, actuele documentatie van de eerste partij, een gecontroleerde bezorging of een afzenderlogboek. Houd aannames gescheiden. Verzin het rapportageschema of de mogelijkheden van een aanbieder niet op basis van het gedrag van een andere aanbieder.
Sluit aanvraag- en incassofouten uit
Referenties: RFC 9990 §4, RFC 9990 §3.5.
Verifieer het toepasselijke beleid en de rua-bestemming en vereiste vervolgens externe autorisatie. Controleer ontvangen mailboxlogboeken, quarantaine- en parserfouten. Als een melding de ophaler bereikte maar niet werd getoond, deed de ontvanger wel melding; de kloof behoort tot het incassoproces.
Een nieuw gecontroleerd bericht naar een instemmende testmailbox kan vaststellen dat een bepaald pad e-mail heeft ontvangen. De vertrouwde authenticatieresultaten helpen bij het diagnosticeren van het bericht, maar ze bewijzen niet dat een samengesteld rapport wordt gegenereerd of arriveert op een gegarandeerd tijdstip.
Classificeer onzekerheid eerlijk
Referenties: RFC 9990 §3.1, RFC 9989 §5.3.8.
Gebruik verschillende statussen, zoals eerder gerapporteerd maar te laat, verzoek ongeldig, levering afgewezen, parser mislukt en deelname niet bevestigd. Dit voorkomt dat verschillende teams elke ontbrekende invoer als dezelfde storing beschouwen. RFC 9990 beschrijft dagelijkse of frequentere feedback, maar de praktische dekking hangt nog steeds af van daadwerkelijk deelnemende systemen en succesvolle verzameling.
Illustratief geval: rapporten komen binnen van ontvangers A en B, terwijl afzenderlogboeken ook geaccepteerde mail bij C tonen. Er is geen rapport van C aanwezig. Zonder verder bewijs classificeert u C als niet-waargenomen in de totale rapportage. Wijs geen mislukkingspercentage van nul toe aan C en leid de beleidsimplementatie ervan niet af uit de rapporten van A.
Neem beslissingen op basis van het beschikbare bewijsmateriaal
Geef prioriteit aan ontbrekende dekking voor kritieke stromen, recente veranderingen in de infrastructuur en ontvangers die voorheen betrouwbaar hebben bijgedragen. Gebruik afzenderlogboeken, geautoriseerde berichtvoorbeelden en leveringsdiagnostiek als aanvulling op rapporten. Wijzig een geldig record niet herhaaldelijk alleen maar om een onbevestigde verslaggever te laten verschijnen.
Publiceer zowel de waargenomen bevindingen als de dekkingsbeperking. Als de afwezige ontvanger een materiële invloed heeft op een tenuitvoerleggingsbeslissing, zorg dan voor beter bewijsmateriaal voor die route of documenteer de resterende onzekerheid en beslissingseigenaar. Het resultaat zou een verdedigbare bewijskaart moeten zijn in plaats van een belofte dat elke mailboxprovider vertegenwoordigd is.
Houd het register van verwachte melders bij
Leg voor elke belangrijke ontvanger vast waarom deelname wordt verwacht, het laatste waargenomen interval, het historische aankomstgedrag en de huidige kwaliteit van het bewijsmateriaal. Scheid een geverifieerde providerwijziging van een lokale schatting op basis van een ontbrekend bestand. Controleer het register na migratie van afzenders of wijzigingen in de hosting van ontvangers, omdat de relevante rapportage-infrastructuur kan veranderen zonder dat het e-mailadres van de klant wordt gewijzigd. Een verwachting die niet kan worden waargemaakt, moet als onbevestigd worden bestempeld. Dit geeft de volgende analist een concreet startpunt in plaats van een terugkerende onverklaarbare waarschuwing.
Ga door met het onderzoek
Gebruik de overzicht van totaalrapporten om de onderliggende velden en de te interpreteren diagnosegids voor uitlijning wanneer een onbewerkte authenticatiepas niet voldoet DMARC.
Synthetisch bewijsmateriaal uitgevoerd
Het volgende is een lokaal herhaald offline synthetisch armatuur, geen live DNS , SMTP of klantobservatie. De XML-invoer werd geparseerd met de standaardbibliotheek van Python, en beweringen controleerden de resulterende velden en berekeningen. De gesimuleerde DNS en mailfasen worden geleverd met testinvoer, geen bewijs dat een echte ontvanger deze bewerkingen heeft uitgevoerd. Volledige schemavalidatie en productiebronauthenticatie vallen buiten dit kleine plaatje; levend bewijs blijft hangende.
Het opgegeven verzoek is _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Er wordt aangenomen dat deze gereserveerde voorbeelddomeinen in het armatuur afzonderlijke organisatiedomeinen zijn. De twee synthetische autorisatie-antwoorden zijn brand.example._report._dmarc.collector.example TXT "v=DMARC1" En brand.example._report._dmarc.archive.example TXT "v=DMARC1". Het lokale model komt overeen met de opgegeven namen van autorisatie-eigenaren en hun versiewaarden eronder RFC 9990 §4. Het voert geen DNS query's of het volledige autorisatie-algoritme uit. Een productie-implementatie moet de volledige detectie- en autorisatieprocedure uitvoeren in plaats van deze domeingrenzen aan te nemen.
Het bewaarde rapport heeft ID R1, beleidsdomein brand.example , date_range begin 1772409600 en eind 1772496000, bron-IP 192.0.2.10 en telling 100. De evaluatie is uitgelijnd DKIM resultaat is geslaagd en uitgelijnd SPF is mislukt. Het onbewerkte SPF resultaat is voldoende voor vendor.example , wat illustreert waarom onbewerkt succes niet gelijk staat aan succes. Deze velden worden geparseerd uit XML in plaats van afgeleid uit een dashboard.
De receiver.example positieve controle.voorbeeld heeft een gesimuleerde geaccepteerde ontvangst en een ontleed aantal van 100. De tweede synthetische ontvanger, unobserved.example , heeft 20 aangeleverde afzenderinzendingen, maar geen ontvangstbewijs en geen ontleed aantal. De bewering behoudt dat dit als nul telt in plaats van als nul. Uit de voltooide positieve controle van de request-to-parser blijkt dat de verzamelaar van het model één rapport kan verwerken; er wordt niet aangetoond dat de vermiste ontvanger heeft deelgenomen of een poging heeft gedaan tot bezorging. Een live onderzoek moet zijn eigen mailbox en bewijsmateriaal van de provider verkrijgen voordat deze classificatie wordt gewijzigd.
Houd het resultaat binnen het geteste bereik
De meegeleverde lokale demonstratie verifieert alleen de kleine synthetische parser, de meegeleverde podiuminvoer en berekeningen. Er werd geen echte DNS autorisatie, SMTP levering, verzamelaarmigratie, providerdeelname of productiedatabasegedrag getest. Originele input blijft gearchiveerd en elke live vergelijking heeft zijn eigen beschermde bewijsmateriaal en verantwoordelijke goedkeuring nodig.