Salattu sähköposti pk-yritykselle: mitä TLS ja end-to-end tarkoittavat 2026

Sähköpostin salauksesta puhutaan usein niin että sekoittuu kolme eri asiaa: liikenteen salaus matkalla, viestin salaus päästä päähän ja tallennetun postilaatikon salaus levyllä. Nämä eivät korvaa toisiaan, ne ratkaisevat eri ongelmia. Pk-yrittäjälle ero on käytännöllinen: yksi näistä on vakioasetus, toinen vaatii kymmenen minuutin DNS-työn ja kolmas on tarpeen vain osalla toimialoja. Käydään läpi mikä on mikä, ja mitä Suomen tilanne 2026 vaatii.

Kolme tasoa, eivät vaihtoehtoja

Sähköpostin matka kulkee kolmen vyöhykkeen läpi: lähettäjän koneelta lähettävälle palvelimelle, palvelimelta vastaanottavalle palvelimelle ja vastaanottajan koneelle. Lisäksi viesti tallentuu molempiin postilaatikoihin. Jokaisella vyöhykkeellä on oma salauksen tyyppinsä.

Transport-tason TLS salaa liikenteen palvelimien välillä. End-to-end -salaus salaa viestin sisällön niin, että edes palveluntarjoaja ei näe sitä. At-rest-salaus salaa tallennetun postilaatikon levyllä. Pk-yritykselle nämä ovat eri vaivan ja eri hyödyn tasoja.

Transport-tason TLS: vakio jonka kanssa on yksi tärkeä mutta

Miten TLS toimii sähköpostissa

Kun sähköpostipalvelimesi lähettää viestin vastaanottajan palvelimelle, ne kättelevät STARTTLS-komennolla. Jos molemmat tukevat TLS-salausta, viesti kulkee salattuna. Jos jompikumpi ei tue, viesti kulkee selkokielisenä. Tätä kutsutaan opportunistiseksi salaukseksi: yritetään, mutta tyydytään huonompaan jos pakko.

Vuonna 2026 suuret pilvipalvelut (Microsoft 365, Google Workspace, Zoho Mail) käyttävät TLS:ää automaattisesti. Ongelma ei ole se etteikö TLS olisi käytössä — ongelma on että hyökkääjä voi pakottaa palvelimet putoamaan takaisin selkokieleen niin sanotulla downgrade-hyökkäyksellä. Reitin varrella oleva taho voi muokata STARTTLS-vastausta niin että näyttää siltä että vastapuoli ei tukekaan TLS:ää, ja palvelin lähettää viestin selvänä.

MTA-STS pakottaa TLS:n päälle

MTA-STS (Mail Transfer Agent Strict Transport Security) on DNS:ään ja HTTPS-policyyn perustuva mekanismi, joka kertoo lähettäville palvelimille: "minun domainilleni tulee aina käyttää TLS:ää, jos ei onnistu, älkää lähettäkö viestiä selkokielisenä, pudottakaa viesti tai kokeilkaa myöhemmin." Tämä sulkee downgrade-aukon.

Käyttöönotto vaatii kolme palaa: HTTPS-policy-tiedoston mta-sts.domain.fi-aliasin alla, TXT-tietueen joka kertoo policyn versiosta ja MX-tietueet sertifikaateilla, jotka vastaavat policyä. Kun pala on paikallaan, se on paikallaan.

Suomessa MTA-STS on edelleen marginaalinen. PowerDMARC:n helmikuun 2024 otoksessa 715 suomalaisesta domainista 99,72 prosentilla ei ollut MTA-STS-tietuetta. Globaalisti käyttöönotto on muutamissa prosenteissa, ja Suomi seuraa samaa rytmiä. Tämä tarkoittaa että käytännössä mikään suomalainen pk-yritys ei ole sulkenut downgrade-aukkoaan, vaikka konfiguraatio on kertaluonteinen ja kustannukset nolla.

Mihin TLS riittää ja mihin ei

Transport-tason TLS riittää valtaosaan pk-yrityksen viestinnästä. Asiakaspalvelu, tarjouspyynnöt, tilausvahvistukset, sisäinen viestintä — näissä TLS plus MTA-STS plus SPF, DKIM ja DMARC muodostavat tason joka kestää realistiset uhkat.

