Toistettava käyttöönottoprosessi alkaa asiakasrajasta. Selvitä, mitkä oikeushenkilöt, toimialueet, sovellukset ja järjestelmänvalvojat kuuluvat, ennen kuin keräät raportteja tai ehdotat DNS muutoksia. Jaettu palvelu ei saa päätellä asiakkaan valtuuksia myyntitaulukossa tai julkisessa DNS haussa näkyvästä verkkotunnuksesta.
Määritä palveluraja
Nimeä asiakkaan sponsori, tekninen omistaja, DNS säilyttäjä, MSP-analyytikko, muutoksen hyväksyjä ja tapahtuman yhteyshenkilö. Kirjaa ylös heidän vastuunsa ja varmuuskopiointi. Vahvista valtuudet sovitun käyttöönottoprosessin kautta ja myönnä vain nykyiseen vaiheeseen tarvittava rajattu käyttöoikeus. Raporttien lukeminen ja todennustietueiden muuttaminen ovat erilliset oikeudet.
Luo lähettäjärekisteri, joka sisältää liiketoiminnan tarkoituksen, sovelluksen omistajan, näkyvän Lähettäjä-toimialueen, kirjekuoriverkkotunnuksen, allekirjoitustoimialueen ja odotetun toimintajakson. Sisällytä aikataulutetut ja vähäiset palvelut. Lyhyen havaintoikkunan poissaolo ei ole todiste siitä, että palvelu on käyttämättä. RFC 9990 koontiraportit kuvaile raportoitu viestitoiminta; ne eivät ole arvovaltainen sovellusluettelo.
Siirry vaiheittaisen hyväksynnän läpi
Hyväksy ensin inventaario ja todisteiden kerääminen. Seuraavaksi arvioi tunnetut lähetysreitit ja selitä epäonnistumiset. Ehdota sitten muutoksia tarkalla erolla, hyväksynnällä ja palautusehdot. Tarkista lopuksi aiottu kulku todellisen sovelluksen viesteillä ja vastaanottajan puolella. DMARC luottaa linjaus samoin kuin SPF tai DKIM todennus alla RFC 9989, joten yleinen passin etiketti ei riitä.
Älä siirrä jokaista verkkotunnusta valvontakäytäntöön vain siksi, että mallin mukaan käyttöönotto on valmis. Tallenna poikkeukset, ratkaisemattomat lähettäjät, välittäjät ja postituslistapolut. Määrittele, kuka hyväksyy jäännösriskin ja milloin todisteet tarkistetaan. Käytäntöpäätösten tulee noudattaa asiakkaan postiriippuvuutta ja valtuutusta.
Pidä kaksi aloitustilaa erillään
Oletetaan, että asiakkaan laskutussovelluksella on voimassa oleva valtuutettu tasatun passin näyte, kun sen neljännesvuosittaista ilmoitusta ei ole suoritettu ja sen vaihtoehtoista DNS hyväksyntää ei ole vahvistettu. Hyväksy testatun laajuuden laskutustodisteet, säilytä ilmoittaja testaamattomana ja ratkaise hyväksyntävarmennus ennen kuin luotat siihen. Täytetty saannin tarkistuslista ei voi muuttaa näitä aukkoja toiminnalliseksi hyväksymiseksi.
Nämä ovat hypoteettisia käyttöönottopäätöksiä, eivät toimitettua asiakkaan runbookia tai suoritettua täydellisyyden tarkistusta. Kirjaa kunkin vaiheen osalta vastuuhenkilö, tarkat hyväksymistodistukset ja ratkaisemattomat ehdot. Poistumissuunnitelmassa vaaditaan vahvistus pääsyn peruuttamisesta vastuullisen järjestelmän kautta sen sijaan, että lupaat, että tuleva komentosarja poistaa sen. Täällä ei vaadita asiakkaan hyväksyntää, DNS kirjoitusta tai raporttien käsittelyä.
Luovuta toiminta ja suunnittele poistuminen
Anna asiakkaalle nykyinen verkkotunnusrekisteri, hyväksytty kokoonpano, avoimet poikkeukset ja eskalaatioreitti. Määritä raportin saatavuus, valvontakattavuus ja säilytysvastuut. Selitä, mitä MSP voi mitata ja mikä riippuu asiakkaista, DNS isännistä ja vastaanottimista. Onnistunut todennus ei lupaa postilaatikon sijoittamista.
Poistumissuunnitelmassa tulee yksilöidä vientimuoto, valtuutettu vastaanottaja, pääsyn peruuttaminen, säilytetty tarkastustodistus ja poistamisvastuut. Älä poista automaattisesti hyödyllisiä todennustietueita offboardin aikana: asiakas voi silti olla riippuvainen niistä. Siirrä tekninen vastuu, testaa jatkuvaa postinkulkua ja lopeta pääsy hyväksytyn suunnitelman mukaisesti. Tarkista palvelu aina, kun omistajuus, sovellukset tai liiketoimintakriittiset virrat muuttuvat.