Tai pikemminkin niiden puuttuminen. Nimittäin marraskuusta 2022 alkaen Google alkoi vaatia entuudestaan tuntemattomilta verkkotunnuksilta joko SPF:n (Sender Policy Framework) tai DKIM:n (Domain Keys Identified Mail) käyttöä. Ongelma koski siis lähinnä uusia verkkotunnuksia, koska vanhoilta verkkotunnuksilta useimmiten oli sähköposteja lähetetty Gmailiin jo aiemmin ja ne olivat sitä kautta jo entuudestaan Gmailin tuntemia.

Jossain kohtaa vaatimus on laajentunut koskemaan myös vanhoja verkkotunnuksia, todennäköisesti kesän 2023 aikana. Sähköpostien kanssa on siis jatkossa syytä käyttää joko SPF:ää tai DKIM:iä. Muutoin sähköpostin perille saaminen Gmailiin on melkoisen epävarmalla pohjalla.

Miksi Gmail on alkanut vaatia SPF:n ja DKIM käyttöä?

Google perustelee vaatimusta roskapostin ja erilaisten huijausyritysten torjunnalla, kuten Googlen ohjeistuksista on luettavissa: Help prevent spoofing and spam with SPF

Valitettavasti sekä SPF että DKIM soveltuvat roskapostin ja huijausyritysten torjuntaan heikosti. Idea on sinällänsä hyvä, mutta käytännön toteutus jättää toivomisen varaa.

SPF:llä on tarkoitus määritellä palvelimet mistä kyseinen verkkotunnus lähettää sähköpostinsa. Se viestissä näkyvä ”Lähettäjä” kohta ei kuitenkaan ole se, mihin vertailu SPF:n tapauksessa tehdään. Viesti voidaan siis lähettää joltain kyseistä verkkotunnusta muistuttavalta verkkotunnukselta ja väärentään viestin lukijalle näkyvä ”Lähettäjä” kenttä halutuksi. Tätä SPF ei valitettavasti estä.

DKIM puolestaan perustuu palvelimen allekirjoittamaan varmenteeseen, jonka idea on varmistaa ettei viesti muuttuisi matkalla. Valitettavasti näkyvän ”Lähettäjä” kentän väärennys on myös DKIMin kanssa täysin mahdollista.

Kumpikaan ei ole mitenkään uusi keksintö, mutta molemmat ovat oleet kohtuullisen vähän käytettyjä. Osin puutteiden takia ja osittain siitä syystä että molemmilla voi saada aikaan myös ongelmia. Virheellisten tai puutteellisten SPF ja DKIM asetusten lisäksi yksi ongelmakohdista on sähköpostien automaattinen uudelleenohjaus eli forwardointi, josta lisää hieman alempana.

Miksi Google sitten päätti yhtäkkiä alkaa vaatimaan jomman kumman käyttöä? Lievästi skeptisenä luonteena epäilen että syynä on raha. Googlen emoyhtiö Alphabet Inc on pörssiyhtiö ja sen osakekurssi lasketteli alamäkeä käytännössä koko vuoden 2022. Kun pörssiyhtiön osakekurssi laskee – alkaa yleensä säästötoimet. Gmail on erittäin suosittu palvelu, mutta sen tuottaminen ei ole ilmaista. Mikäli oheinen artikkeli vuodelta 2016 osuu edes oikealle hehtaarille, kyseessä on melkoinen kasa rahaa. Siinä missä 2016 käyttäjämääräksi on arvioitu ”vain” miljardi, nykyään Gmaililla arvioidaan olevan yli 1,8 miljardia käyttäjää. Jatkuvasti kasvavaa palvelintilatarvetta hillitsee mitä tiukempia kriteereitä vastaanotettaville viesteille asetetaan. Samaa tavoitetta auttaa myös epäaktiivisten tilien poistaminen, mistä Google ilmoitti tänä keväänä. Tämän vuoden joulukuusta alkaen yli kaksi vuotta epäaktiivisena olleet Google-tilit saattavat joutua poistetuiksi: Updating our inactive account policies

SPF ja ongelmat sähköpostien automaattiseen uudelleenohjaukseen