Mihin TLS ei riitä: sähköpostipalvelimen ylläpitäjä näkee viestin sisällön. Pilvipalvelussa tämä tarkoittaa että Microsoft tai Google teknisesti voivat lukea postilaatikkosi. Käytännössä eivät lue, mutta voivat. Jos palvelimelle tehdään tietomurto, hyökkääjä saa selkokielisen sisällön käsiinsä. TLS suojaa matkalta, ei pysäkiltä.

End-to-end -salaus: viesti vain vastaanottajan avaimella

Mitä E2E tarkoittaa

End-to-end -salauksessa viesti salataan lähettäjän koneella vastaanottajan julkisella avaimella. Se kulkee palvelinten läpi salattuna mössönä ja avautuu vasta vastaanottajan koneella tämän yksityisellä avaimella. Sähköpostipalvelin näkee otsikkokentät (lähettäjä, vastaanottaja, aihe) mutta ei viestin sisältöä.

Käytännön toteutukset jakautuvat kolmeen perheeseen. S/MIME käyttää X.509-varmenteita ja on integroitu Outlookiin, Apple Mailiin ja moneen yritysjärjestelmään. OpenPGP käyttää hajautettua avainjakelua ja on suosittu yksittäisten asiantuntijoiden parissa. Suljetut palvelut kuten Proton Mail ja Tutanota hoitavat E2E:n automaattisesti omien käyttäjiensä välillä ja tarjoavat suojatun verkkolinkin ulkopuolisille vastaanottajille.

Miksi E2E ei ole pk-yrityksen oletus

E2E vaatii avainhallintaa. Jokaisella vastaanottajalla pitää olla julkinen avain, joka on jaettu turvallisesti, ja yksityinen avain pitää varmuuskopioida niin ettei se katoa työsuhteen päättyessä tai laitevaihdossa. S/MIME-varmenteet maksavat tyypillisesti 20–80 euroa per käyttäjä vuodessa. PGP on ilmainen mutta vaatii käyttäjältä teknistä ymmärrystä.

Lisäksi vastaanottajan pitää tukea samaa standardia. Jos asiakas käyttää tavallista Gmailia ilman S/MIME-laajennusta, hän ei voi lukea S/MIME-salattua viestiä. Tämä rajoittaa E2E:n käytön kumppaneihin, jotka ovat sopineet tekniikasta etukäteen, tai portaaliratkaisuihin, joissa viesti haetaan selaimen kautta erillisellä salasanalla.

Toimialat joilla E2E on perusteltu

Pk-yritykselle E2E (tai sitä vastaava suojattu viestintäportaali) on tarpeen kun viestintä koskee GDPR:n erityisiä henkilötietoryhmiä tai liike-elämän kriittisiä salaisuuksia. Kolme käytännön esimerkkiä:

Asianajaja ja lakitoimisto. Asianajajien laissa säädetty vaitiolovelvollisuus ei jousta sähköpostin tekniikan mukaan. Rikosjuttuihin, vahingonkorvausriitoihin, perheoikeudellisiin asioihin ja yrityskauppoihin liittyvä aineisto on sellaista jonka vuoto voi tuhota asiakkaan asian. Käytännössä suomalaiset asianajotoimistot käyttävät joko S/MIME:ä isompien yritysten kanssa tai portaaliratkaisua yksityishenkilöille.

Tilintarkastaja ja tilitoimisto. Palkkatiedot, henkilötunnukset, pankkitilinumerot ja verotustiedot vaativat enemmän kuin TLS:n. Sama koskee yrityskauppojen luottamuksellista aineistoa. Tilitoimiston tyypillinen ratkaisu on suojattu portaali, johon asiakas kirjautuu vahvalla tunnistautumisella. Sähköpostissa kulkee vain ilmoitus että aineistoa odottaa.

Tilitoimistolle E2E:n hyöty on myös vastuukysymys: jos asiakkaan palkkatiedot vuotavat selkokielisestä postilaatikosta, kirjanpitäjä joutuu selvittämään asian Tietosuojavaltuutetulle. Salatun portaalin kautta kulkenut aineisto on huomattavasti pienempi tapaus. Sama logiikka pätee BEC-huijauksiin: kun palkkalaskelmaa ei lähetetä koskaan sähköpostin liitteenä vaan portaalilinkin kautta, väärennetyllä lähettäjäosoitteella tehty pyyntö "lähetä se vielä tämä versio osoitteeseen X" ei toimi prosessin sisällä.

