At flytte til en håndhævelsespolitik er en vigtig domænekontrolbeslutning, ikke enden på e-mailsvindel. Rapportér den opnåede grænse præcist: Domænet anmoder om stærkere behandling af beskeder, der fejler DMARC. Forklar derefter de trusler, der stadig kan autentificere eller falde uden for denne identitetsgrænse, sammen med det operationelle arbejde, der er nødvendigt for at holde legitim post i funktion.
Angiv beskyttelsen uden garanti
DMARC kombinerer tilpasset domænegodkendelse med en offentliggjort håndteringspræference og rapporteringsramme. Modtagerens faktiske håndtering kan involvere lokal politik. Lov ikke, at enhver mislykket besked bliver afvist overalt, eller at en beståelse betyder, at beskeden er sikker. RFC 9989.
Meddelelser på et lookalike-domæne, efterligning af vist navn og kompromitterede legitime afsendere kan forblive farlige efter håndhævelse. En godkendt leverandør kan stadig sende en uautoriseret betalingsanmodning. SPF autorisation, der er bredere end tilsigtet, kan også efterlade en tilpasset gennemkørselsrute tilgængelig. Dette er grunde til at opretholde supplerende kontroller, ikke grunde til at opgive domænegodkendelse.
Tjek legitime ruter før ændringen
Oprethold en afsender-for-afsender-matrix med tjenesten, ansvarlig ejer, forfatterdomæne, godkendte domæner, justering beviser, kritiske modtagere og sidste testdato. Medtag lavvolumensystemer såsom scannere og advarsler. En stille rute er ikke nødvendigvis ubrugt. Løs ukendte afsendere, før du behandler beholdningen som komplet.
Dokumenter den foreslåede politikforskel, og hvem der godkender den. En ændring fra p=none til p=reject er et eksempel, ikke en værdi at udgive blindt. Gennemgå de relevante domæner og afhængigheder, planlæg observationsvinduet og definer gendannelsestriggere for vigtige legitime fejl. Brug genererede tjenestespecifikke værdier i stedet for denne artikels demonstrationsidentiteter.
Undersøg en skriftlig beredskabsbog
For den foreslåede p=none til p=reject ændring nedenfor, antage en enkelt gyldig synlig Fra pr. besked og fastsatte modtagergodkendelsesbevis. Der udføres ingen egentlig ændring eller modtagertest.
- Fakturering: foreslået ejer Billing Operations; Fra invoice@billing.brand.test ; SPF -pas for bounce@billing.brand.test ; DKIM bestå med d=billing.brand.test. Begge identifikatorer justeres nøjagtigt, så den hypotetiske meddelelse passerer. Reelle kritiske modtagertests og ændringsgodkendelse er fortsat ikke leveret.
- Support: foreslået ejer Support Operations; Fra agent@support.brand.test ; SPF -pas for bounce@support.brand.test ; DKIM pass med d=support.brand.test. Begge stemmer nøjagtigt, så det hypotetiske budskab passerer. Reelle kritiske modtagertests og ændringsgodkendelse er fortsat ikke leveret.
- Ældre scanner: ejer ubekræftet; Fra, SPF , DKIM og modtagerdækning ukendt. Der kan ikke udledes nogen meddelelsesdom. Tildel en ansvarlig ejer og indhent rutebevis, før du erklærer klar.
Det overordnede udrulningsberedskab er ikke etableret. Selv de to fastsatte pas er ikke observeret produktionsbevis. Den foreslåede ændringsejer bør holde ændringen i bero, indtil ubekendte, godkendelser, gendannelsesudløsere og rutetjek er løst. Ingen kode, DNS forespørgsel eller signaturbekræftelse blev udført for denne hovedbog.
RFC9989 afsnit 7.4 kræver gyldige DKIM signaturer ved publicering af p=reject og fraråder afvisning for domæner, hvis brugere kan sende til mailinglister. Disse domæner skal først vurdere aggregerede data med p=none i mindst en måned, derefter p=quarantine i en lige lang periode. Vælg politikken med disse interoperabilitetsbegrænsninger i udsigt; et rent direkte afsendelseseksempel afgør ikke risikoen for indirekte post.
Bekræft adfærd efter en godkendt udrulning
I en reel ændring skal du fange den offentliggjorte politik, tid, godkendte diff og test for hver kritisk rute. Sammenlign betroede modtagerresultater og faktisk håndtering, og gennemse tilgængelig samlet rapportering med dens dækningsgrænser. Manglende rapporter er ikke et bevis på, at der ikke er sendt nogen mail, eller at der ikke er opstået en fejl. RFC 9990. Undersøg legitime undtagelser ad rute i stedet for generelt at svække beskyttelsen uden en ejer.
Forklar den resterende risiko for svindel i de samme forretningsbetingelser, som blev brugt før håndhævelsen. Betalingsændringer kræver stadig uafhængig verifikation; kontokompromis kræver stadig kontosikkerhedssvar; lookalikes kræver detektion og rapportering med passende omfang. FBI's betalingsbekræftelsesvejledning forbliver relevant, selv når domænet autentificeres. FBI vejledning.
En god afslutningserklæring navngiver den observerede politik, testede ruter, uafklarede undtagelser og resterende kontroller. Det skal ikke sige phishing er løst. Hold ejerskab og periodisk gennemgang aktiv, efterhånden som tjenester, nøgler og forretningsprocesser ændres.