Sähköpostin automaattinen uudelleenohjaus ei normaalisti aiheuta ongelmia DKIMin suhteen, sillä kunhan viestin sisältö ei muutu matkalla, läpäisee se edelleen DKIM-tarkastuksen. Valitettavasti SPF:n suhteen tilanne on toinen, automaattisella uudelleenohjauksellakin lähettävä palvelin muuttuu matkalla ja viesti ei tästä johtuen läpäise SPF-tarkastusta.

Tällöin ratkaisevaksi muodostuu se, miten lähettäjän SPF-kenttä on muotoilu ja miten vastaanottava sähköpostipalvelin niitä noudattaa. Jos käytössä on tiukat asetukset ja vastaanottava palvelin noudattaa sääntöä, kieltäytyy se vastaanottamasta automaattisesti uudelleenohjattua viestiä. Tällöin sähköposti itse asiassa menee läpi alkuperäiseen osoitteeseen, mutta automaattisesti uudelleenohjattu viesti ei mene perille ja lähettäjä saa bumerangin takaisin otsikolla ”Mail delivery failed: returning message to sender”.

Koska Gmail noudattaa SPF:n tiukkoja sääntöjä ja esim. Microsoftin sähköpostipalvelimilla oletuksena on tiukat SPF-asetukset, automaattinen uudelleenohjaus Gmailiin ei mene läpi kun lähettäjällä käytössä on Microsoftin sähköpostipalvelut oletusasetuksilla.

Sähköpostien automaattista uudelleenohjausta on siis nykyään syytä käyttää hyvin harkiten ja noudattaa ainakin seuraavia sääntöjä:

1) Älä käytä automaattista uudelleenohjausta Gmail-tilille, lähettäjän tiukoilla SPF-asetuksilla viestit eivät mene perille.

2) Jos käytät Microsoftin sähköpostipalveluita, älä käytä SPF:ää oletusasetuksilla. Osa sähköpostiosoitteista nimittäin toimii kokonaan uudelleenohjausperiaatteella ja aiheutat hallaa omien viestiesi perille menolle. Esim. kaikki @iki.fi -osoitteet perustuvat uudelleenohjaukseen.

Valitettavasti kaksi tietotekniikka-alan jättiläistä ovat siis valitsemillaan käytännöillä tehneet pitkään käytössä olleestä sähköpostien automaattisesta uudelleenohjauksesta huomattavasti aiempaa epävarmemman tekniikan.

Sinällänsä tätä ei voi pitää yllättävänä, sillä jo pari vuotta sitten moni Microsoftin Hotmailia käyttänyt havahtui siihen ettei Gmailista lähetetyt viestit tulleet perille. Toisin kuin tässä tapauksessa, viestit suodatettiin pois eikä lähettäjä saanut mitään tietoa siitä etteivät viestit mene perille saakka… Not receiving emails from Gmail in my Hotmail

Onko SPF käytössä? Miten tarkistan ja tulkitsen SPF-kenttää

Kaikissa Windowseissa on edelleen pääsy komentoriville, vanhemmissa Windowseissa se löytyi usein Apuohjelmien alta nimellä komentokehote (esim. Windows 7). Windows 11:sta se kulkee nimellä Windows Powershell ja löytyy ainakin suomenkielisestä oletuksena sovelluslistasta nimellä Pääte.

Komennolla nslookup -type=txt verkkotunnus.pääte näet kyseisen verkkotunnuksen nimipalvelintiedoissa olevat tekstikentät.

Jos SPF on käytössä löytyy tekstikenttä joka alkaa ”v=spf1…” sekä mahdollisesti muita tekstikenttiä.

Esim. hieman sähköpostia hitaamman kirjepostin kantajan tapauksessa seuraava:

Kuvan mukaisessa tapauksessa on määritelty kolme erillistä IP-osoitetta sekä niiden lisäksi sisällytetään spf.protection.outlook.com. Posti siis käyttää Microsoftin sähköpostipalveluita, mutta toisin kuin oletuksena Microsoftin ohjeistuksissa neuvotaan, lopussa on ~all eikä -all.

Tämä on erittäin oleellinen ero, sillä esim. edellä mainittu viestien automaattinen uudelleenohjaus aiheuttaa ~all vaihtoehdolla SPF tarkistuksessa tuloksen ”SoftFail” eli viesti ei läpäissyt SPF-tarkistusta, mikä tulisi merkitä ja hyväksyä viestin vastaanotto. Kun taas vaihtoehto -all aiheuttaa samassa tilanteessa tuloksen ”Fail” eli viesti ei läpäissyt SPF-tarkistusta ja sen vastaanotosta tulisi kieltäytyä.

