En migrering av e-postleverandør kan la to legitime sendesystemer være aktive samtidig. Den tryggeste SPF planen starter med meldingene og identitetene som vil eksistere under den overlappingen. Å legge til den nye leverandøren er bare ett trinn; å fjerne den gamle for tidlig eller beholde den på ubestemt tid skaper forskjellige problemer.
Inventar migrasjonsgrensen
Liste ansattes e-post, applikasjonsvarsler, fakturering, automatiserte svar og enheter som videresender gjennom den gamle plattformen. For hver flyt, fange opp det faktiske konvoluttdomenet og utgående rute. Den synlige Fra-adressen er ikke nødvendigvis SPF identiteten. Bruk e-postidentitetskjede å holde disse feltene atskilt.
Spør den nye leverandøren om gjeldende instruksjoner for leietaker og konfigurasjon. Noen tjenester bruker sitt eget konvoluttdomene med mindre en egendefinert returbane er konfigurert. Å legge til en inkludering i rotdomenet ditt endrer ikke automatisk denne identiteten. Ikke oppfinn leverandørverdier eller gjenbruk en annen leietakers oppsett.
Utform overlappingspolitikken
Behold en gjeldende SPF rekord ved hvert evaluert eiernavn. Ikke publiser de gamle og nye retningslinjene som separate konkurrerende SPF poster. RFC 7208 §3.2 og RFC 7208 §4.5 definere valgbegrensningen.
Bygg en kandidat som inneholder de fortsatt nødvendige autorisasjonene. Evaluer det kombinerte avhengighetstreet fordi to individuelt akseptable konfigurasjoner kan produsere en problematisk kombinert bane. Test de faktiske konvoluttdomenene og IP-familiene som er i bruk. Unngå bare å telle toppnivå-inkluderer eller anta at et leverandørnavn i DNS viser riktig konfigurasjon.
Registrer det tiltenkte sluttresultatet som ikke samsvarer, og sørg for at det ikke har endret seg ved et uhell. En migrering er ikke en grunn til å gi universell autorisasjon. Beholde DKIM oppsett og DMARC justering verifisering i planen som distinkte arbeidsstrømmer.
Repeter cutoveren
Denne illustrative migreringen har personalpost som flyttes på mandag mens en faktureringsapplikasjon forblir på det gamle reléet til fredag. Fjerning av den gamle autorisasjonen på mandag ville ignorere søknadsplanen. Omvendt, å forlate den for alltid fordi fakturaer en gang ble brukt den, ville unngå avviklingsbeslutningen. Planen trenger et eget eier- og utgangskriterium for den flyten.
Før produksjon, bevar den gamle DNS verdien, den foreslåtte overlappingsverdien og gjenopprettingsbeslutningen. Gjennomgå tidligere TTL-er og forventet bufringsatferd uten å love at alle mottakere endres samtidig. Test den nye banen med vanlige meldinger og viktige automatiserte varianter, ikke bare en leverandørs interne verifiseringsskjerm.
Sjekk mottakerens bevis
Samle en mottatt prøve fra hver relevant rute og inspiser den pålitelige mottakerens autentiseringsresultat, evaluerte konvoluttidentitet og synlige Fra-domene. RFC 8601 forklarer tillitsgrensen for Authentication-Results; en overskrift satt inn utenfor denne grensen er ikke et uavhengig bevis.
Et rå SPF pass etablerer ikke DMARC justering. RFC 9989 avsnitt 4.4 knytter autentiserte identiteter til forfatterdomenet. Bekreft den nye rutens justerte autentisering i stedet for å behandle et vellykket DNS oppslag som fullføring. Levering kan fortsatt avhenge av andre mottakerpolicyer.
Fjern den gamle autoriteten bevisst
Bruk søknad-eier-bekreftelse, utsendelse av logger og representativ observasjon for å bestemme når den gamle ruten ikke lenger er nødvendig. Vurder gjenforsøk i kø og uvanlige planlagte jobber. Det er ingen enkelt venteperiode som beviser at hver organisasjon har sluttet å bruke en leverandør.
Forbered og godkjenn en ny policyendring som fjerner bare det pensjonerte omfanget. Gjenta positive og negative evalueringer og verifiser de gjenværende strømmene. Hold en tilbakeføringsplan som tar hensyn til om den gamle tjenesten fortsatt eksisterer; en lagret DNS post kan ikke gjenopprette en kansellert sendekonto.
Lukk migreringen når inventar, DNS , tester for mottatte meldinger og eierskapsposter er enige. Behold pensjonsbeviset slik at neste administrator vet hvorfor den gamle leverandøren ble fjernet i stedet for å legge den til på nytt som svar på en urelatert feil.
DNS -bakgrunn: RFC 1035 avsnitt 3.2.1 definerer ressurs-record TTL; RFC 2308 §5 dekker negativ caching; RFC 8767 §4 oppdaterer TTL-semantikk og tillater gammel bruk når autoritativ oppdatering mislykkes. Disse beskriver DNS atferd, ikke en universell fullføringstid for en endring.
Registrer neste avgjørelse
Spor ansatte og fakturaer som separate rader: eier, gjeldende rute, faktisk konvoluttdomene, krav om overlapping, bevis for ny rute og pensjonstilstand. Personalnedskjæring gir ikke rett til å fjerne fakturaavhengigheten. Hvis den gamle kontoen er kansellert, merker du tilbakerulling av ruting som utilgjengelig selv om en gammel DNS verdi er lagret. Dette er en foreslått akseptoppføring, ikke en utført migrering.