Sender logger og DMARC samlede rapporter telle ulike hendelser. En avsender kan registrere en søknadsinnsending, et mottakerforsøk eller fjerngodkjenning; en rapport grupperer mottakerobservasjoner som involverer et domene. Velg en sammenlignbar populasjon før du trekker en total fra den andre.
Skriv ned hva hver teller betyr
Referanser: RFC 9990 §3.1.1.8, RFC 9990 §3.1.
For avsender, dokumenter om tellingen representerer meldinger, mottakerleveranser, forsøk eller vellykkede SMTP transaksjoner. Etablere tidsgrunnlag og håndtering av gjenforsøk. For rapporter, bevar policydomene, header Fra domene, reporter, intervall og radantall. Sum rad teller i stedet for å telle XML-rader som meldinger.
Rapporter er ikke begrenset til å sende dine autoriserte tjenester. Forfalsket bruk av domenet og indirekte ruter kan bidra med observasjoner, mens ikke-rapporterende destinasjoner og tapte rapporter reduserer synligheten. En råforskjell er derfor ikke et mål på tapt legitim post.
Juster omfanget før du sammenligner
Referanser: RFC 9990 §3.1.2, RFC 9990 §3.5.4.
Velg samme forfatter-domeneomfang og overlappende observasjonsperiode. Separat policy-domenegruppering fra den faktiske overskriften Fra domener innenfor den. Bruk kjente destinasjonsrelasjoner der det er tilgjengelig, men ikke late som en samlet rad tilordner en individuell utgående melding.
Behold bare én opptalt kopi av kjente dupliserte rapporter. Hold uløste overlappinger adskilt og noter sene ankomster. Registrer oppbevaringshull i avsenderlogg og om kun intern trafikk er inkludert. Disse detaljene kan endre sammenligningen mer enn selve autentiseringsresultatet.
Bygg en forklaringsbro
Illustrerende eksempel: avsenderposter viser 1000 mottakerleveranser, men bare 800 av disse mottakerleveransene er målrettet mot mottakerkohorten representert i de innsamlede rapportene. Rapportene inneholder 820 observasjoner, inkludert 20 observasjoner som ikke er knyttet til de godkjente leveransene. Den naive sammenligningen antyder en mangel på 180. Den omfangsbaserte sammenligningen forklarer forskjellen som 200 uobserverte leveranser og 20 ekstra rapporterte observasjoner. Dette er syntetisk aritmetikk, ikke en påstand om at aggregerte data alene beviser hvilke 20 meldinger som var støtende.
Bruk kategorier med bevis: utenfor mottakerdekning, utenfor intervall, duplikatkvittering, mistanke om uautorisert trafikk og uforklarlig. Ikke tving en uforklarlig rest inn i forfalskning eller leveringstap bare for å balansere regnearket.
Bruk riktig bevis for det gjenværende spørsmålet
For en manglende kundemelding, undersøk leveringsposter på mottakernivå og autoriserte meldingseksempler. For en ny kilde i rapporter, undersøk eierskap og autentiseringsidentiteter. For et metrisk avvik, bevar søkedefinisjonene og råinndataene slik at en annen analytiker kan reprodusere totalsummene.
Lukk avstemmingen med matchede omfang, forklarte justeringer og en eksplisitt rest. En rest som ikke er null kan være et ærlig resultat når systemene ikke observerer den samme populasjonen.
Ta vare på avstemmingsarket
Hold én linje per justering med fortegn, enhet, bevis og tillit. Unngå å legge til tellinger på meldingsnivå til tellinger på mottakernivå, selv når begge kolonnene kalles volum. Registrer om en avsendereksport gjenspeiler endelige resultater eller et mellomliggende øyeblikksbilde, og bevar eksporttiden. Be en annen analytiker om å rekonstruere ett lite intervall manuelt før du stoler på en gjentakende spørring. Der nøyaktig kobling er utilgjengelig, oppgi den begrensningen i regnearket i stedet for å antyde at et aritmetisk samsvar viser identiske underliggende meldinger.
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
Denne lokalt gjenkjørte offline-armaturen gjør sammenligningspopulasjonen eksplisitt. Innspillet har to godkjente tjenester og levert mottakerdekningsklassifikasjoner; disse klassifiseringene er syntetiske fakta, ikke konklusjoner trukket fra kildens IP. Python summerer følgende beholdte rader og kontrollerer broen med påstander.
- Tjeneste: Fakturering; Avsender mottaker leveranser: 600; Dekket mottakerkohort: 500; Utvendig dekning: 100; Rapportert lovlig: 500; Uklassifiserte observasjoner: 10; Rapport totalt: 510; Rest: 0
- Tjeneste: Varsler; Avsender mottaker leveranser: 400; Dekket mottakerkohort: 300; Utvendig dekning: 100; Rapportert legitim: 300; Uklassifiserte observasjoner: 10; Rapport totalt: 310; Rest: 0
- Service: Totalt; Avsender mottaker leveranser: 1000; Dekket mottakerkohort: 800; Utvendig dekning: 200; Rapportert lovlig: 800; Uklassifiserte observasjoner: 20; Rapport totalt: 820; Rest: 0
Hver rest er rapport totalt minus dekkede leveranser minus uklassifiserte observasjoner. Den utførte totalen er 820 - 800 - 20 = 0. Den større broen er 1000 - 200 + 20 = 820. De 20 er merket som uklassifisert, ikke bekreftet spoofing. Denne rene syntetiske matchen beviser ikke eksakt kobling i ekte samlede data. Et produksjonsregneark trenger faktiske mottakerenhetslogger, mottakerdekningsbevis og verifiserte tjenestetilordninger. Behold eventuelle uovertrufne rester i stedet for å låne armaturets null.
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.