Flytte e-post til ny leverandør – en kontrollert migreringsplan

Ingen seriøs leverandør bør love «null tap og null nedetid» uten å kjenne den gamle tjenesten, datamengden, DNS-oppsettet og alle systemene som sender e-post. En tryggere målsetting er: ingen kjente mangler, målbar kontroll før og etter byttet og en testet vei tilbake hvis lanseringskravene ikke er oppfylt.

Denne planen gjelder flytting av e-post på eget domene mellom to leverandører. Adressene kan forbli de samme, men tjenestene bak dem endres.

Hvis kildeleverandøren er kjent, bruk også den konkrete sjekklisten for å flytte fra Domeneshop , flytte fra one.com , flytte fra Webhuset eller flytte fra Uniweb .

En e-postflytting består av flere spor

MX-posten styrer hvor ny innkommende e-post skal forsøkes levert. Den flytter ikke gamle meldinger, kalendere, regler eller klientinnstillinger.

Steg 1: fastsett mål, toleranse og ansvar

Bestem før arbeidet:

• hvilke domener og adresser som inngår
• tidspunkt og endringsvindu
• hvor lenge brukere kan være uten normal tilgang
• hvor fersk historikken må være ved overgang
• hvilke avvik som stopper byttet
• hvem som beslutter videreføring eller rollback
• hvem som kan endre DNS og begge e-posttjenestene
• hvem som svarer brukerne under og etter byttet

En bedrift med to informasjonspostbokser har en annen risiko enn en virksomhet med delte postbokser, journalkrav, automatiske fakturaer og mange mobile enheter.

Steg 2: lag et komplett register

Ikke bygg planen bare fra listen over brukerkontoer. Registrer:

Adresser og mottak

• personlige postbokser
• delte postbokser
• aliaser
• distribusjonslister og grupper
• videresendinger
• catch-all-oppsett
• returadresser og tekniske adresser

Data og funksjoner

• meldingsantall og datamengde per mappe
• arkiv og bevaringspolicy
• kalender, kontakter, oppgaver og notater
• serverregler, automatiske svar og signaturer
• delegering og Send som-rettigheter
• blokkerings- og tillatelseslister

Systemer som sender

• nettsideskjema og WordPress
• regnskaps- og fakturasystem
• CRM, booking og kundeservice
• printere, skannere og overvåking
• nyhetsbrev og transaksjonelle e-posttjenester
• utviklings-, test- og produksjonsmiljøer

For hver avsender må dere vite synlig Fra-domene, konvoluttavsender, teknisk tjeneste, autentisering og eier. SPF alene viser ikke nødvendigvis hele listen.

Steg 3: ta vare på utgangspunktet

Før endring:

• eksporter DNS-sonen eller lag en maskinlesbar oversikt
• ta skjermbilder som supplement, ikke eneste dokumentasjon
• lagre MX, SPF, DKIM, DMARC, autodiscover og andre e-postposter
• dokumenter TTL-en som faktisk er publisert
• eksporter brukere, aliaser, grupper og videresendinger
• avklar leverandørens backup og gjenopprettingsmulighet
• ta en uavhengig, gjenopprettbar kopi når risikoen krever det
• noter normal e-postflyt og kjente feil før migreringen

En lokal synkronisert klientprofil er ikke automatisk en komplett backup. Kontroller eksportformat og prøv å åpne eller gjenopprette et utvalg.

Steg 4: opprett hele målet før DNS endres

Opprett ny løsning med:

• alle nødvendige postbokser og adresser
• riktige kvoter og lisenser
• roller, deling og minst mulig tilgang
• MFA og gjenopprettingsrutine
• kalender og kontakter hvis løsningen støtter det
• policy for spam, skadevare og videresending
• supportkontakter og administratorer

Test innlogging direkte hos ny leverandør uten å endre MX. Opprett ikke bare én pilotbruker dersom flere adressetyper skal fungere etter byttet.

Steg 5: klargjør autentisering før sending

Ny leverandør gir normalt DNS-verdier for DKIM og informasjon til SPF. Planlegg overgangsperioden:

