En migrering af e-mail-udbydere kan lade to legitime afsendelsessystemer være aktive på én gang. Den sikreste SPF planen starter med de beskeder og identiteter, der vil eksistere under det overlap. Tilføjelse af den nye udbyder er kun ét trin; at fjerne den gamle for tidligt eller bevare den på ubestemt tid skaber forskellige problemer.
Inventar migrationsgrænsen
List medarbejdermail, applikationsmeddelelser, fakturering, automatiske svar og enheder, der videresender gennem den gamle platform. For hvert flow skal du fange det faktiske kuvertdomæne og udgående rute. Den synlige Fra-adresse er ikke nødvendigvis SPF identiteten. Brug e-mail-identitetskæde at holde disse felter adskilt.
Spørg den nye udbyder om de aktuelle instruktioner til din lejer og konfiguration. Nogle tjenester bruger deres eget kuvertdomæne, medmindre der er konfigureret en tilpasset retursti. Tilføjelse af en inkludering til dit roddomæne ændrer ikke automatisk denne identitet. Opfind ikke udbyderværdier eller genbrug en anden lejers opsætning.
Design overlapningspolitikken
Bevar en gældende SPF rekord ved hvert vurderet ejernavn. Udgiv ikke de gamle og nye politikker som separate konkurrerende SPF poster. RFC 7208 §3.2 og RFC 7208 §4.5 definere valgbegrænsningen.
Byg en kandidat, der indeholder de stadig nødvendige autorisationer. Evaluer det kombinerede afhængighedstræ, fordi to individuelt acceptable konfigurationer kan producere en problematisk kombineret sti. Test de faktiske kuvertdomæner og IP-familier, der er i brug. Undgå blot at tælle med på øverste niveau eller antage, at et udbydernavn i DNS beviser den rigtige konfiguration.
Registrer det tilsigtede endelige ikke-matchende resultat, og sørg for, at det ikke er ændret ved et uheld. En migration er ikke en grund til at give universel autorisation. Holde DKIM opsætning og DMARC justering verifikation i planen som adskilte arbejdsstrømme.
Øv cutover
Denne illustrative migrering flytter personalepost på mandag, mens en faktureringsapplikation forbliver på det gamle relæ indtil fredag. Fjernelse af den gamle tilladelse på mandag ville ignorere ansøgningsplanen. Omvendt ville det undgå nedlukningsbeslutningen, hvis den forlades for evigt, fordi fakturaer engang er brugt den. Planen har brug for et separat ejer- og exitkriterium for det flow.
Før produktion skal du bevare den gamle DNS værdi, den foreslåede overlapningsværdi og gendannelsesbeslutningen. Gennemgå tidligere TTL'er og forventet cacheadfærd uden at love, at alle modtagere ændres samtidigt. Test den nye vej med almindelige beskeder og vigtige automatiserede varianter, ikke kun en udbyders interne bekræftelsesskærm.
Tjek modtagerens beviser
Indsaml en modtaget prøve fra hver relevant rute, og inspicér den betroede modtagers godkendelsesresultat, evaluerede kuvertidentitet og synlige Fra-domæne. RFC 8601 forklarer tillidsgrænsen for Authentication-Results; en overskrift indsat uden for denne grænse er ikke uafhængigt bevis.
Et rå SPF -pas etablerer ikke DMARC justering. RFC 9989 afsnit 4.4 relaterer autentificerede identiteter til forfatterdomænet. Bekræft den nye rutes tilpassede godkendelse i stedet for at behandle et vellykket DNS opslag som fuldførelse. Levering kan stadig afhænge af andre modtagerpolitikker.
Fjern den gamle autoritet bevidst
Brug ansøgning-ejer-bekræftelse, afsendelse af logfiler og repræsentativ observation til at beslutte, hvornår den gamle rute ikke længere er nødvendig. Overvej genforsøg i kø og usædvanlige planlagte job. Der er ingen enkelt venteperiode, der beviser, at enhver organisation er holdt op med at bruge en udbyder.
Forbered og godkend en anden politikændring, der kun fjerner det pensionerede omfang. Gentag positive og negative evalueringer og verificer de resterende strømme. Hold en tilbagerulningsplan, der tager højde for, om den gamle tjeneste stadig eksisterer; en gemt DNS post kan ikke gendanne en annulleret afsenderkonto.
Luk migreringen, når beholdningen, DNS , testene for modtaget meddelelse og ejerskabsregistreringer er enige. Opbevar pensionsbeviset, så den næste administrator ved, hvorfor den gamle udbyder blev fjernet i stedet for at tilføje den igen som svar på en ikke-relateret fejl.
DNS -baggrund: RFC 1035 afsnit 3.2.1 definerer ressource-record TTL; RFC 2308 §5 dækker negativ caching; RFC 8767 §4 opdaterer TTL-semantik og tillader gammel brug, når autoritativ opdatering mislykkes. Disse beskriver DNS adfærd, ikke en universel færdiggørelsestid for en ændring.
Optag den næste beslutning
Spor personale og fakturaer som separate rækker: ejer, nuværende rute, faktisk kuvertdomæne, krav om overlapning, bevis for ny rute og pensionstilstand. Medarbejdernedskæring giver ikke tilladelse til at fjerne fakturaafhængigheden. Hvis den gamle konto annulleres, skal du markere routing rollback utilgængelig, selvom en gammel DNS værdi er gemt. Dette er en foreslået acceptpost, ikke en udført migrering.