Publisering p=reject er en politisk milepæl, ikke slutten på DMARC operasjoner. Sendetjenester endres, nye søknader dukker opp og mottakere beholder sine egne håndteringsvedtak. Samlet rapportering hjelper fortsatt med å identifisere autentiseringsregresjoner, nylig observerte kilder og forskjeller mellom den forespurte policyen og rapportert behandling.
Fortsett å konfigurere og overvåke rapporteringen etter policyendringen. Egnethet avhenger fortsatt av domenebruk: RFC 9989 §7.4 advarer mot avvisning for domener hvis brukere kan poste til Internett-e-postlister og krever at avvisningsdomener skal bruke gyldige DKIM heller enn å stole utelukkende på SPF. Bevisene forblir begrenset av deltakende mottakere og deres observasjoner. En avvisningspolicy er ikke et bevis på at hvert forsøk på etterligning ble blokkert eller at alle legitime meldinger ble levert.
Les policy, evaluering og disposisjon separat
Referanser: RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
De publiserte retningslinjene uttrykker domeneeierens forespurte behandling for e-post som ikke oppfyller DMARC . Evaluering spør om en autentisert SPF eller DKIM identifikator stemmer overens med forfatterdomenet. Rapportert disposisjon beskriver mottakerens rapporterte DMARC-relaterte behandling, med overstyringsinformasjon der den er oppgitt.
Disse feltene skal ikke skjules til én status. En rekord som viser p=reject ved siden av disposisjon ingen er ikke automatisk feilformet: en melding kan ha gått, eller mottakerhåndtering kan ha forskjellig fra den forespurte handlingen. Undersøk de samordnede resultatene og tilgjengelige årsaker i stedet for å gjette fra policyen alene. RFC 9989 bevarer mottakerens skjønn, og RFC 9990 definerer de samlede feltene.
Se etter lovlige ruteregresjoner
Referanser: RFC 9989 §5.3.5.
Hold en vedlikeholdt oversikt over applikasjoner og eiere. Sammenlign nåværende observasjoner med deres forventede identiteter, og undersøk en endret velger, retur-sti eller forfatterdomene før brukere rapporterer manglende e-post. Inkluder lavvolum og sesongbaserte ruter som kan forbli usynlige i lange perioder.
Illustrerende eksempel: en tidligere bekreftet faktureringsapplikasjon flytter til en ny plattform og mister sin justering DKIM signatur. SPF går fortsatt under et ikke-relatert tjenestedomene. Anta en gjeldende gyldig policy og fullførte kontroller. Uten en annen justert passeringsbane, mislykkes meldingen DMARC i dette syntetiske eksemplet. Det nyttige svaret er å reparere den støttede avsenderidentiteten, ikke å anta at håndhevelse har gjort fremtidig onboarding unødvendig.
Tolk vedvarende uautoriserte feil
Uautoriserte avsendere kan fortsette å bruke domenet i From selv etter håndhevelse. Rapporter kan vise observert mislykket autentisering og mottakerbehandling for den trafikken. Vedvarende feilvolum beviser ikke alene at håndhevelse er ineffektiv; en kontroll kan avvise trafikk som fortsetter å ankomme.
Omvendt, ikke tell hver feil som et bekreftet forhindret angrep. Attribusjon, hensikt, mottakerdekning og faktisk håndtering trenger bevis. En rapporttelling er en observasjonstelling, og rapportert disposisjon er ikke en fullstendig nedstrømsleveranserevisjon.
Avstemme unntak og manglende dekning
Referanser: RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
Gå gjennom poster der mislykkede e-poster ble behandlet annerledes enn de forespurte retningslinjene. Undersøk oppgitte overstyringsårsaker og relevant videresending eller mellomledd atferd. Ikke anta at hver mottaker bruker samme lokale retningslinjer eller at hvert unntak har nok forklaring i en samlet rapport.
Sjekk selve rapporteringspipelinen: destinasjonseierskap, ekstern autorisasjon der det er nødvendig, inntaksfeil og endringer i bidragende mottakere. Et stille dashbord etter håndheving kan gjenspeile et innkrevingsproblem. Hold en kontrollert test for kritiske ruter og sammenlign mottakerbevis med applikasjonslogger når du undersøker levering.
Oppretthold en driftsrytme etter håndheving
Tildel ansvar for onboarding av nye avsendere, periodisk inventargjennomgang, DNS endringer og rapporttriage. Bruk en godkjennings- og utløpsprosess for enhver midlertidig politikkavslapning. Bekreft at den foreslåtte endringen adresserer en støttet årsak og ikke unødvendig påvirker ikke-relaterte avsendere.
Lukk hver anmeldelse med de legitime rutene som er testet, ukjente kilder undersøkt, mottakeravvik undersøkt og rapporteringshull som fortsatt er tilstede. Målet etter p=reject opprettholdes, forklarbar autentiseringsdekning. Policystrengen alene kan ikke gi den forsikringen.
Bundet konklusjonen og neste handling
For den fiktive plattformflyttingen, behold rå SPF pass under den ikke-relaterte tjenesteidentiteten atskilt fra manglende justert DKIM . En senere støttet signeringsreparasjon må testes på den berørte ruten. En rapportert ingen-disponering forblir håndtering av bevis, ikke bevis på at autentisering gjenopprettet eller en innboks mottok meldingen.