Koska et lähettäessä voi tietää onko vastaanottajalla automaattinen uudelleenohjaus käytössä vaiko ei, kannattaa käyttää vaihtoehtoa ~all. Näin tekee myös esim. verkkolaiteyhtiö Nokia.

Muita SPF-kentässä usein esiintyviä vaihtoehtoja ovat:

a eli a-tietue mikä kertoo kyseisen verkkotunnuksen IP-osoitteen
mx eli verkkotunnuksen sähköpostipalvelimet

Näiden edessä voi myös olla + eli plusmerkki, merkitys on sama sen kanssa ja ilman sitä. Lisäksi ip6: alkuiset kentät ovat yleistymässä. Kyse siis on uudemman ja laajemman IPv6 protokollan mukaisista IP-osoitteista.

Tärkeää on että kaikki mistä sähköpostia on tarkoitus lähettää, on varmasti mukana! Huonosti määritelty SPF-kenttä saattaa aiheuttaa suurempia ongelmia kuin sen puuttuminen.

Mikäli sähköpostia lähetetään vain webmailista ja/tai erillisestä sähköpostiohjelmasta (Thunderbird, Outlook tms.) oman verkkotunnuksen kautta sekä omilta verkkosivuilta tulee yhteydenotot sähköpostiin, on SPF-kenttä melko yksinkertainen.

Muun muassa palvelitilan hallintaan tarkoitetussa cPanelissa on ”Email Deliverability” toiminto, jolla SPF:n voi ottaa tälläisessa tilanteessa suoraan käyttöön. Tässä kohtaa on tosin syytä olla tarkkana, sillä jos käytössä on jotain sähköposteja lähettäviä oman palvelintilan ulkopuolisia palveluita ne on syytä huomioida SPF-kentässä.

SPF ja verkkokauppa- sekä sähköpostimarkkinointipalvelut

Ehkä yleisimpiä SPF-kentässä huomioitavia asioita on ulkopuoliset verkkokauppapalvelut, siis tilanteessa jossa varsinaisen verkkotunnus ja sähköpostit ovat muualla ja pelkkä www-liikenne on ohjattu verkkokauppapalveluun (esim. MyCashflow, Vilkas, Shopify, Finqu jne.). Jotta verkkokaupan tilausvahvistukset menisivät perille, on SPF-kentässä huomioita myös ne palvelimet jotka lähettävät verkkokaupan tilausvahvistukset.

Sama tilanne on luonnollisesti myös sähköpostimarkkinointialustojen, kuten esim. MailChimpin, Brevon tai muiden vastaavien kanssa. Ne on syytä lisätä SPF-kenttiin, jos haluaa markkinointiviestien menevän perille asti.

Oma lukunsa on myös operaattorien lähtevän sähköpostin palvelimet. Joskus esim. Outlook tai Thunderbird on saatettu asettaa käyttämään oman verkkotunnuksen lähtevän postin palvelimen sijasta operaattorin lähtevän postin palvelinta. Tämä ei lähtökohtaisesti ole yleensä paras vaihtoehto, sillä operaattorien lähtevän postin palvelimilla on ollut taipumusta päätyä mustalle listalle: IP blacklisted | Telia Yhteisö

Jos kuitenkin jostain syystä operaattorin lähtevän postin osoitetta haluaa käyttöön, on se täysin mahdollista kunhan ne vain on huomioitu SPF-kentässä.

Entä sitten DKIM? Sen kanssa palvelintilan ulkopuolisia palvelut on syytä ottaa huomioon, kuten SPF:n kanssakin. Käytössä voi olla useampiakin DKIM-kenttiä, mutta ulkopuolisten palveluidenkin täytyisi tukea DKIMin käyttöä. Sen takia voi joissain tilanteissa olla järkevämpi tyytyä pelkän SPF:n käyttöön, sen asettaminen kun ei varsinaisesti edellytä edes mitään tukea ulkopuolisilta palveluilta. Riittää kun tiedossa on miltä kaikilta palvelimilta oman verkkotunnuksen sähköpostit lähtevät.