Miten SPF, DKIM ja DMARC otetaan käyttöön Google Workspacessa – opas B2B-kylmäsähköpostin lähettäjälle

Jos yrityksesi aikoo lähettää kohdennettua B2B-kylmäsähköpostia, Gmail ja muut suuret vastaanottajapalvelimet vaativat, että lähettävä domain on todennettu SPF-, DKIM- ja DMARC-tietueilla – muuten viestit päätyvät roskapostiin tai hylätään kokonaan. Tämä opas käy läpi, miten SPF, DKIM ja DMARC otetaan käyttöön Google Workspacessa vaihe vaiheelta, kun tavoitteena on erillinen lähetysdomain kylmäsähköpostikampanjoille – ei pääasiallinen yritysposti. Lopussa on lista yleisimmistä virheistä, joita näemme asiakkaiden verkkotunnuksissa.

Miksi Gmail ja Workspace vaativat SPF-, DKIM- ja DMARC-tietueet

Google ja muut suuret sähköpostipalvelut arvioivat jokaisen saapuvan viestin lähettäjän mainetta ennen kuin päättävät, meneekö viesti saapuneisiin vai roskapostiin. SPF, DKIM ja DMARC ovat kolme DNS-tietuetta, jotka todistavat vastaanottajalle, että viesti todella tulee siltä domainilta, jolta se väittää tulevansa, eikä ole väärennetty. Ilman näitä tietueita Gmail kohtelee jokaista viestiä epäluotettavana lähteenä riippumatta siitä, kuinka hyvin viesti on kirjoitettu tai kuinka pieni lähetysmäärä on.

Kohdennetussa B2B-kylmäsähköpostissa lähetysmäärät ovat tyypillisesti pieniä – kymmeniä viestejä päivässä lähettäjää kohden – mutta se ei vapauta todennusvelvoitteesta. Päinvastoin: uusi tai vasta aktivoitu lähettäjätunnus ilman SPF-, DKIM- ja DMARC-tietueita on juuri se profiili, jota Gmailin suodattimet seuraavat tarkimmin. Siksi SPF, DKIM ja DMARC Google Workspacessa kuuluvat ensimmäisiin teknisiin askeliin ennen kuin yksikään kylmäviesti lähtee ulos.

Käytännön suositus on, ettei kylmäsähköpostia lähetetä pääverkkotunnuksesta (esim. yritys.fi), vaan erillisestä lähetysalidomainista, kuten outreach.yritys.fi tai contact.yritys.fi. Näin mahdolliset maineongelmat – tai varotoimena tehty jäähdytysjakso – eivät koske laskutus- tai asiakaspalveluviestejä, jotka kulkevat pääverkkotunnuksen kautta.

SPF-tietueen määritys Google Workspacessa vaihe vaiheelta

SPF (Sender Policy Framework) kertoo vastaanottavalle palvelimelle, mitkä palvelimet saavat lähettää sähköpostia domainisi nimissä. Google Workspacessa SPF-tietue lisätään DNS:ään TXT-tietueena – ei Workspacen admin-konsolissa, vaan verkkotunnuksen omassa DNS-hallinnassa.

• Kirjaudu domainin DNS-hallintaan ja avaa TXT-tietueiden muokkaus.
• Lisää tietue muotoon: v=spf1 include:_spf.google.com ~all (jos lähetät vain Workspacen kautta).
• Jos käytät myös muita työkaluja (kylmäsähköpostialusta, CRM, laskutusjärjestelmä), lisää niiden include-lausekkeet samaan tietueeseen – domainilla saa olla vain yksi SPF-tietue.
• Pidä DNS-lookupien määrä alle kymmenessä; jokainen include kuluttaa yhden, ja rajan ylitys mitätöi koko SPF-tietueen.
• Käytä ~all (soft fail) käyttöönoton alkuvaiheessa ja siirry -all (hard fail) -tilaan vasta, kun kaikki lähettävät palvelut on kartoitettu.
• Tarkista tietue esim. MXToolboxin SPF-tarkistimella ennen kuin aloitat lähetykset.

DKIM-avaimen käyttöönotto Gmailissa

DKIM (DomainKeys Identified Mail) allekirjoittaa jokaisen lähtevän viestin kryptografisesti, jolloin vastaanottaja voi varmistaa, ettei viestiä ole muutettu matkalla. Google Workspacessa DKIM-avaimen generointi tapahtuu admin-konsolissa, mutta julkinen avain pitää silti viedä DNS:ään itse.

