Under RFC 9989 §4.7, a DMARC politikk av p=none uttrykker ingen preferanse for håndtering av domeneeiere for DMARC feil. Når rapportering er konfigurert og gjennomgått, skaper det en mulighet til å finne ut hvilke tjenester som bruker domenet, hvor legitime meldinger mislykkes og hva en policyendring kan påvirke.
Overvåking blir nyttig gjennom etterforskning. Rapporter må nå et innsamlingssystem, kilder trenger eiere og uløste feil trenger beslutninger. Forløpt tid eller én høy bestått prosent kan ikke fastslå at alle viktige tjenester er dekket.
Gjør rapporteringsinnsamlingen observerbar
For et domene som begynner overvåket distribusjon, er en illustrativ policy:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comEksemplet forutsetter det tiltenkte _dmarc publikasjon og en fungerende samlingsadresse for samme domene. Hvis domenet allerede har en sterkere godkjent policy, ikke svekk den bare for å matche et eksempel. Bruk rekordarbeidsflyten for å bekrefte den faktiske konfigurasjonen.
Følgende RFC 9990 §4 for ekstern tillatelse og RFC 9989 §5.3.8 for mottakerrapportering, sjekk rapporteringsdestinasjonen, eventuell nødvendig ekstern destinasjonstillatelse, postlevering og parsing. Behold reporterens identitet, periode og relevant konfigurasjonshistorikk. Å motta rapporter fra én leverandør viser en arbeidsvei for den observasjonen; det beviser ikke universell dekning.
Klassifiser tjenester og bevar usikkerhet
For hvert meningsfylt kildemønster, undersøk applikasjonen, kundespesifikk konto eller rute, synlig fra domene, konvoluttidentitet, signeringsidentitet og eier.
Bruk klare arbeidskategorier:
- Kategori: Godkjent tjeneste med forventet justert bane; Neste handling: Behold eierskapet og overvåk endringer
- Kategori: Godkjent tjeneste mislykkes med autentisering eller justering; Neste handling: Korriger og test den støttede konfigurasjonen
- Kategori: Legitime indirekte rute; Neste handling: Analyser videresending, modifikasjoner og mottakerhåndtering
- Kategori: Ukjent kilde; Neste handling: Bevar usikkerhet og undersøk
- Kategori: Bekreftet uautorisert bruk; Neste handling: Registrer støttende bevis og svar
Et skyleverandørnavn, ASN eller land er ikke nok til å godkjenne en avsender. På samme måte er en mislykket rad ikke nok til å erklære alle tilknyttede meldinger som skadelige.
Eksempel: Et stille vindu går glipp av lønn
Tenk på en illustrativ organisasjon som vurderer ti dager med ansatt- og markedsføringspost. Rapportene ser sunne ut. En månedlig lønnstjeneste har ikke sendt i denne perioden, og signeringskonfigurasjonen er ikke testet.
Den riktige konklusjonen er at de observerte bekkene så friske ut i løpet av de ti dagene. Det er ikke slik at hele domenet er klart for en mer restriktiv politikk.
Teamet kan undersøke og teste lønnsruten direkte, identifisere eventuelle andre periodiske tjenester og utvide bevisene. Observasjonsvinduer bør gjenspeile de faktiske forretningssyklusene og relevante interoperabilitetshensyn, i stedet for et universelt tall valgt fra et dashbord.
Velg en policy som passer til domenet
Beslutningen er bredere enn et gjennomslagsmål. Krev dekning av kritiske tjenester, ansvarlige eiere, en evaluert populasjon av indirekte e-post, løste feil med stor innvirkning og en gjenopprettingsprosess.
RFC 9989 §7.4 advarer eksplisitt mot p=reject for generell e-post og diskuterer domener hvis brukere deltar i e-postlister på Internett. Dens interoperabilitetsveiledning inkluderer spesifikke observasjons- og sammenligningstrinn for disse domenene. Ikke erstatt den veiledningen med et generisk løfte om at hvert overvåket domene til slutt skal nå avvises.
Et tett kontrollert transaksjonssendingsdomene og et domene som brukes til generell personalkorrespondanse kan ha forskjellige driftsbegrensninger. Separate identitetsstrømmer der det tjener et reelt styringsformål, mens du verifiserer den resulterende konfigurasjonen og faktiske meldinger.
Definer bevisene for neste avgjørelse
En håndhevingsgjennomgang bør besvare disse spørsmålene med bevis:
- Er de viktige legitime tjenestene identifisert, eid og testet?
- Har hver berørte tjeneste en støttet justert bane?
- Har periodiske og lavvolumstrømmer blitt vurdert?
- Er e-postlister, videresending og andre indirekte ruter forstått?
- Er rapporteringsdekning beskrevet uten å behandle det som all e-post som sendes?
- Er unntak omfattet, eid og planlagt for gjennomgang?
- Kan teamet godkjenne, verifisere og komme seg etter den foreslåtte endringen?
Avgjørelsen kan være å forbedre en avsender, endre domeneseparasjon, fortsette overvåkingen eller bruke en policy tilpasset domenets dokumenterte bruk. Behold resonnementet med endringsprotokollen.
Tildel eiere til funnene
Spør hva teamet forventer å lære og hvem som vil handle på funnene. Hvilke tjenester sender for bedriften? Hvilke kritiske meldinger mislykkes? Hvilke tilsynelatende avsendere forblir uidentifiserte? Hvilke bevis vil avgjøre neste trinn?
Inkluder arbeid utenfor IT-teamets umiddelbare syn. En månedlig lønnsmelding eller årlig fornyelsesvarsel kan være viktig samtidig som det bidrar svært lite til den totale meldingen.
Unngå en automatisk nedtelling til en sterkere policy. En uke med få synlige feil kan bety sunn sending, ufullstendig rapportering eller en tjeneste som ikke har sendt ennå. Betal for et vedlikeholdt inventar og lukkede funn, ikke bare forløpte dager.
Fortsett overvåking etter en policyendring
Ny programvare, leverandørendringer, nøkkelrotasjon og DNS redigeringer kan skape nye hull. Fortsett å undersøke nye avsendere og legitime feil etter enhver endring i retningslinjene.
Forklar den gjenværende risikoen for bedriftsledere: Mottakere beholder sine egne håndteringsvalg under RFC 9989 §5.4, og domeneautentisering forhindrer ikke alle lookalike-meldinger, kontokompromittering eller uredelige forespørseler. For bevistolkning, bruk gjennomgangen for samlet rapport. For en raw-pass-feil, bruk justeringsguiden.
Den praktiske takeawayen
Resultatet av overvåkingen bør være en eid avsenderinventar, verifiserte kritiske ruter og en begrunnet policybeslutning. Fortsett å overvåke ettersom miljøet endres, slik at en senere endring av applikasjon, nøkkel eller gateway ikke stille åpner de samme hullene igjen.
Registrer beslutningen og dens grenser
For det fiktive ti-dagers vinduet, la den månedlige lønnen være uprøvd i stedet for å markere den som sunn. Legg til eieren, neste representant arbeidsflyt og bevis som trengs for å lukke gapet. Hvis innsamlingen fungerer, men applikasjonen aldri ble sendt, kan ikke mer analyse av de samme rapportene fastslå autentiseringen. Det ble ikke samlet inn rapporter eller lønnstester for denne illustrasjonen.