• publiser ny DKIM-nøkkel og bekreft at den kan slås opp
• oppdater den ene eksisterende SPF-posten slik at autoriserte gamle og nye sendere dekkes mens begge brukes
• ikke publiser flere separate SPF-poster for samme navn
• kontroller at alle legitime avsendere kan oppnå DMARC-samsvar
• ikke stram DMARC-policy samtidig med flyttingen med mindre dette er testet separat

Fjern gammel avsender fra SPF først etter at alle systemer faktisk har sluttet å bruke den. Gjennomgå SPF, DKIM og DMARC som et samlet system og kontroller hele SPF-oppslagskjeden dersom posten blir kompleks.

Steg 6: senk TTL tidlig nok

En lav ny TTL påvirker bare oppslag som henter den nye verdien. En resolver som allerede har cachet den gamle MX-posten, kan beholde den til den gamle TTL-en utløper.

Gjør derfor dette minst én full tidligere TTL-periode før MX-bytte:

1. Les den publiserte TTL-en for MX.
2. Sett en planlagt, lavere verdi dersom DNS-leverandøren tillater det.
3. Vent minst den gamle TTL-en.
4. Bekreft den nye TTL-en fra flere eksterne oppslag.

Ikke bruk 300 sekunder som et magisk krav. En lav verdi gir flere DNS-oppslag og skal bare brukes kontrollert rundt endringen. Dokumenter hva dere valgte og når normal verdi skal gjenopprettes.

Steg 7: gjør en første datakopi

Bruk leverandørens migreringsverktøy eller en profesjonell migreringstjeneste når det finnes. Det gir ofte bedre logging, parallellitet og differansesynkronisering enn manuell draing i en e-postklient.

IMAP-til-IMAP kan kopiere meldinger og servermapper, men er ikke en komplett migrering av:

• kalendere og kontakter
• klientregler og lokale mapper
• delegering og delte postbokstillatelser
• arkiv- eller bevaringspolicy
• signaturer og automatiske svar
• passord og MFA

IMAP-standarden har funksjoner for meldinger, mapper og flagg, men kilde, mål og verktøy kan støtte ulike detaljer og begrensninger.

Kjør første kopi mens gammel tjeneste fortsatt er i normal drift. Kopier, ikke slett. Registrer feil, ratebegrensning og resultat per bruker.

Steg 8: avstem første kopi

Ikke nøye dere med «jobben fullført». Sammenlign:

• mapper per konto
• antall meldinger per mappe
• datamengde, med forklaring på forventede formatforskjeller
• eldste og nyeste melding
• store meldinger og vedlegg
• norske tegn og spesielle mappenavn
• leste, flaggede og sendte meldinger
• et tilfeldig utvalg fra ulike år

Noen systemmapper har forskjellige navn hos leverandørene. Kontroller at Sendt, Papirkurv, Utkast, Søppelpost og Arkiv havner riktig og ikke blir duplisert.

Steg 9: test kritiske flyter før byttet

Bruk leverandørens testmetode eller et kontrollert testdomene. Verifiser:

• innlogging med MFA
• webmail og klienttilgang
• intern sending mellom nye kontoer
• sending til flere eksterne leverandører
• svar og videresending
• alias, gruppe og delt postboks
• DKIM-signatur og DMARC-samsvar
• kalender og kontakter dersom det inngår
• SMTP fra minst ett representativt system
• varsling og supportvei ved feil

Kontroller meldingshoder og leveringsresultat, ikke bare at meldingen finnes i innboksen.

Steg 10: forbered klienter og brukere

Gi brukerne et konkret tidspunkt og en kort veiledning:

• nytt brukernavn og aktiveringsmåte
• MFA-oppsett og gjenoppretting
• webmail-adresse
• hva som skjer med mobil og skrivebordsklient
• hvordan rapportere manglende mapper eller meldinger
• hva de ikke skal gjøre under overgangsvinduet

Automatisk klientkonfigurasjon kan endres via DNS eller enhetsstyring, men må testes. Ikke anta at alle klienter oppdager nytt servernavn bare fordi MX er endret; MX brukes til mottak mellom e-postsystemer, ikke som klientinnstilling.

Steg 11: bytt MX kontrollert

