A DMARC endringsforespørsel bør tillate en annen person å bestemme nøyaktig hva som vil endres, hvilke tjenester som kan bli påvirket og hvordan suksess vil bli demonstrert. Et skjermbilde som viser ønsket policy er ikke nok. Bevar grunnlinjen og foreslåtte RRset, og koble dem deretter til godkjente forretningsflyter og en gjenopprettingsbeslutning.
Fang grunnlinjen nøyaktig
Registrer DNS leverandørens konto eller leietaker, sone, eiernavn, posttype, fullstendig verdi og TTL. Inkluder tidspunkt og kilde for observasjonen. Registrer gjeldende DMARC policyoppdagelse for berørte forfatterdomener, pluss godkjente avsendere og eventuelle uløste unntak. Bevar autentiseringsidentifikatorer i stedet for å redusere en test til en dashbordfarge.
DMARC kan passere gjennom en justert vellykket SPF eller DKIM resultat. En melding er synlig fra domenet og dets autentiserte identifikatorer betyr derfor mer enn en generisk uttalelse som SPF sender. RFC 9989. For domenepublisering p=reject, RFC 9989 seksjoner 7.4 og 8 separat krever gyldige DKIM signaturer og forbyr kun tillit til SPF ; suksess på meldingsnivå fraviker ikke denne distribusjonsplikten. Et autentiseringspass bekrefter ikke forretningsforespørselen eller sikrer innboksplassering.
Beskriv den tiltenkte forskjellen
Oppgi de nøyaktige før-og-etter RR-sett og berørte navn. Forklar hvorfor endringen er nødvendig nå, hvilke tjenester som ble testet og hvilke bevis som fortsatt er ufullstendige. Hold urelaterte DNS redigeringer utenfor forespørselen, slik at en godkjenner ikke ved et uhell godkjenner en bredere operasjon. Identifiser teknisk implementer, virksomhetsgodkjenner og eskaleringskontakt.
Hvis rapporteringsdestinasjoner eller delegerte tjenester endres, vurdere informasjonsflyten og avhengigheten separat. Ta vare på konfigurasjonen for rapportinntak som er nødvendig for den tiltenkte overvåkingen. Samlede rapporter er mottakerobservasjoner med dekningsbegrensninger, så de kan ikke være det eneste akseptsignalet for en tidskritisk legitim flyt. RFC 9990.
Skriv observerbare akseptkriterier
Bruk kriterier som kan mislykkes: det autoritative RR-settet er lik den godkjente verdien; Representative kritiske meldinger bruker tiltenkte identiteter og autentiserer som forventet; bedriftsmottakeren bekrefter det forventede resultatet; og rapportinntaket fortsetter. Registrer observasjonstider og skille umiddelbart tilgjengelige tester fra senere rapportgjennomgang. En rapport som ikke har kommet ennå er ikke en bestått prøve.
Definer gjenopprettingsutløsere før implementering. Hvis en kritisk flyt mislykkes og diagnose kobler den til den godkjente endringen, påkaller du den godkjente gjenopprettingsplanen. Bevar den gamle staten og forklar dens begrensninger. Gjenoppretting av en policy reverserer ikke bufret DNS umiddelbart eller tilbakekaller meldinger som allerede er avvist. Plan observasjon utover det nominelle vedlikeholdsvinduet.
Test om en forespørsel faktisk kan lukkes
Anta at en hypotetisk forespørsel bare endrer policyen for et lønnsregister fra domene fra p=none til p=quarantine samtidig som den beholder rapporteringsdestinasjonen og TTL. Gjennomgangen må fortsatt binde hele grunnlinjen og foreslåtte RRset, målkonto og domene, godkjent lønnsomfang og gjenopprettingsplan. Ingen reell nyttelast, godkjenning eller DNS endring leveres her.
Anta at en autorisert observasjon etter endring samsvarer med den godkjente DNS tilstanden og en representant lønnsmelding autentiserer som forventet, men bedriftsmottakeren har ikke bekreftet mottak og den neste samlede rapporten er ennå ikke tilgjengelig. Registrer konfigurasjons- og autentiseringssjekker separat fra de ventende resultatene. Tildele kvitteringsoppfølging til lønnseier og forsinket inntaksgjennomgang til rapporterende eier; ikke lukk alle akseptkriterier på grunnlag av en samsvarende post. Dette er hypotetiske funn, ikke utførte kontroller.
Endre arbeidsflyten ovenfor er en driftsanbefaling, ikke et protokollkrav. NIST SP 800-53 Rev. 5 kontroller CM-3 og CM-5 gir et generelt grunnlag for å vurdere, godkjenne og begrense endringer; den nøyaktige nyttelastbindingen, rollene og overleveringsfeltene her er den foreslåtte implementeringen. NIST kontrollkatalog.