En plutselig økning i rapporterte DMARC feil er en grunn til å undersøke, ikke en diagnose. Det kan reflektere en ødelagt legitim avsender, et nytt etterligningsforsøk, endret mottakerdekning eller duplikatinntak. Start med å ta vare på observasjonen og finn ut hvilken av disse forklaringene bevisene støtter.
Arbeidsflyten nedenfor skiller rapportkvalitet, avsenderautorisasjon, autentisering og forretningspåvirkning. Den forutsetter ikke tilgang til meldingsinnhold eller lover at hver feil har en unik årsak som er synlig i aggregerte data.
Frys et nyttig øyeblikksbilde av hendelsen
Referanser: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Lagre rapporteringsintervall, mottakerorganisasjon, rapportidentifikator, policydomene og berørte posttellinger. Oppbevar den opprinnelige rapporten innenfor organisasjonens godkjente tilgangs- og oppbevaringskontroller. Registrer inntakstiden separat fra intervallet som er beskrevet i rapporten, siden en sen ankomst kan skape en topp på dashbordet i dag for trafikk sett tidligere.
Bekreft at rapportforsøk eller gjenbearbeiding ikke har blitt talt to ganger. Sammenlign gjeldende og tidligere vinduer med tilsvarende dekning. Registrer om varselet betyr flere mislykkede meldinger, en høyere andel, en ny kilde eller en endret disposisjon. Det er forskjellige observasjoner.
Isoler den minste betydningsfulle berørte gruppen
Referanser: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10, RFC 9990 §3.1.1.11.
Grupper etter rapportert kilde-IP, forfatterdomene, evaluert SPF og DKIM identiteter, mottaker og policykonfigurasjon der dette er tilgjengelig. Hold det samlede antallet med hver gruppe. Unngå å konvertere én rapportrad til én melding eller behandle en infrastruktureiers navn som bevis på kundeautorisasjon.
Sjekk om feilen påvirker all trafikk fra en kjent applikasjon eller bare en rute, mottaker eller tidsdel. Match resultatet med distribusjons- og DNS endringsposter. Et vanlig tidsstempel begrenser en undersøkelse, men beviser ikke årsakssammenheng.
Skille autentisering fra justering
Referanser: RFC 9989 §5.3.5, RFC 6376 §6.1.2.
Inspiser både SPF og DKIM utfall og deres justering med forfatterdomenet. Et bestått autentiseringsresultat under en tjenestes urelaterte identitet gir ikke en justert bane. Motsatt gjør en sviktende SPF -bane ikke DMARC til å mislykkes når en er justert DKIM signatur passerer.
Illustrerende sak: en fakturaapplikasjon endres til en urelatert retur-sti mens dens DKIM velger peker på en manglende nøkkel. Anta en gjeldende gyldig policy, en etablert fraværende nøkkel i stedet for et tidsavbrudd, ingen annen bestått justert signatur og fullførte SPF kontroller. Begge justerte banene er utilgjengelige i eksemplet, så de observerte feilene er plausible. Den støttede reparasjonen er å gjenopprette den tiltenkte signerings- eller konvoluttkonfigurasjonen etter verifisering, ikke å legge til vilkårlige IP-er før grafen blir grønn. Dette er et syntetisk diagnostisk scenario, ikke en direkte hendelse.
Etablere autorisasjon og innvirkning
Be den kjente applikasjonseieren bekrefte ruten og forventet volum. Bruk kontrollerte mottatte meldinger, sending av logger og kundepåvirkningsbevis når tilgjengelig. Rediger unødvendig innhold før du deler bevis. Hvis ingen kan etablere autorisasjon, behold en ukjent kildeklassifisering i stedet for å legitimere kilden gjennom DNS endringer.
Prioriter avbrutt tilbakestilling av passord, fakturaer eller viktige varsler ved å bruke faktiske konsekvensbevis. En stor strøm av tilsynelatende uautoriserte feil under håndhevelse kan trenge misbruksanalyse, mens en liten legitim feil kan kreve umiddelbar gjenoppretting av tjenesten. Hold disse arbeidsstrømmene forskjellige.
Reparer den støttede årsaken og bekreft
Gjør den minste autoriserte endringen støttet av diagnosen. En tilbakeføring av politikk for hele domenet svekker håndhevelsen for urelatert e-post og bør ikke være standardsvaret på en uforklarlig graf. Dersom et midlertidig unntak er berettiget, dokumenter omfang, godkjenner, risiko, eier og utløp.
Send en ny kontrollert melding gjennom den berørte ruten og inspiser pålitelige mottakerautentiseringsresultater. Bekreft deretter at påfølgende sammenlignbare rapporter støtter gjenoppretting, noe som gir mulighet for rapporteringsforsinkelse. Lukk med årsak, endring, bevis og gjenværende dekningsgrenser. Hvis årsaken fortsatt er usikker, si det og navngi neste test i stedet for å registrere en gjettet løsning som bevist.
Bundet konklusjonen og neste handling
For den fiktive fakturaregresjonen, skaff deg nøyaktig signeringsvelger og domene, autoritative oppslagsbevis og pålitelig mottaksresultat før du velger en reparasjon. En no-key observasjon er ikke bevis på at urelatert IP-autorisasjon fikser meldingen. Ingen DNS oppslag, hendelsesreparasjon eller e-posttest ble utført.