Hammaslääkäri ja muu pieni terveydenhuolto. Potilastiedot ovat GDPR:n 9 artiklan erityisiä henkilötietoja. Tietosuojavaltuutetun linjauksen mukaan tavallista sähköpostia ei saa käyttää terveystietojen lähettämiseen ilman lisäsuojausta. Suomessa pääosa potilasviestinnästä menee Kanta-palvelujen tai ammattilaisjärjestelmien kautta, mutta jos sähköpostia käytetään, sen pitää olla joko E2E-salattu tai kulkea suojatun portaalin läpi.

Useimmilla muilla toimialoilla — putkiliike, ravintola, verkkokauppa, konsulttitalo — TLS riittää valtaosaan viestinnästä. E2E:n käyttöönotto vain tuntumalta "varmuuden vuoksi" lisää käyttäjien turhautumista, koska arkinen viestintä ei toimi enää vastaanottajan päässä ilman lisäpalikoita.

At-rest-salaus: postilaatikon levy

Kolmas taso on tallennetun postilaatikon salaus. Microsoft 365, Google Workspace ja muut isot palvelut salaavat postilaatikot levytasolla. Tämä suojaa konkreettiselta laitevarkaudelta datakeskuksessa, mutta ei suojaa palvelimen ylläpitäjältä eikä murtautujalta, joka pääsee kirjautuneeseen tiliin sisään.

Pk-yrityksen kannalta at-rest-salaus on pilvipalvelujen oletus, johon ei tarvitse erikseen ottaa kantaa. Oma sähköpostipalvelin vaatii levyosioiden salauksen konfiguroinnin (LUKS tai vastaava), mikä on perustyö palvelinhallinnoijalle eikä vaadi käyttäjältä mitään.

Pakollinen pohja 2026

Pk-yrityksen sähköpostin tietoturvan pohja koostuu viidestä DNS-tietueesta ja yhdestä periaatteesta:

1. SPF kertoo mistä IP-osoitteista viestisi saavat tulla.
2. DKIM allekirjoittaa lähtevät viestit kryptografisesti.
3. DMARC politiikalla p=reject hylkää huijausviestit ennen perille tuloa.
4. MTA-STS pakottaa TLS:n päälle ja sulkee downgrade-aukon.
5. DNSSEC estää DNS-vastausten väärentämisen.

Yksikään näistä ei maksa lisenssimaksua. Yhden kunnollisesti konfiguroidun iltapäivän työ, ja domainisi on samalla tasolla suomalaisten suurten toimijoiden kanssa. Ilman näitä olet PowerDMARC:n raportin karuissa luvuissa: 54 prosenttia suomalaisista domaineista on kokonaan ilman DMARC:ia ja noin kaksi kolmesta ei voi todistaa että nimissään lähetetty viesti on aito.

GDPR ja salauksen vaikutus tietoturvaloukkauksen ilmoitusvelvollisuuteen

GDPR:n 32 artikla edellyttää "asianmukaisia teknisiä ja organisatorisia toimenpiteitä" henkilötietojen suojaamiseksi ja mainitsee salauksen esimerkkinä. 34 artikla puolestaan rajaa milloin rekisteröidyille pitää ilmoittaa tietoturvaloukkauksesta. Jos vuotanut aineisto on ollut vahvasti salattua eivätkä avaimet ole vaarantuneet, rekisteröidyille ei välttämättä tarvitse ilmoittaa.

Käytännössä tämä tarkoittaa että E2E-salatun postilaatikon vuoto on Tietosuojavaltuutetun toimistolle huomattavasti pienempi tapaus kuin selväkielisen postilaatikon vuoto. Selkokielinen aineisto johtaa lähes aina 72 tunnin sisällä tehtävään viranomaisilmoitukseen ja usein myös rekisteröidyille ilmoittamiseen, mikä on sekä työlästä että maine-ongelma. Salaus vähentää sekä todennäköisyyttä että vaikutusta.

Tietosuojavaltuutetun ohjeessa "Sähköpostin käyttö henkilötietojen käsittelyssä" linja on selkeä: tavallinen TLS-suojattu sähköposti voi riittää vähäriskisille henkilötiedoille, mutta erityisiin henkilötietoryhmiin tarvitaan lisäsuoja — joko salatut liitteet eri kanavalla toimitetulla salasanalla tai vahvempi viestintäkanava.

Käytännön toimintamalli pk-yritykselle

Kolme tasoa, joista jokaisen pitää olla paikallaan ennen seuraavaa.

