Miten teen Google Workspace -käyttöönoton niin, ettei sähköposti katkea? (DNS, siirrot ja varmistukset)

Google Workspace -käyttöönotto ilman sähköpostikatkosta tehdään niin, että rakennat uuden ympäristön valmiiksi, lasket DNS:n TTL-arvot ajoissa, vaihdat MX-tietueet hallitussa ikkunassa ja varmistat SPF-, DKIM- ja DMARC-asetukset ennen kuin mikään tuotantoliikenne käännetään. Kun lisäksi siirrät vanhat viestit ja kalenterit rinnakkaisajossa ja pidät palautuspolun valmiina, sähköposti ei katkea, vaikka DNS ehtii elää 1–48 tuntia.

Google Workspace -käyttöönotto ilman sähköpostikatkosta alkaa DNS-riskien pienentämisestä

Sähköpostikatkot syntyvät lähes aina kahdesta syystä: MX-tietueet vaihtuvat, mutta osa lähettäjistä ohjautuu vielä vanhalle palvelimelle, tai todennus (SPF/DKIM/DMARC) jää puolitiehen ja viestit alkavat pompata tai mennä roskapostiin. Siksi ensimmäinen askel on DNS-riskin pienentäminen, ei itse MX-vaihto.

Tee tämä 48–72 tuntia ennen vaihtoa: laske domainin TTL esimerkiksi arvoon 300 sekuntia (5 min) niissä tietueissa, joita aiot muuttaa (MX, SPF/TXT, DKIM). Jos TTL on nyt 3 600–14 400 sekuntia, muutos vaikuttaa hitaasti, ja “käännön” jälkeen osa maailmasta näkee vanhaa reittiä pitkään.

Samalla varmista, että sinulla on täydellinen varmuuskopio nykyisestä DNS:stä (kuvakaappaus tai export) ja pääsy sekä domainin DNS-hallintaan että vanhan sähköpostipalvelun adminiin. Jos nämä eivät ole käsissäsi, riski kasvaa nopeasti.

Jos yrityksesi sähköposti on osa myyntiä ja asiakaspalvelua, ajoita vaihto arkeen sopivaan hiljaiseen hetkeen, esimerkiksi tiistai tai keskiviikko klo 18–22. Älä vaihda perjantaina, koska jos jokin menee ristiin, viikonlopun tuki ei aina ole saatavilla.

Kun lasket TTL:n ajoissa, teet todennuksen kuntoon ja pidät vanhan postin rinnalla, Google Workspace -vaihto onnistuu ilman katkoa.

MX, SPF, DKIM ja DMARC: Google Workspace -käyttöönotto ilman sähköpostikatkosta vaatii todennuksen kuntoon

MX-tietueet ohjaavat saapuvan postin. SPF, DKIM ja DMARC taas kertovat vastaanottajille, että viestit ovat aidosti sinun domainistasi, eikä niitä ole väärennetty. Kun nämä ovat pielessä, katkos ei näy vain “ei tule postia”, vaan myös niin, että lähtevä posti ei mene perille tai päätyy roskapostiin.

Turvallinen eteneminen on: lisää ensin Google Workspacen SPF mukaan nykyisen rinnalle, eli älä katkaise vanhaa lähetysreittiä heti. Käytännössä tämä tarkoittaa, että SPF-tekstiin lisätään Googlen include, mutta pidetään myös vanha palvelu mukana siirtymäajaksi. Sitten otetaan DKIM käyttöön Google Adminissa ja lisätään DKIM-tietue DNS:ään. DKIM on tyypillisesti se kohta, joka unohtuu, ja silloin DMARC alkaa raportoida ongelmia.

DMARC kannattaa ottaa käyttöön kahdessa vaiheessa. Aloita “p=none” (vain raportointi), jotta näet, mitä oikeasti tapahtuu, ja kiristä vasta myöhemmin “quarantine” tai “reject”. Googlen omat perusohjeet tietueille löytyvät suoraan lähteestä: Google Workspace DNS-asetukset.

