En rapport kan vise en publisert avvisningspolicy uten å rapportere en avvisning. Les rapporteringsprofilen før du tolker disposisjonen: aktuell RFC 9990 definerer pass for en melding som passerer DMARC under en håndhevende policy, mens eldre rapporter ikke kan bruke noen for å sende melding. Tolk policykonteksten, autentiseringsresultatene og håndteringsbeslutningen som tydelige bevis. Forholdet deres, i stedet for et enkelt felt, forklarer hva som må undersøkes.
Les først den observerte konfigurasjonen
policy_published registrerer policykonfigurasjonen observert av mottakeren for rapportens policydomene. Det er historisk rapporteringsbevis, ikke et nytt DNS oppslag. Hvis du spør etter DNS i dag, hold resultatet og tidsstempelet atskilt. En policy kan ha endret seg under eller etter det rapporterte intervallet.
RFC 9990 tillater flere rapporter når konfigurasjoner endres i løpet av en periode; ellers bør en reporter merke seg den endelige observerte konfigurasjonen. Ett øyeblikksbilde av policy kan derfor ikke alltid forklare hver meldingstidstilstand. Ta vare på intervallet og endringshistorikken før du anklager en reporter for inkonsekvens.
Evaluer forfatterdomenet og justerte baner
En rekord's header_from leverer forfatterdomenet. Det kan avvike fra policydomenet når underdomener er avhengige av et annet domenes policy. Bestem det gjeldende policyforholdet i stedet for å anta at hver rad bruker p-verdien på toppnivå isolert.
dkim- og spf-verdiene under policy_evaluated beskriver DMARC-relatert identifikatorevaluering. De skiller seg fra råresultater under auth_results. En passerende justert bane kan tilfredsstille DMARC ; en ikke-relatert forbigående identitet kan ikke. En melding som passerer DMARC er ikke en kandidat for avvisning av retningslinjer bare fordi domenet publiserer p=reject.
Les disposisjon med overstyringsgrunner
Illustrativ gjeldende profilsak én: policy_published viser p=reject, aligned DKIM bestått og disponering er bestått, som beskrevet i RFC 9990 Appendiks A og illustrert i Appendiks B. Tilfelle to: begge justerte banene mislykkes, men disposisjonen forblir ingen med en lokalpolitisk grunn. Rapporten beskriver en mottakeroverstyring, ikke et reparert autentiseringsresultat. Ta vare på feilen og årsaken separat.
RFC 9990 krever en grunn når justering mislykkes og anvendt policy samsvarer ikke med den konfigurerte policyen. Manglende eller uventet informasjon bør merkes for etterforskning i stedet for å fylles ut med en oppfunnet forklaring. En grunnstreng er reporterens forklaring og kan fortsatt trenge bekreftelse.
Disse sakene er syntetiske. Verken disposisjon ingen eller et bestått autentiseringsresultat beviser innboksplassering. Andre filtrerings- og leveringsbeslutninger kan eksistere utenfor DMARC -håndteringen beskrevet i rapporten.
Undersøk en reell mismatch metodisk
Sammenlign rapportens periode, observerte retningslinjer, forfatterdomene, justeringsmodus og rå identifikatorer med daterte DNS endringer og kontrollerte meldingsbevis. Bekreft at avsenderen er en autorisert forretningsrute. Hvis rapporten forblir internt inkonsekvent, bevar XML-en og noter usikkerheten.
Ikke svekk en domenepolicy bare for å få et instrumentbords etiketter til å stemme overens. Rett opp en bekreftet sendingsfeil når en eksisterer; dokumenter separat mottakeroverstyringer og rapporteringsbegrensninger. Resultatet bør være en fortelling som en annen administrator kan reprodusere fra de samme feltene.
Sammenlign to eksplisitte feltarmaturer
Begge de delvise syntetiske kartene bruker gjeldende RFC 9990 rapporteringsprofil og policydomene og header_from brand.example , p=reject, relaxed alignment og epokeintervall 1704067200–1704153600 (1. januar 2024 00:0020 4. januar 2. januar 02:00 UTC). I den første, count=25, rå SPF passerer for vendor.example og DKIM passerer for brand.example /selector billing1. De beregnede justerte resultatene er SPF feil og DKIM bestått; DMARC bestått. Den medfølgende disposisjonen er bestått under gjeldende RFC 9990 rapporteringsprofil.
I den andre passerer count=4 og begge råmekanismene for vendor.example , med DKIM velger v1. Ingen av identitetene stemmer overens, så det beregnede DMARC -resultatet mislykkes. Den medfølgende disposisjonen er fortsatt ingen, ledsaget av årsakstype local_policy og den eksplisitt syntetiske kommentaren "unntak for klarert videresending." Den grunnen forklarer fiktiv håndtering uten å endre den mislykkede justeringen.
Feltsammenlikningene forklarer begge autentiseringsresultatene; det andre eksemplet gir eksplisitt en grunn. Disse delvise feltkartene er ikke komplette XML- eller levende observasjoner. Mottakerens håndteringsbeslutning er et input, ikke en konsekvens utledet fra autentisering alene.
Velg neste handling
- Justert pass pluss gjeldende profil disposisjon pass (eller eldre profil ingen): ingen DMARC avvisning er forespurt for den beståtte meldingen; undersøk levering separat om nødvendig.
- Begge justerte banene mislykkes pluss disposisjon ingen: inspiser årsaken til overstyring og bekrefter avsenderen, i stedet for å ommerke autentiseringen som bestått.
- Rapport og gjeldende DNS er uenige: sammenlign rapportintervallet med den daterte endringshistorikken.
- Nødvendig grunn mangler: bevar rapporten og flagg en uforklarlig mismatch. Ikke oppfinn et unntak for lokalpolitikk.
Skille nåværende og eldre disposisjoner
RFC 9990 vedlegg A definerer disposisjonspassering som ingen handling for å bestå DMARC med en håndhevingspolicy. Den beholder ingen da ingen tiltak er iverksatt. Eldre rapporter i RFC 7489 -format mangler passdisposisjon og kan ikke rapportere noen for en bestått melding. Sjekk navneområdet, rapporteringsprofilen og de justerte resultatene sammen: ingen er ikke universelt ugyldig, men den bør ikke stille inn for eksempelet med gjeldende profilpass. Ingen av verdiene beviser innboksplassering.