En arvet avsenderbeholdning er et beslutningsverktøy, ikke en liste over IP-adresser. Før du standardiserer oppkjøpte domener, koble observert e-post til den kundespesifikke tjenesten som produserte den, bedriftseieren og dens godkjente identiteter. En kjent leverandør kan være vert for både legitim og uønsket trafikk, så infrastrukturgjenkjenning alene er ikke godkjenning.
Start med flere beviskilder
Samle autorisert konfigurasjonseksport, applikasjonsregistre, leverandørkontoposter, DNS observasjoner og tilgjengelig e-postbevis. Ta vare på hvor hver observasjon kom fra og når den ble samlet inn. Samlede rapporter kan avsløre kilde-IP-er og autentiseringsmønstre, men kan ikke uavhengig etablere organisasjonens forretningshensikt eller komplette avsenderpopulasjon. RFC 9990.
For hver tjeneste, postformål, ansvarlig eier, leverandørkonto eller leietaker, kritikalitet, synlig Fra domene, konvoluttdomene, DKIM signeringsidentitet, siste representativ test og godkjenningsbevis. Hold ukjente felt eksplisitte. Registrer sending og mottak separat for domener som kan være sovende eller defensive.
Tilordne identiteter før du legger til autoritet
Sammenlign de observerte identifikatorene med den faktiske leverandørkonfigurasjonen og forretningsflyten. DMARC bruker justering mellom forfatterdomenet og en vellykket autentisert identifikator; et generisk passresultat uten identifikatorene kan skjule problemet du må løse. RFC 9989.
Ikke legg til en ukjent kilde til SPF rett og slett fordi post ser ut til å stamme der. SPF autoriserer verter for den evaluerte identiteten, og evalueringen inkluderer DNS oppslagsgrenser. RFC 7208 , avsnitt 4.6.4. En ny inkluderer kan utvide autoritet, overskride operasjonelle grenser eller mislykkes i å fikse justering. Etabler den tiltenkte tjenesten og passende autentisert rute først.
Hold godkjenning og testing adskilt
En godkjent tjeneste kan fortsatt mislykkes i en migrasjonstest; en autentisert melding kan fortsatt komme fra en ikke-godkjent tjeneste. Lagre begge stater. Godkjenningsbevis bør identifisere den ansvarlige beslutningen, mens testbevis bør beskrive den faktiske transaksjonen, identiteter, resultat og tidspunkt. Ikke bruk prøvebestått som erstatning for bedriftseierskap.
Anta at en arvet faktureringstjeneste har en navngitt bedriftseier og godkjent formål, men målkontoens signeringsidentitet er ikke bekreftet. En annen tjeneste har en justert bestått melding, men ingen identifisert bedriftseier. Den første trenger rutebevis før migrering; den andre må tilskrives og godkjennes før den behandles som en autorisert tjeneste. Ingen av gapet løses av den andre tjenestens betryggende resultat.
Dette er hypotetiske inventarbeslutninger, ikke genererte poster eller utførte tester. Hold separate felt for eierskap, tiltenkte identiteter, godkjenning og gjeldende testdekning. Når applikasjonseieren oppgir manglende kontobevis, oppdater kun tilstanden den etablerer; ikke automatisk endre et utestet migreringsresultat til bestått.
Gjør attribusjon til en migrasjonsplan
Grupper tjenester etter verifisert eier, avhengighet og beredskap. Definer de tiltenkte målidentitetene og testene før du redigerer poster. Bevar ukjente ruter for etterforskning, med en navngitt eier og frist, i stedet for å godkjenne eller slette dem i det stille. Behold den gamle konfigurasjonen og en godkjent gjenopprettingsplan for hver påfølgende overgang.
Etter standardisering, avstem faktiske observasjoner mot godkjent inventar og undersøk nye identiteter. Hold pensjonerte tjenester og deres beslutninger i historien. En nyttig inventar forblir en driftspost gjennom leverandørendringer og hendelsesrespons, i stedet for et regneark som forlates når fusjonsprosjektet avsluttes.
Denne arbeidsflyten for inventar og gjennomgang er en anbefalt driftsmodell. NIST SP 800-53 Rev. 5 CM-8 og CM-3 gir et generelt grunnlag for ansvarlige varelager og kontrollerte endringer; de foreskriver ikke disse e-postspesifikke feltene eller gir godkjenning. NIST kontrollkatalog.