En repeterbar onboarding-prosess starter med kundegrensen. Fastslå hvilke juridiske enheter, domener, applikasjoner og administratorer som er innenfor omfanget før du samler inn rapporter eller foreslår DNS endringer. En delt tjeneste skal ikke utlede kundeautoritet fra et domene som vises i et salgsregneark eller et offentlig DNS oppslag.
Etablere tjenestegrensen
Navngi kundesponsor, teknisk eier, DNS ansvarlig, MSP-analytiker, endringsgodkjenner og hendelseskontakt. Registrer deres ansvar og backup-dekning. Bekreft autoritet gjennom den avtalte ombordstigningsprosessen, og gi kun tilgangen med omfang som er nødvendig for det nåværende stadiet. Å lese rapporter og endre autentiseringsposter er distinkte tillatelser.
Opprett et avsenderregister som inkluderer forretningsformål, applikasjonseier, synlig fra domene, konvoluttdomene, signeringsdomene og forventet aktivitetssyklus. Inkluder planlagte tjenester og lavvolumstjenester. Et fravær i et kort observasjonsvindu er ikke bevis på at en tjeneste er ubrukt. RFC 9990 samlede rapporter beskrive rapportert meldingsaktivitet; de er ikke en autoritativ applikasjonsbeholdning.
Gå gjennom iscenesatt aksept
Godta først inventar og bevisinnsamling. Evaluer deretter kjente sendebaner og forklar feil. Foreslå deretter endringer med eksakt diff, godkjenning og tilbakeføringsbetingelser. Bekreft til slutt den tiltenkte flyten med meldinger fra den faktiske applikasjonen og resultatene på mottakersiden. DMARC stoler på justering samt SPF eller DKIM autentisering under RFC 9989, så en generisk passetikett er ikke nok.
Ikke flytt alle domener til en håndhevelsespolicy bare fordi malen sier at onboarding er fullført. Registrer unntak, uløste avsendere, videresendere og postlistestier. Definer hvem som aksepterer gjenværende risiko og når bevisene skal gjennomgås. Policybeslutninger må følge kundens e-postavhengigheter og autorisasjon.
Hold to ombordstigningsrom atskilt
Anta at en kundes faktureringsapplikasjon har en gjeldende autorisert justert-pass-prøve, mens dens kvartalsvise varsler ikke har kjørt og dens alternative DNS godkjenner er ubekreftet. Godta faktureringsbeviset for det testede omfanget, behold varsleren som uprøvd, og løs godkjenningsreserven før du stoler på den. En utfylt sjekkliste for inntak kan ikke gjøre disse hullene til operasjonell aksept.
Dette er hypotetiske onboarding-beslutninger, ikke en levert kunde-runbook eller utført fullstendighetssjekk. For hvert trinn, registrer den ansvarlige personen, nøyaktige akseptbevis og uløste forhold. Ved avslutningsplanlegging, kreve bekreftelse på tilbakekall av tilgang gjennom det ansvarlige systemet i stedet for et løfte om at et fremtidig skript vil fjerne det. Ingen kundegodkjenning, DNS skriving eller rapportering av inntak hevdes her.
Overlate driften og planlegge utgangen
Gi kunden et gjeldende domeneregister, godkjent konfigurasjon, åpne unntak og eskaleringsrute. Spesifiser rapporttilgjengelighet, overvåkingsdekning og oppbevaringsansvar. Forklar hva MSP kan måle og hva som avhenger av kunder, DNS verter og mottakere. Vellykket autentisering lover ikke innboksplassering.
En utgangsplan bør identifisere eksportformat, autorisert mottaker, tilbakekall av tilgang, oppbevart revisjonsbevis og slettingsansvar. Ikke slett automatisk nyttige autentiseringsposter under offboarding: kunden kan fortsatt være avhengig av dem. Overføre teknisk ansvar, teste fortsatt postflyt og trekke tilbake tilgang under en godkjent plan. Gå gjennom tjenesten hver gang eierskap, applikasjoner eller forretningskritiske flyter endres.