--- title: "Salattu sähköposti pk-yritykselle. TLS ja end-to-end 2026" url: https://resahost.net/oppaat/salattu-sahkoposti-pk-yritys-tls-e2e/ canonical: https://resahost.net/oppaat/salattu-sahkoposti-pk-yritys-tls-e2e/ language: fi description: "TLS, MTA-STS ja end-to-end -salaus pk-yrittäjälle: mikä on pakollinen, mikä riittävä ja mikä tarpeen vain tietyillä toimialoilla. Suositukset Suomeen 2026." author: "Olli Junes" author_url: https://resahost.net/tiimi/olli-junes/ datePublished: 2026-05-27 dateModified: 2026-08-27 related: - "Sähköposti Yrityssähköposti omalla domainilla: seitsemän vaiheen opas pk-yrittäjälle Lue opas → — https://resahost.net/oppaat/yrityssahkoposti-luominen-opas/" - "Sähköposti Suojattu sähköposti: SPF, DKIM ja DMARC — pk-yrityksen opas Lue opas → — https://resahost.net/oppaat/suojattu-sahkoposti-spf-dkim-dmarc-opas/" - "Sähköposti Yrityssähköposti omalla domainilla: @yritys.fi vs @gmail.com Lue opas → — https://resahost.net/oppaat/yrityssahkoposti-vs-gmail/" --- Sähköposti 8 min lukuaika · Päivitetty 08/2026 # Salattu sähköposti pk-yritykselle. TLS ja end-to-end 2026 TLS, MTA-STS ja end-to-end -salaus pk-yrittäjälle: mikä on pakollinen, mikä riittävä ja mikä tarpeen vain tietyillä toimialoilla. Suositukset Suomeen 2026. Lyhyesti - TLS suojaa viestin matkalla palvelimelta toiselle mutta ei postilaatikon sisältöä levyllä: tietomurrossa hyökkääjä saa selkokielisen arkiston käsiinsä. - MTA-STS sulkee downgrade-aukon jossa hyökkääjä voi pakottaa palvelimet putoamaan salaamattomaan yhteyteen: silti 99,7 prosentilla suomalaisista domaineista se puuttuu. - End-to-end -salaus on perusteltu asianajajille, tilitoimistoille ja terveydenhuollolle, mutta valtaosalle pk-yrityksistä TLS plus SPF-, DKIM-, DMARC- ja MTA-STS-pohja riittää. - GDPR:n 34 artikla suosii salausta: E2E-salatun postilaatikon vuoto on Tietosuojavaltuutetulle huomattavasti pienempi tapaus kuin selkokielisen. 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. [PowerDMARCin heinäkuun 2026 raportissa](https://powerdmarc.com/finland-dmarc-adoption-report/) **98,5 prosentilla tutkituista suomalaisista domaineista ei ollut toimivaa MTA-STS-käytäntöä**. 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](https://resahost.net/oppaat/ddos-dmarc-suomalaisen-pk-yrityksen-aukot/): 21,3 prosenttia suomalaisista domaineista on kokonaan ilman DMARC:ia ja yli 60 prosenttia ei voi todistaa, että niiden nimissä 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](https://resahost.net/oppaat/ddos-dmarc-suomalaisen-pk-yrityksen-aukot/) 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](https://resahost.net/yhteystiedot/) 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. Verkkosivusi kunnossa. Aina. Hosting, domain, sähköposti ja tietoturva yhdellä sopimuksella — alkaen 69 €/kk (alv. 0 %). Tilaa hosting ## Usein kysyttyä ## Suojaako TLS-salaus sähköpostin niin hyvin ettei muuta tarvita? TLS suojaa viestin siirron matkalla palvelimelta toiselle. Se ei suojaa viestin sisältöä palvelimella tallennettuna eikä estä palvelimen ylläpitäjää lukemasta viestiä. Käytännössä Microsoft ja Google eivät lue yksityisposteja, mutta tietomurron sattuessa hyökkääjä saa selkokielisen postilaatikon. Jos viestit sisältävät erityisiä henkilötietoja tai kaupallisia salaisuuksia, TLS yhteen MTA-STS:n kanssa on pohja, mutta ei riittävä taso. ## Onko end-to-end -salaus mahdollista ilman että kaikilla osapuolilla on erillinen ohjelma? Käytännöllisin tapa on suojattu portaaliratkaisu: lähettäjä kirjoittaa viestin portaaliin, vastaanottaja saa sähköpostilinkin ja kirjautuu portaaliin lukemaan viestin selaimella ilman erillistä asennusta. Tämä on yleinen tapa tilitoimistoilla ja asianajajilla, kun viestitään yksityishenkilöiden kanssa jotka eivät ole valmiita asentamaan Thunderbirdia tai PGP-laajennusta. ## Pitääkö kaikkien pk-yritysten ottaa MTA-STS käyttöön? Se on suositeltavaa kaikille toimijoille joiden sähköpostiviestintä on liiketoiminnalle kriittistä. MTA-STS sulkee niin sanotun downgrade-aukon, jossa hyökkääjä voi pakottaa palvelimet putoamaan selkokieliseen viestinvälitykseen vaikka molemmilla osapuolilla olisi TLS tuettuna. Käyttöönotto on kertaluonteinen, kustannus on nolla ja vaatii kolme palaa: HTTPS-policy-tiedoston, TXT-tietueen ja ajantasaiset MX-tietueet. ![Olli Junes](https://resahost.net/assets/team/ollijunes.webp) Kirjoittaja Olli Junes perustaja ja toimitusjohtaja, ResaHost · Rovaniemellä 27.5.2026 @resacolli LinkedIn **Ylläpito omalle toimialallesi** - [Terveyspalvelut](https://resahost.net/toimialat/terveyspalvelut/) - [Tilitoimistot](https://resahost.net/toimialat/tilitoimistot/) ## Lue seuraavaksi Sähköposti ### Yrityssähköposti omalla domainilla: seitsemän vaiheen opas pk-yrittäjälle Lue opas → Sähköposti ### Suojattu sähköposti: SPF, DKIM ja DMARC — pk-yrityksen opas Lue opas → Sähköposti ### Yrityssähköposti omalla domainilla: @yritys.fi vs @gmail.com Lue opas →