Ved start av endringsvinduet:

1. Bekreft at ny tjeneste er frisk.
2. Bekreft at gammel tjeneste fortsatt mottar.
3. Ta en siste konfigurasjonseksport.
4. Endre MX nøyaktig etter ny leverandørs verdier.
5. Kontroller autoritative navnetjenere og eksterne resolvere.
6. Test ekstern innkommende post til alle adressetyper.
7. Test utgående post og svar.
8. Overvåk avvisninger, forsinkelser og autentiseringsresultater.

Ikke bruk gammel og ny leverandør som likeverdige MX-poster for å «fordele» overgangen. MX-prioritet beskriver hvilket mottakssystem en avsender skal forsøke først og deretter ved feil; det er ikke en mekanisme for å synkronisere to uavhengige postbokser.

Steg 12: behold gammel mottakstjeneste og kjør differansekopi

Noen avsendere kan fortsatt ha gammel DNS-informasjon. Andre meldinger kan ligge i kø etter et midlertidig leveringsproblem.

Hold derfor gammel tjeneste aktiv til:

• minst hele den tidligere TTL-en er passert etter MX-endringen
• ingen nye meldinger har kommet til gammel side i den avtalte observasjonsperioden
• leveringskøer og forsinkelser er vurdert
• differansekopi er kjørt
• avstemmingen er godkjent

Det finnes ingen universell 48- eller 72-timersgrense som beviser at alt er ferdig. Observasjonsperioden bestemmes av tidligere TTL, leverandørenes køatferd, risiko og faktisk trafikk.

Kjør én eller flere differansesynkroniseringer fra gammel til ny tjeneste. Dersom brukere har arbeidet begge steder, må dere håndtere endringer i begge retninger eller stoppe skriveaktivitet kontrollert; en enkel kopi kan ellers overskrive eller duplisere.

Steg 13: avstem hele kjeden

Etter byttet skal dere kontrollere:

Loggfør kjente avvik med eier og frist. «Ingen har klaget» er ikke en avstemming.

Rollback må planlegges før MX-bytte

Definer når dere skal gå tilbake, for eksempel:

• kritiske adressetyper mottar ikke
• utgående e-post blir systematisk avvist
• brukere kan ikke autentisere
• vesentlig historikk mangler
• integrasjoner har ingen sikker midlertidig løsning

En DNS-rollback er ikke øyeblikkelig, av samme TTL-grunn som selve overgangen. Gammel tjeneste må fortsatt være intakt, og meldinger som har kommet til ny side må senere avstemmes.

Skriv hvem som beslutter rollback, hvilken DNS-konfigurasjon som gjenopprettes og hvordan post på begge sider samles etterpå.

Steg 14: avvikle gammel tjeneste sist

Avslutt ikke før dere har:

• godkjent migrerings- og avstemmingsrapport
• eksportert eller flyttet nødvendig arkiv
• tatt vare på juridisk og forretningsmessig nødvendig dokumentasjon
• fjernet gamle SMTP-avhengigheter
• oppdatert SPF og andre DNS-poster
• fjernet gamle administratorer og integrasjoner
• avtalt sikker sletting og tidspunkt hos gammel leverandør
• gjenopprettet normal TTL
• dokumentert ny drifts- og supportmodell

Behold ikke gamle kontoer uten sluttdato «for sikkerhets skyld». De blir ellers glemte tilganger og ekstra angrepsflate.

Flytte e-post til Vymo

Vymo tilbyr e-post på eget domene fra 19 kroner per måned per konto. Basis har 15 GB lagring, webmail, IMAP og POP3. Hvor mye Vymo kan bistå med ved flytting, avhenger av den gamle leverandøren, antall kontoer, datamengde, protokoller og om kalender, kontakter eller andre funksjoner inngår.

En bestilling er derfor ikke et automatisk løfte om komplett migrering. Beskriv dagens leverandør, kontoer, aliaser, lagringsmengde og nødvendige integrasjoner, så kan omfang, ansvar og pris avklares før endringen starter.

Se innhold og priser for Vymo e-post , eller send migreringsgrunnlaget til Vymo før dere avtaler dato.