Sähköposti omalla domainilla: SPF, DKIM ja DMARC selkokielellä – näin varmistat, että viestit menevät perille

Sähköposti omalla domainilla: SPF, DKIM ja DMARC selkokielellä tarkoittaa käytännössä kolmea “todistetta”, joilla osoitat vastaanottajalle, että viesti on oikeasti yritykseltäsi eikä huijaus. Kun nämä ovat kunnossa, viestit menevät todennäköisemmin perille, roskapostisuodattimet rauhoittuvat ja brändisi näyttää ammattimaiselta jokaisessa lähetyksessä.

Sähköposti omalla domainilla: SPF, DKIM ja DMARC selkokielellä, mitä ne tekevät ja miksi sillä on väliä

Kun lähetät sähköpostia omasta verkkotunnuksesta (esim. [email protected]), vastaanottajan järjestelmä tarkistaa, onko lähettäminen “sallittua” ja onko viestiä muutettu matkalla. Tässä SPF, DKIM ja DMARC ovat se peruskolmikko, joka ratkaisee usein 80 % toimitusvarmuusongelmista.

SPF kertoo, mitkä palvelimet saavat lähettää sähköpostia domainistasi. DKIM lisää viestiin kryptografisen allekirjoituksen, joka varmistaa, ettei sisältöä ole muokattu. DMARC taas on sääntökirja, joka kertoo vastaanottajalle, mitä tehdä, jos SPF tai DKIM ei täsmää, ja mihin raportit mahdollisista väärinkäytöksistä lähetetään.

Jos nämä puuttuvat tai ovat ristiriidassa, tyypillinen seuraus on, että viestit päätyvät roskapostiin, toimitus viivästyy tai pahimmillaan viesti hylätään kokonaan. Google tiukensi vaatimuksiaan erityisesti massalähettäjille, ja käytännössä DMARC:in järkevä käyttöönotto on nyt monelle pk-yrityksellekin “pakollinen vakuutus”. Lisätaustaa löytyy Googlen ohjeesta SPF, DKIM ja DMARC Google Workspacessa.

Kun SPF, DKIM ja DMARC ovat kunnossa, sähköpostisi näyttää vastaanottajalle luotettavalta, ja se näkyy suoraan siinä, moniko viesti oikeasti luetaan.

SPF, DKIM ja DMARC: yleisimmät syyt, miksi viestisi menevät roskapostiin

Yleisin kompastuskivi on se, että sähköposti lähtee useasta paikasta, mutta SPF:ssä on sallittu vain yksi. Esimerkiksi Google Workspace hoitaa henkilökunnan postit, mutta uutiskirje lähtee erillisestä työkalusta ja laskutusjärjestelmä vielä kolmannesta. Jos näitä ei ole lisätty SPF:ään ja DKIM:ään oikein, osa viesteistä näyttää vastaanottajalle epäilyttävältä.

Toinen yleinen virhe on “liian tiukka” tai keskeneräinen DMARC. Jos asetat DMARC-politiikaksi suoraan reject, mutta DKIM ei ole käytössä tai lähettäjiä ei ole kartoitettu, voit aiheuttaa itsellesi oikean toimituskatkon. Turvallinen eteneminen on yleensä monitorointi ensin, sen jälkeen kiristäminen vaiheittain.

Kolmas kipupiste on DNS:n ristiriidat: päällekkäiset SPF-tietueet, vanhat DKIM-avaimet tai väärään paikkaan lisätyt TXT-tietueet. Pieneltä näyttävä kirjoitusvirhe voi riittää siihen, että allekirjoitus ei täsmää. Jos sinulla on jo yrityssähköposti, kannattaa lukea myös miksi kannattaa ottaa yrityksen oma sähköposti ja varmistaa, että pohja on kunnossa.

Sähköposti omalla domainilla: SPF, DKIM ja DMARC selkokielellä, näin otat ne käyttöön ilman arvailua

Nopein tapa onnistua on tehdä ensin lähettäjäkartoitus: mistä järjestelmistä sähköpostia lähtee domainistasi viimeisen 30 päivän aikana? Tyypillisesti listalla on Google Workspace, verkkosivuston lomakkeet, uutiskirjetyökalu ja mahdollinen CRM. Kun tiedät lähteet, SPF:ään lisätään vain tarvittavat lähettäjät, ja kaikille keskeisille lähteille otetaan DKIM käyttöön, jos se on mahdollista.

Konkreettinen esimerkkilaskelma: jos yritykseltäsi lähtee keskimäärin 25 tarjousta päivässä ja 10 % putoaa roskapostiin, se on 2–3 tarjousta/päivä “piilossa”. Kuukaudessa se on noin 50–75 viestiä. Jos yksikin niistä olisi johtanut 1 500 euron kauppaan, puhutaan jo 1 500–3 000 euron vaikutuksesta, ilman että myynti tekee mitään eri tavalla. Toimitusvarmuus ei ole nippelitietoa, se on suoraa liikevaihtoa.

Käytännön eteneminen DMARC:issa on usein tämä: aloita politiikalla p=none ja kerää raportit omaan osoitteeseen, sen jälkeen siirry p=quarantine, ja vasta kun raportit näyttävät puhdasta, harkitse p=reject. DMARC-raportit auttavat näkemään, yrittääkö joku lähettää viestejä domainisi nimissä. DMARC:n perusperiaatteista on hyvä viranomais-/standarditausta DMARC.orgin koonnissa DMARC.

Jos verkkotunnus on vielä hankkimatta tai epäselvä, aloita tästä: Minkälainen domain hankkia yritykselle? Hyvä domain ja siisti DNS tekevät koko paketista helpomman.

Google Workspace -käyttöönotto Helsingissä, kun haluat sähköpostin toimivan heti (DigiSilta-malli)

Jos haluat välttää sen, että sähköposti on viikon “sinne päin”, DigiSilta Oy hoitaa Google Workspace -käyttöönoton Helsingissä niin, että SPF, DKIM ja DMARC rakennetaan samalla kerralla oikein. Toimitusvarmuus varmistetaan käytännön testein, ei pelkillä oletuksilla.

Tyypillinen toteutus etenee niin, että perustamme käyttäjät ja osoitteet (esim. myynti@, laskutus@), teemme DNS-muutokset hallitusti, otamme DKIM-allekirjoituksen käyttöön ja asetamme DMARC:n vaiheittain. Tarvittaessa siirrämme vanhat postit ja varmistamme, että verkkosivun yhteydenottolomakkeet lähettävät viestit “oikealla tavalla” (etenkin jos WordPress on käytössä). Verkkosivujen perusasioista saat hyötyä myös tästä: Verkkosivut.

Case-esimerkki arjesta: helsinkiläinen palveluyritys huomasi, että osa tarjouspyynnöistä jäi vastaamatta, koska myyjän vastaukset menivät asiakkaan roskapostiin. Kun SPF korjattiin yhden lähettäjän osalta, DKIM otettiin käyttöön ja DMARC asetettiin monitorointiin, roskapostiin putoaminen väheni selvästi ja myynti näki vaikutuksen jo ensimmäisen viikon aikana. Kun toimitusvarmuus on kunnossa, voit keskittyä sisältöön ja myyntiin. Jos haluat ymmärtää koko työkalupakin hyödyt, katso myös kuinka Google Workspace tehostaa viestintää.

Kun tarvitset kumppanin, joka tekee tämän kerralla oikein, löydät meidät osoitteesta DigiSilta Oy, Alvar Aallon katu 5b Lt 1, 00100 Helsinki. Kurkkaa myös yhteystiedot tai palaa myöhemmin lukemaan lisää aiheista: artikkelit.