SPF, DKIM ja DMARC: näin sähköpostin lähettäjä varmennetaan

Sähköpostin näkyvä lähettäjäosoite on samanlainen kenttä kuin kirjekuoren kääntöpuolelle käsin kirjoitettu nimi. Sen kirjoittaa lähettäjä, eikä postilaitos tarkista sitä. Sähköpostin alkuperäisessä rakenteessa ei ole mitään mekanismia, joka estäisi kirjoittamasta lähettäjäksi kenet tahansa.

Tämä ei ollut aikanaan huolimattomuutta. Sähköposti suunniteltiin verkkoon, jossa palvelimet tunsivat toisensa ja lähettäjän aitous ei ollut ongelma. Kun sama järjestelmä siirtyi maailmanlaajuiseen käyttöön, puuttuva tarkistus muuttui kalastelun tärkeimmäksi työkaluksi.

Ratkaisu rakennettiin päälle, ei sisään. Kolme erillistä menettelyä lisättiin vuosien mittaan, kukin ratkaisemaan eri osan ongelmasta. Ne kaikki tallennetaan verkkotunnuksen nimipalveluun, koska se on ainoa paikka, jonka jokainen vastaanottava palvelin osaa jo valmiiksi lukea.

Nimipalvelun valinta ei ole sattumaa. Se on jo valmiiksi hajautettu järjestelmä, jossa jokainen verkkotunnus voi julkaista tietoa itsestään ilman että kenenkään pitää rekisteröityä mihinkään keskitettyyn luetteloon. Kun verkkotunnus on hallinnassasi, sen nimipalvelutietueet ovat sinun sanasi, ja koko maailman postipalvelimet osaavat lukea ne saman tien. Sama piirre selittää senkin, miksi korjaus ei näy heti: vanha tieto elää välimuisteissa voimassaoloaikansa loppuun.

Kaksi lähettäjäosoitetta, ei yhtä

Ennen kuin tietueita voi ymmärtää, pitää tietää että jokaisessa viestissä on kaksi eri lähettäjäosoitetta. Ne voivat olla eri osoitteita, ja hyvin usein ne ovat.

Kirjekuoren lähettäjä on osoite, jonka lähettävä palvelin ilmoittaa toiselle palvelimelle toimituksen aikana. Se ei näy sähköpostiohjelmassa. Sen tehtävä on kertoa, minne palautusviestit lähetetään, jos toimitus epäonnistuu.

Otsikon lähettäjä eli From-kenttä on se osoite, jonka lukija näkee. Se on osa viestin sisältöä, ja lähettävä ohjelma kirjoittaa sen.

Ero on koko aiheen ydin. Postituslistat ja uutiskirjepalvelut käyttävät tätä eroa täysin laillisesti: viesti näyttää tulevan yhdistykseltä, mutta palautusviestit ohjataan lähetyspalvelun omaan osoitteeseen. Huijari käyttää samaa eroa toiseen tarkoitukseen. Jos et vielä tiedä, miten viesti kulkee palvelimelta toiselle, se kannattaa lukea ensin sähköpostin toiminnasta.

SPF: lista sallituista lähettäjistä

SPF (Sender Policy Framework) vastaa yhteen kysymykseen: saako tämä palvelin lähettää postia tämän verkkotunnuksen nimissä?

Verkkotunnuksen haltija julkaisee nimipalvelussa tekstitietueen, jossa luetellaan sallitut lähettävät palvelimet. Lista voi sisältää IP-osoitteita ja viittauksia muiden palveluiden omiin listoihin, jolloin sähköpostipalvelun tai uutiskirjetyökalun palvelimet tulevat mukaan ilman että niitä pitää luetella käsin. Tietueen lopussa kerrotaan, miten pitäisi suhtautua palvelimeen jota listalla ei ole.

Vastaanottava palvelin katsoo, mistä osoitteesta yhteys tuli, hakee kirjekuoren lähettäjän verkkotunnuksen SPF-tietueen ja vertaa. Tarkistus on nopea ja kevyt.

SPF:llä on kaksi tunnettua rajoitusta. Ensimmäinen on edelleenohjaus: kun viesti ohjataan automaattisesti eteenpäin toiseen osoitteeseen, se saapuu lopulliselle vastaanottajalle väärästä palvelimesta ja SPF epäonnistuu, vaikka viesti on täysin aito. Toinen on se, että SPF tarkistaa kirjekuoren lähettäjän, ei sitä osoitetta jonka lukija näkee. Pelkkä SPF ei siis estä väärennettyä From-kenttää lainkaan.

Kolmas rajoitus on käytännöllinen. SPF-tarkistus saa tehdä vain rajallisen määrän nimipalveluhakuja, koska muuten yksi viesti voisi aiheuttaa kymmenien kyselyiden vyöryn. Kun organisaatio ottaa käyttöön yhä uusia lähetyspalveluja ja lisää jokaisen viittauksena tietueeseen, raja tulee vastaan ja koko tarkistus alkaa epäonnistua. Tämä on yleinen syy siihen, että aiemmin toiminut lähetys lakkaa läpäisemästä tarkistuksia ilman että kukaan on muuttanut mitään ilmeistä.

