SPF, DKIM ja DMARC: miten sähköpostin suojaus toimii?

Yritykseltä lähtee postia usein monesta paikasta: henkilöstön postilaatikoista, laskutusohjelmasta, verkkokaupasta ja uutiskirjepalvelusta. Jokainen niistä pitää ottaa huomioon, kun asetuksia tehdään. Nykytilan näette ilmaisella sähköpostiturvan tarkistuksella.

SPF: saako tämä palvelin lähettää?

SPF on DNS-tietue, joka luettelee palvelimet, jotka saavat lähettää postia yrityksen puolesta. Vastaanottaja vertaa lähettävän palvelimen osoitetta tähän luetteloon. SPF tarkistaa kuitenkin teknisen lähettäjäosoitteen, ei sitä From-osoitetta, jonka vastaanottaja näkee. Siksi SPF ei yksin estä väärennöksiä.

Kaksi virhettä toistuu usein. Ensimmäinen: jokaiselle uudelle palvelulle lisätään oma SPF-tietue, vaikka niitä saa olla vain yksi. Toinen: tietueeseen kertyy liikaa viittauksia muihin palveluihin (include). SPF sallii enintään kymmenen nimipalveluhakua, ja rajan ylittyessä tarkistus epäonnistuu. Myös postin edelleenlähetys toisen palvelimen kautta voi rikkoa SPF-tuloksen.

Esimerkki: jos kuviteltu Esimerkki Oy käyttää Microsoft 365:tä ja laskutuspalvelua, molemmat tulevat samaan tietueeseen: v=spf1 include:spf.protection.outlook.com include:spf.laskutus.example ~all.

Tietue päättyy yleensä joko ~all (muut palvelimet merkitään epäilyttäviksi) tai -all (muut palvelimet hylätään). Kun DMARC on käytössä, ~all on yleinen ja suositeltu valinta. Sähköpostialan järjestö M3AAWG suosittaa sitä vuoden 2020 ohjeessaan, jonka mukaan vastaanottajan ei pidä hylätä viestiä SPF:n perusteella ennen DMARC-tarkistusta. Näin edelleenlähetetty aito viesti ei kaadu pelkkään SPF:ään. Microsoft 365 -käyttäjille Kyberturvallisuuskeskus on Direct Send -kalastelun vuoksi suositellut tiukempaa linjaa, jossa myös SPF hylkää (-all). Verkkotunnukselle, joka ei lähetä postia lainkaan, julkaistaan v=spf1 -all ja DMARC-käytäntö p=reject. Silloin myös käyttämättömät ja varatut verkkotunnukset on suojattu väärentämiseltä.

DKIM: onko viesti allekirjoitettu?

Lähettävä palvelu allekirjoittaa jokaisen viestin yksityisellä avaimella. Vastaanottaja hakee nimipalvelusta vastaavan julkisen avaimen ja tarkistaa, että allekirjoitus täsmää. Jos viestiä on muutettu matkalla, tarkistus epäonnistuu.

Allekirjoitus osoittaa, että viesti tuli palvelusta, jolla on verkkotunnuksen avain. DMARCin kannalta allekirjoituksen pitää olla teidän verkkotunnuksellanne. Moni palvelu allekirjoittaa viestit oletuksena omalla verkkotunnuksellaan, eikä sellainen allekirjoitus auta DMARCia. Se ei kerro, onko sisältö turvallinen tai kuka viestin kirjoitti. Jokaisella lähettävällä palvelulla kannattaa olla oma avain (selektori). Avain haetaan viestin otsakkeessa kerrotulla nimellä, joten palvelun voi vaihtaa tai poistaa koskematta muihin. Toimivan DKIM:n voi varmistaa vain lähettämällä testiviestin jokaisesta palvelusta.

DMARC: vastaako tunnistus näkyvää lähettäjää?

DMARC yhdistää kaksi edellistä siihen osoitteeseen, jonka vastaanottaja näkee. Viesti läpäisee DMARC-tarkistuksen, kun SPF tai DKIM onnistuu ja sen verkkotunnus vastaa From-osoitteen verkkotunnusta. Molempien ei tarvitse onnistua.

DMARC-tietueessa kerrotaan, mitä epäonnistuneille viesteille pitäisi tehdä:

p=none

Vastaanottajaa ei pyydetä tekemään mitään. Tila sopii aloitukseen ja raporttien keräämiseen, mutta se ei torju väärennöksiä.

p=quarantine

Viesti käsitellään epäilyttävänä, yleensä se ohjataan roskapostikansioon.

p=reject

Viesti hylätään.

Lopullisen päätöksen tekee aina vastaanottajan postipalvelu. Raportteja tulee vain, jos tietueessa on raporttiosoite, ja niistä on hyötyä vain, jos joku käy ne läpi. Raportit ovat koneluettavia XML-tiedostoja, joten läpikäynti kuuluu yleensä IT-kumppanille.

p=quarantine on välivaihe. Tavoite on p=reject, kuten Kyberturvallisuuskeskus suosittaa, kun kaikki lähettävät palvelut on varmistettu. Se on vakiintunut perustaso: Yhdysvaltain kyberturvallisuusvirasto CISA määräsi jo vuonna 2017 liittovaltion virastot siirtymään vuoden kuluessa tilaan p=reject. Käytäntö koskee oletuksena myös aliverkkotunnuksia, kuten laskut.yritys.fi. Niille voi antaa oman käytännön sp=-määreellä, mutta sitä ei kannata jättää tilaan sp=none, koska silloin huijari voi lähettää postia aliverkkotunnuksen nimissä.