Vähimmäistaso (kaikki pk-yritykset). Pilvipalvelu (Microsoft 365 tai Google Workspace), SPF, DKIM, DMARC p=reject, MTA-STS, DNSSEC. Työntekijöille ohje siitä missä tilanteissa arkaluonteista tietoa ei lähetetä sähköpostin runkona. Tämä on lähtötaso, ei tavoitetaso.

Korotettu taso (tilitoimisto, asianajaja, konsultti joka käsittelee yrityskauppoja). Edellisten lisäksi suojattu viestintäportaali tai S/MIME niiden asiakkaiden kanssa, jotka sitä tukevat. Prosessi jossa luottamuksellinen sisältö ei koskaan kulje sähköpostin runkona — viesti sisältää vain ilmoituksen ja linkin portaaliin.

Korkea taso (terveydenhuolto, vesi- ja energiasektori). E2E tai portaaliratkaisu oletuksena kaikkeen asiakas- ja potilasviestintään. Salausta käytetään myös argumenttina GDPR 32 ja 34 artiklojen mukaisessa riskianalyysissä.

Yleisimmät virheet käyttöönotossa

Salatun sähköpostin käyttöönotossa toistuu kolme virhetilannetta, jotka tekevät tyhjäksi alkuperäisen hyödyn.

DMARC jätetään tilaan p=none pysyvästi. Tämä asetus kerää raportteja mutta päästää huijausviestit perille. Moni pk-yritys ottaa p=none:n käyttöön valvontatilana ja unohtaa nostaa sen p=reject-tasolle parin viikon kuluttua. Lopputulos on DMARC paperilla mutta ei suojaa käytännössä. DDoS- ja DMARC-katsauksessa käytiin läpi miksi tämä siirtymä on koko DMARC-työn ydin.

MTA-STS-policy jätetään testiläntilaan. Policy-tiedostossa on kolme tilaa: none, testing ja enforce. Testiläntilassa lähettävät palvelimet raportoivat ongelmista mutta toimittavat viestit edelleen ilman pakotusta. Käyttöönotossa testiläntila on perusteltu pari viikkoa, mutta sen pitää siirtyä enforce-tilaan että suoja toimii. Käytännössä useimmat MTA-STS-konfiguraatiot jäävät testitilaan pysyvästi.

S/MIME-varmenteen yksityinen avain katoaa työsuhteen päättyessä. Kun käyttäjä lähtee yrityksestä ja kone palautetaan, kaikki kyseisellä avaimella E2E-salatut vanhat viestit muuttuvat luettavaksi kelpaamattomaksi datapöinöksi. Tämä on hyväksyttävä lopputulos jos viestit eivät ole tarpeen tulevaisuudessa, mutta kirjanpitolain mukaan tietyt aineistot pitää säilyttää kuusi tai kymmenen vuotta. Yritys tarvitsee avainten varmuuskopiointiprosessin (key escrow), jossa yksityiset avaimet säilytetään keskitetysti niin, että ne ovat palautettavissa työsuhteen päättyessäkin.

Yhden palveluntarjoajan etu

Sähköpostin salaus kaatuu harvoin teknologiaan. Se kaatuu siihen että hosting-paketti, DNS-paneeli ja sähköpostipalvelu ovat eri toimittajilla, ja kukaan ei ole vastuussa kokonaisuudesta. DMARC-tietue on DNS-paneelissa, MX-tietue toisessa, MTA-STS-policy pitäisi olla kolmannen kautta, ja muutosta tehtäessä yksi rikkoutuu kun toista korjataan.

Resahost-paketissa SPF, DKIM, DMARC p=reject, MTA-STS ja DNSSEC konfiguroidaan kerralla saman katon alla ennen kuin domain otetaan käyttöön. Yhden domainin osalta tämä on pari tuntia työtä, ja sen jälkeen se on tehty. Jos sinulla on tarvetta E2E-tason ratkaisuihin, autamme kartoittamaan sopivan portaalin tai S/MIME-konfiguraation toimialasi vaatimusten mukaan.

Jos haluat tarkistaa nykyisen tilanteen ennen kuin teet päätöksiä, audit on maksuton ja kestää alle vuorokauden. Saat raportin jossa näkyy SPF-, DKIM-, DMARC-, MTA-STS- ja DNSSEC-tilanne sekä arvio siitä, riittääkö nykyinen taso toimialasi viestintään vai tarvitaanko E2E-kerros tiettyihin käyttötapauksiin. Raportti on selkokielinen, ja jokaisesta löydöstä mainitaan joko korjausohje tai arvio korjauksen kestosta.