DKIM: allekirjoitus, joka kulkee viestin mukana

DKIM (DomainKeys Identified Mail) ratkaisee eri ongelman. Se ei kysy mistä viesti tuli vaan onko viesti muuttunut ja tunnustaako verkkotunnus sen omakseen.

Lähettävä palvelin laskee viestin sisällöstä ja valituista otsikkokentistä tiivisteen ja allekirjoittaa sen salaisella avaimellaan. Allekirjoitus lisätään viestiin omana otsikkokenttänään. Vastaava julkinen avain julkaistaan verkkotunnuksen nimipalvelussa, ja allekirjoituksessa kerrotaan sekä verkkotunnus että valitsin, jolla oikea avain löydetään.

Vastaanottaja hakee julkisen avaimen, laskee viestistä oman tiivisteensä ja tarkistaa allekirjoituksen. Jos ne täsmäävät, kaksi asiaa on todistettu: viesti on peräisin taholta, jolla on verkkotunnuksen salainen avain, eikä allekirjoitettu osa ole muuttunut matkalla.

DKIM kestää edelleenohjauksen, koska allekirjoitus matkustaa viestin sisällä eikä riipu lähettävästä palvelimesta. Se rikkoutuu kuitenkin, jos jokin välissä oleva järjestelmä muokkaa viestiä, esimerkiksi lisää postituslistan tunnuksen otsikkoriville tai liittää tekstiä viestin loppuun.

Myöskään DKIM ei yksinään sido allekirjoitusta näkyvään lähettäjäosoitteeseen. Viesti voi olla kelvollisesti allekirjoitettu jollain aivan muulla verkkotunnuksella kuin sillä, joka näkyy From-kentässä.

DMARC: kohdistus ja ohje vastaanottajalle

Tässä kohtaa DMARC (Domain-based Message Authentication, Reporting and Conformance) tulee mukaan, ja se tekee kaksi asiaa.

Ensimmäinen on kohdistus. DMARC vaatii, että läpäisty SPF- tai DKIM-tarkistus koskee samaa verkkotunnusta, joka näkyy lukijalle From-kentässä. Tämä on se puuttuva lenkki, joka muuttaa kaksi teknistä tarkistusta väitteeksi lähettäjän henkilöllisyydestä. Riittää, että toinen tarkistuksista läpäistään kohdistettuna.

Toinen on ohje. Verkkotunnuksen haltija julkaisee nimipalvelussa käytännön, joka kertoo vastaanottavalle palvelimelle, mitä tehdä viestille joka väittää tulevansa tästä verkkotunnuksesta mutta ei läpäise kohdistettua tarkistusta. Vaihtoehtoja on kolme: älä tee mitään erityistä, siirrä roskapostiin tai hylkää kokonaan.

Huomaa, ettei vastaanottava palvelin ole velvollinen noudattamaan ohjetta. DMARC on suositus, ei pakko. Käytännössä suuret postipalvelut ottavat sen kuitenkin vakavasti, ja hylkäysohjeen julkaisseen verkkotunnuksen väärentäminen on selvästi vaikeampaa kuin sellaisen, jolla ohjetta ei ole.

Näin tarkistus etenee vastaanottavassa päässä

Vastaanottava palvelin tekee koko työn muutamassa sekunnissa, ennen kuin viesti on edes lajiteltu postilaatikkoon. Vaiheet ovat nämä.

1. Yhteyden kirjaus. Palvelin merkitsee muistiin, mistä osoitteesta yhteys tuli ja minkä kirjekuoren lähettäjän toinen pää ilmoitti.
2. SPF-tarkistus. Se hakee kirjekuoren lähettäjän verkkotunnuksen SPF-tietueen ja katsoo, onko yhteyden lähdeosoite sallittujen listalla.
3. DKIM-tarkistus. Se etsii viestistä allekirjoituskentät, hakee kunkin allekirjoituksen ilmoittamalta verkkotunnukselta julkisen avaimen ja tarkistaa, täsmääkö allekirjoitus viestin sisältöön.
4. Kohdistuksen arviointi. Se vertaa From-kentän verkkotunnusta niihin verkkotunnuksiin, joita onnistuneet tarkistukset koskivat.
5. Käytännön haku. Jos kumpikaan tarkistus ei kohdistu, palvelin hakee From-verkkotunnuksen DMARC-käytännön ja toimii sen ohjeen mukaan.
6. Tuloksen kirjaus. Lopputulos tallennetaan viestin otsikkotietoihin ja tilastoidaan raportteja varten.

Vasta tämän jälkeen alkaa varsinainen sisällön arviointi. Tarkistusten tulos menee siihen mukaan yhtenä painavana tietona muiden joukossa.

Raportit ovat DMARC:n aliarvioitu puoli