Esimerkki: kuviteltu Esimerkki Oy julkaisee tietueen v=DMARC1; p=none; rua=mailto:dmarc@esimerkki.example. Huijari lähettää laskun osoitteesta laskutus@esimerkki.example, eikä viesti läpäise tarkistusta. Tilassa p=none se voi silti päätyä vastaanottajan saapuneisiin, ja Esimerkki Oy näkee sen vasta raportista. Tilassa p=reject vastaanottajan postipalvelu yleensä hylkää sen.

Suomessa näin on käynyt: vuonna 2021 useat yrittäjät saivat kiristysviestin, joka näytti tulleen heidän omasta osoitteestaan. Kyberturvallisuuskeskuksen asiantuntijan mukaan suojaus oli tuolloin kunnossa vain noin kolmella prosentilla .fi-verkkotunnuksista.

Samaa aukkoa käyttävät myös valtiolliset hyökkääjät. FBI, NSA ja Yhdysvaltain ulkoministeriö varoittivat toukokuussa 2024, että Pohjois-Korean Kimsuky-ryhmä lähetti kalasteluviestejä oikeiden ajatushautomoiden ja uutismedioiden osoitteista. Niiden DMARC puuttui tai oli tilassa p=none.

Sähköpostihuijaukset ovat kalliita. FBI:n IC3-keskukselle ilmoitettiin vuonna 2025 yrityksiin kohdistuneista sähköpostihuijauksista (BEC) 24 768 tapausta ja yli 3 miljardin dollarin tappiot. Luvussa ovat mukana myös murretuilta tileiltä tehdyt huijaukset, joita DMARC ei estä.

Miksi asetukset vaikuttavat myös perillemenoon?

Suuret postipalvelut käyttävät näitä tarkistuksia myös roskapostin suodatukseen. Gmail edellyttää helmikuusta 2024 alkaen, että jokainen lähettäjä käyttää SPF:ää tai DKIM:iä. Lähettäjältä, joka lähettää Gmail-osoitteisiin yli 5 000 viestiä päivässä, vaaditaan kaikki kolme, ja Yahoo vaatii samaa suurilta lähettäjiltä. Microsoft alkoi toukokuussa 2025 vaatia samaa suurilta lähettäjiltä Outlook.com-osoitteisiin. Puutteelliset asetukset voivat siis viedä aidonkin laskun tai tarjouksen roskapostiin.

Näin kiristätte asetukset turvallisesti

1. Listatkaa kaikki lähettävät palvelut. Myös laskut, lomakkeet, ajanvaraus ja markkinointi. Merkitkää jokaiselle ylläpitäjä.
2. Käyttäkää palvelun omia ohjeita. Verkosta kopioitu esimerkkitietue ei tunne teidän lähettäjiänne.
3. Lähettäkää testiviesti jokaisesta palvelusta. Katsokaa vastaanotetun viestin tunnistustulokset. Yhden postilaatikon toimiminen ei riitä.
4. Aloittakaa tilasta p=none ja käykää raportit läpi. Pyytäkää IT-kumppanianne erottamaan omat lähettäjät väärennöksistä ennen kuin siirrytte tiukempaan tilaan.
5. Siirtykää tilaan p=quarantine. Kun kaikki omat lähettäjät läpäisevät tarkistuksen, väärennetyt viestit ohjautuvat roskapostiin.
6. Siirtykää tilaan p=reject. Kun raporteissa ei enää näy omia hylättyjä viestejä, väärennökset hylätään kokonaan.
7. Pitäkää paluutie auki. Vanhat asetukset tallessa ja joku valmiina korjaamaan, jos aitoja viestejä alkaa kadota.

Kyberturvallisuuskeskuksen Microsoft 365 -ohje neuvoo etenemään samoin. Nimissänne lähetetystä väärennöksestä voi lähettää näytteen Kyberturvallisuuskeskukselle liitteenä, jotta otsaketiedot säilyvät.

Mitä ilmainen tarkistus kertoo, ja mitä ei

Kybervartion sähköpostiturvan tarkistus lukee verkkotunnuksen julkiset DNS-asetukset selaimessanne. Se ei lähetä testiviestejä eikä näe yksittäisiä viestejä. DKIM-avainta haetaan yleisimmillä selektorinimillä, joten tulos "ei löytynyt" voi tarkoittaa myös, että avain on eri nimellä.

Nämä suojaukset eivät myöskään estä huijausta, jossa käytetään samannäköistä verkkotunnusta tai murrettua oikeaa sähköpostitiliä. Ne eivät estä myöskään viestiä, jossa vain lähettäjän nimi on väärennetty ja osoite on esimerkiksi Gmail-tili, kuten Kyberturvallisuuskeskuksen elokuussa 2026 varoittamissa palkanmaksuhuijauksissa. Varmistakaa maksu- ja tilipyynnöt toista kautta. Laajempi katsaus julkisiin asetuksiin kuuluu perustarkastukseen, ja Kybervartio-seuranta tarkistaa asetukset päivittäin, kertoo toimia vaativista muutoksista yleensä samana arkipäivänä ja kokoaa kuukausikoosteen.