• Avaa Google Workspacen Admin-konsoli → Apps → Google Workspace → Gmail → Todenna sähköposti (Authenticate email).
• Valitse lähettävä alidomain (esim. outreach.yritys.fi) ja generoi 2048-bittinen DKIM-avain – 1024-bittistä ei kannata enää käyttää.
• Kopioi Google Workspacen antama TXT-tietue (host-nimi tyyliin google._domainkey) domainin DNS-hallintaan.
• Odota DNS-propagointia ennen kuin painat "Aloita todennus" -painiketta admin-konsolissa.
• Tarkista, että DKIM-allekirjoitus näkyy lähtevän testiviestin otsikoissa (dkim=pass) Gmailin "Näytä alkuperäinen" -toiminnolla.

DMARC-tietueen luominen ja käytännön kiristäminen

DMARC (Domain-based Message Authentication, Reporting and Conformance) kertoo vastaanottajalle, mitä tehdä viestille, joka ei läpäise SPF- tai DKIM-tarkistusta, ja lähettää raportteja siitä, kuka domainisi nimissä lähettää postia. DMARC-tietue lisätään DNS:ään osoitteeseen _dmarc.yritys.fi TXT-tietueena, esimerkiksi: v=DMARC1; p=none; rua=mailto:dmarc-raportit@yritys.fi.

Käytäntöä ei kannata viedä suoraan p=reject-tilaan, vaikka kiire kylmäsähköpostikampanjan aloittamiseen olisi kova. Oikea polku on asteittainen: aloita p=none-tilasta, jossa kerätään vain raportteja ilman että mikään viesti hylätään, tarkista raporteista, ettei mikään laillinen lähde jää SPF/DKIM-tarkistuksen ulkopuolelle, ja nosta sitten pct-arvoa ja tiukkuutta vaiheittain.

Todennuksen vaikutus toimitettavuuteen käytännössä

Ero näkyy suoraan saapuvien kansiossa. Kun seuraamme asiakkaidemme lähetysdomainien saapumista ennen ja jälkeen täyden SPF-, DKIM- ja DMARC-käyttöönoton, inbox-sijoitusprosentti nousee tyypillisesti selvästi – etenkin kun domain on uusi ja lämmitysvaiheessa.

Huomionarvoista on, että pelkkä SPF ilman DKIM:iä auttaa vain osittain – DMARC-tarkistus edellyttää, että vähintään toinen SPF:stä tai DKIM:stä on kohdistettu (aligned) lähettävän domainin kanssa, ja moni lähetysalusta rikkoo SPF-kohdistuksen välittäessään viestiä oman palvelimensa kautta.

Yleisimmät virheet SPF-, DKIM- ja DMARC-käyttöönotossa

Käymme viikoittain läpi asiakkaiden DNS-asetuksia ennen kylmäsähköpostikampanjan käynnistystä, ja samat virheet toistuvat.

• Domainilla on kaksi erillistä SPF-tietuetta yhden sijaan – DNS-standardin mukaan vain yksi sallitaan, ja kaksi tekee molemmista pätemättömiä.
• DMARC viedään suoraan p=reject-tilaan ilman raportointivaihetta, jolloin laillisiakin viestejä alkaa kadota huomaamatta.
• DKIM-avain jää generoimatta lähetysalidomainille, vaikka lähetykset tehdään sen kautta – pääverkkotunnuksen DKIM ei kata alidomainia automaattisesti.
• Kylmäsähköpostit lähetetään suoraan pääverkkotunnuksesta ilman erillistä alidomainia, jolloin maineriski kohdistuu koko yrityksen sähköpostiliikenteeseen.
• rua-raportointiosoitetta ei seurata koskaan käyttöönoton jälkeen, jolloin väärinkonfiguroitu palvelu huomataan vasta kun toimitettavuus on jo romahtanut.

Checklist ennen ensimmäistä kylmäsähköpostierää

LDM:n kampanjoissa jokainen uusi lähetysdomain käy läpi saman tarkistuslistan ennen ensimmäistä viestierää, riippumatta siitä, ajaako lähetystä oma tiimi vai me.

• SPF-tietue on validi, sisältää kaikki todelliset lähettäjät ja pysyy alle kymmenen DNS-lookupin rajan.
• DKIM on käytössä 2048-bittisellä avaimella lähetysalidomainille, ei vain pääverkkotunnukselle.
• DMARC on p=none-tilassa vähintään viikon ajan raportteja seuraten ennen kiristämistä.
• Lähetysdomain on erillinen alidomain, ei laskutus- tai tukiviestien domain.
• Lämmitysjakso on ajettu ennen täyttä lähetysmäärää, jotta maine ehtii rakentua todennuksen rinnalla.

Usein kysytyt kysymykset