DMARC:n kirjainlyhenteen viimeinen osa tarkoittaa raportointia, ja se on verkkotunnuksen haltijalle usein arvokkaampi kuin itse ohje.

Käytäntöön voi merkitä osoitteen, johon vastaanottavat postipalvelut lähettävät säännöllisesti koosteraportteja. Raportti kertoo, mitkä palvelimet ovat lähettäneet postia verkkotunnuksen nimissä ja miten tarkistukset menivät. Se ei sisällä viestien sisältöä.

Tästä syystä käyttöönotto tehdään yleensä kolmessa vaiheessa. Ensin julkaistaan käytäntö, joka ei pyydä mitään toimenpiteitä mutta kerää raportteja. Sitten katsotaan raporteista, mitkä omat järjestelmät epäonnistuvat, ja korjataan ne. Vasta lopuksi käytäntöä kiristetään. Järjestys on tärkeä, koska liian aikaisin asetettu hylkäysohje pysäyttää myös omat laskutusjärjestelmät ja uutiskirjeet.

Jos hallinnoit omaa verkkotunnusta, muista myös että nimipalvelun muutokset näkyvät viiveellä välimuistin voimassaoloajan verran. Tietueen korjaaminen ei siis vaikuta heti kaikkialla.

Mitä nämä eivät estä

Tässä kohtaa on syytä olla rehellinen. Kolmikko ratkaisee tarkkaan rajatun ongelman: sen, että viesti väittää tulevansa verkkotunnuksesta johon lähettäjällä ei ole oikeutta. Se ei ratkaise huijauksia yleisesti.

• Samannäköinen verkkotunnus. Huijari rekisteröi oman verkkotunnuksen, joka muistuttaa oikeaa, ja julkaisee sille täydelliset SPF-, DKIM- ja DMARC-tietueet. Kaikki tarkistukset menevät läpi, koska viesti tulee aidosti siitä verkkotunnuksesta. Vaihtoehtoina ovat kirjainvaihdokset, ylimääräiset sanat ja eri ylätason verkkotunnus.
• Näyttönimi. Sähköpostiohjelma näyttää usein vain lähettäjän nimen, ei osoitetta. Nimi on vapaata tekstiä eikä kuulu tarkistusten piiriin lainkaan. Puhelimen pienellä ruudulla tämä on erityisen tehokasta.
• Kaapattu tili. Jos huijari on saanut oikean käyttäjän tunnukset, viesti lähtee oikeasta palvelusta ja läpäisee kaiken. Tarkistukset todistavat verkkotunnuksen, eivät sitä kuka näppäimistön ääressä istui.
• Viestin sisältö. Läpäisty tarkistus ei kerro mitään siitä, onko viesti asiallinen. Aidon verkkotunnuksen kautta voi lähettää täyttä roskaa.

Yksi lisärajaus kannattaa tietää. Käytäntö voidaan asettaa erikseen verkkotunnukselle ja sen aliverkkotunnuksille. Jos aliverkkotunnuksia ei ole huomioitu, huijari voi keksiä sellaisen aliverkkotunnuksen, jota ei ole koskaan käytetty, ja lähettää sen nimissä. Osoite näyttää lukijan silmään täysin uskottavalta, koska organisaation oikea nimi on siinä keskellä.

Vastaanottajan kannalta johtopäätös on selvä: tekniset tarkistukset nostavat riman huijarille mutta eivät korvaa viestin lukemista ajatuksella. Käytännön tunnusmerkit käydään läpi huijausviestien tunnistamisessa.

Miten tämä näkyy sinulle

Tavallinen käyttäjä ei koskaan aseta näitä tietueita, mutta kohtaa niiden seuraukset viikoittain.

1. Viesti roskapostissa ilman selvää syytä. Yleinen taustasyy on epäonnistunut kohdistus: viesti tulee palvelusta, jota lähettäjän verkkotunnus ei ole valtuuttanut. Tämä on tavallista, kun yhdistys tai pienyritys ottaa käyttöön uuden uutiskirjetyökalun.
2. Otsikkotietojen tarkistus. Vastaanottava palvelin kirjaa tarkistusten tuloksen viestin otsikkokenttiin. Jos haluat tietää, läpäisikö viesti tarkistukset, avaa viestin alkuperäinen muoto ja etsi rivi, jossa lukee tarkistusten tulokset.
3. Oma verkkotunnus. Jos lähetät postia omalla verkkotunnuksella, kolme tietuetta ovat perusasetuksia siinä missä MX-tietue. Ilman niitä viestisi päätyvät muita todennäköisemmin roskapostiin.
4. Suodatuksen ymmärtäminen. Tarkistusten tulos on vain yksi signaali muiden joukossa siinä päätöksessä, jonka roskapostisuodatin tekee.

Muista lopuksi tärkein rajaus. Läpäisty tarkistus todistaa, että viesti tulee siitä verkkotunnuksesta jonka näet. Se ei todista, että verkkotunnus on se, jonka luulet sen olevan.