Numeerinen havainnollistus riskistä: jos TTL on 14 400 sekuntia (4 h) ja vaihdat MX:n klo 18, osa lähettäjistä voi edelleen käyttää vanhaa MX:ää klo 22 asti. Jos vanha postilaatikko on suljettu klo 18, menetät viestejä. Jos vanha pysyy päällä yön yli, viestit eivät katoa, ne vain jakautuvat hetken kahteen paikkaan, joka on hallittavissa siirroilla.

Viestien siirrot ja varmistukset: näin vältät “postit katosi” -tilanteen

Kun MX vaihtuu, saat uutta postia Gmailiin, mutta vanhat viestit ovat yhä vanhassa järjestelmässä. Katkos syntyy usein siitä, että käyttäjät hyppäävät uuteen postiin, mutta tarvitsevat heti vanhoja ketjuja, tarjouksia ja liitteitä. Ratkaisu on siirtää data hallitusti ja varmistaa, että vanha ympäristö säilyy rinnalla siirtymän ajan.

Tee siirto vaiheittain: ensin avainkäyttäjät (myynti, asiakaspalvelu), sitten loput. Käytä joko Googlen migraatiotyökaluja tai IMAP-siirtoa, ja siirrä vähintään viimeiset 3–12 kuukautta “nopeana eränä”, jotta arki toimii heti. Loput voidaan ajaa taustalla.

Konkreettinen esimerkkilaskelma aikataulusta: jos yhdellä käyttäjällä on 12 GB postia ja realistinen siirtonopeus on 5–10 GB per tunti (riippuu palvelusta ja rajoituksista), 10 käyttäjän siirto voi viedä 12–24 tuntia taustalla. Siksi “kaikki kerralla” perjantai-iltana on riski, mutta porrastus toimii.

Varmistus ennen lopullista kytkentää: tee testilähetykset ulkopuolelta sisään ja sisältä ulos, tarkista että viestit eivät pomppaa, ja että ainakin yksi iso liite (esim. 10–20 MB) tulee perille. Lisäksi varmista, että jaetut osoitteet (info@, myynti@) ja mahdolliset ohjaukset on rakennettu valmiiksi. Jos sinulla on kysymyksiä oman domainin sähköpostin todennuksesta, katso myös: Sähköposti omalla domainilla: SPF, DKIM ja DMARC selkokielellä.

Katkoton vaihto käytännössä: rinnakkaisajo, valvonta ja palautussuunnitelma

Katkoton malli on käytännössä rinnakkaisajo. Pidät vanhan postipalvelun aktiivisena vähintään 3–7 päivää MX-vaihdon jälkeen, jotta viiveellä tulevat viestit eivät katoa. Samalla seuraat, mihin postia oikeasti päätyy, ja ajat tarvittaessa toisen “delta-siirron”, jolla haet viimeisetkin viestit vanhasta uuteen.

Tee palautussuunnitelma ennen ensimmäistäkään DNS-muutosta. Se voi olla niinkin yksinkertainen kuin: jos sisääntuleva posti ei tule 30 minuuttiin, palauta MX vanhaan, nosta TTL takaisin ja selvitä syy. Kun tämä on sovittu etukäteen, päätökset eivät veny, eikä katkos pitene.

Pieni case Helsingistä: 15 hengen yrityksellä vaihdettiin sähköposti Googleen niin, että TTL laskettiin 2 päivää ennen, DKIM ja DMARC laitettiin ensin raportointiin ja MX vaihdettiin keskiviikkona klo 19. Vanha palvelu pidettiin auki viikon, ja ajettiin delta-siirto seuraavana aamuna. Lopputulos oli 0 minuutin käyttökatko, mutta noin 2 tuntia “jakautunutta sisääntuloa”, joka ei näkynyt käyttäjille.

Kun kokonaisuus on valmis, dokumentoi asetukset ja omistajuudet. Tämä säästää hermoja seuraavassa muutoksessa, oli kyse sitten domainista tai verkkosivuprojektista. Jos samalla kehität yrityksen digiperustaa, tutustu myös palveluihimme: Etusivu, Verkkosivut, Kuinka Google Workspace voi tehostaa yrityksesi viestintää?, Miksi kannattaa ottaa yrityksen oma sähköposti?, Artikkelit ja Yhteystiedot.