Defaults.Exposed › Korjaukset › SPF (Sender Policy Framework)

Kuinka korjata SPF (Sender Policy Framework)

SPF on yksi rivi verkkotunnuksesi asetuksissa – se kertoo, mitkä sähköpostipalvelut saavat lähettää viestejä yrityksesi nimissä. Ilman sitä kuka tahansa maailmalla voi lähettää sähköpostia, joka näyttää tulevan sinulta – ja omat aidot viestisi päätyvät helpommin asiakkaiden roskapostiin.

Lyhyesti liiketoiminnallesi: Kuka tahansa voi lähettää sähköpostia esiintyen yrityksenäsi – asiakkaillesi, henkilöstöllesi ja tavarantoimittajillesi – laskuista maksutietojen muutospyyntöihin asti. Samalla omat tarjouksesi ja laskusi päätyvät todennäköisemmin roskapostiin, jolloin kaupat hiljentyivät huomaamattasi.

Mitä tämä voi maksaa sinulle

Huijari lähettää asiakkaallesi laskun 'sinulta' omilla pankkitiedoillaan, ja asiakas maksaa sen. Saat tietää viikkojen kuluttua, kun asiakas kysyy tilauksensa perään – ja nyt kyseessä on mainehaitta ja mahdollisesti myös vastuukysymys.
Tarjouksesi, laskusi ja vastauksesi päätyvät hiljalleen asiakkaiden roskapostiin, koska Gmail ja Yahoo eivät pysty varmistamaan niiden alkuperää. Kaupat kylmenevät etkä koskaan tiedä miksi.
Huijari esiintyy toimitusjohtajana tai talousvastaavana ja lähettää henkilöstölle viestin kiireellisestä maksusta tai lahjakorteista – viesti näyttää aidosti tulevan verkkotunnukseltasi, joten joku maksaa.
Suuremman asiakkaan IT- tai tietoturvatarkastus tarkistaa verkkotunnuksesi, huomaa puuttuvan lähettäjänsuojan ja joko hylkää sinut tai vaatii korjausta ennen sopimusta – menetetty kauppa tai viikkoja myöhästynyt allekirjoitus.
Luulet olevasi suojattu, koska SPF-tietue on olemassa – mutta se on asetettu 'pehmeäksi hylkäykseksi' ilman DMARC-vahvistusta, joten väärennetyt viestit silti läpäisevät suodatuksen.

Miksi tällä on merkitystä. Sähköpostin lähettäjäosoitteen väärentäminen on triviaalia eikä maksa hyökkääjälle mitään. SPF on nopein ja halvin tapa vaikeuttaa verkkotunnuksesi väärinkäyttöä sekä pitää omat viestisi poissa roskapostista. Google ja Yahoo alkavat aktiivisesti hylätä tai poistaa viestit, joiden verkkotunnuksia ei ole autentikoitu – tämä ei siis enää ole valinnainen parannus, vaan edellytys sille, että viestisi ylipäätään toimitetaan perille.

Lyhyesti

Tällä hetkellä, ellei SPF ole asetettu oikein, kuka tahansa maailmassa voi lähettää sähköpostia, joka näyttää tulevan yritykseltäsi. He voivat lähettää asiakkaillesi väärennetyt laskut, henkilöstöllesi tekaisut maksupyynnöt ja tavarantoimittajillesi viestejä esiintyen sinuna – ja viestit näyttävät aidoilta, koska verkkotunnuksesi ei sano muuta.

SPF (Sender Policy Framework) on ratkaisu. Se on yksi tekstirivi verkkotunnuksesi DNS-asetuksissa, joka luettelee sähköpostipalvelut, joilla on oikeus lähettää viestejä puolestasi. Vastaanottavat palveluntarjoajat – Gmail, Outlook ja muut – tarkistavat listan ennen kuin päättävät, onko viesti aito. Ilman listaa tai sen ollessa heikko heillä ei ole mitään tarkistettavaa.

Tämä sivu käsittelee kahta asiaa, joiden molempien on oltava kunnossa: onko SPF-tietue ylipäätään olemassa ja onko se asetettu riittävän tiukasti.

Mitä tämä voi maksaa yrityksellesi

Nämä ovat arkipäiväisiä, todellisia tapoja, joilla puuttuva tai heikko SPF-tietue muuttuu menetetyiksi rahoiksi ja luottamukseksi. Emme nimeä oikeita yrityksiä – nämä ovat malleja, joita näemme datassa.

Laskuhuijaus. Rikollinen lähettää asiakkaallesi sähköpostin, joka näyttää täsmälleen sinulta, liittäen aidon näköisen laskun omilla pankkitiedoillaan. Asiakas maksaa sen. Ensimmäinen tieto on yhteydenotto, jossa kysytään tilatun tuotteen perään. Nyt edessä on vihainen asiakas, rikolliselle mennyt maksu ja vaikea keskustelu siitä, kuka kärsii tappion.
Toimitusjohtajahuijaus. Joku lähettää kirjanpitäjällesi viestin “sinulta”: “Nopeasti – voisitko hoitaa tämän maksun ennen päivän loppua?” Koska viesti näyttää aidosti tulevan verkkotunnukseltasi, se ei herätä epäilyksiä. Raha poistuu yrityksestä.
Hiljainen toimitettavuusongelma. Tarjouksesi ja laskusi alkavat päätyä asiakkaiden roskapostiin, koska Gmail ja Yahoo eivät pysty varmistamaan niiden alkuperää. Et saa palautusta, et virheilmoitusta – kaupat vain hiljenevät. Menetät liiketoimintaa, etkä edes näe sen tapahtuvan.
Menetetty sopimus. Suuremman asiakkaan hankintaosasto tai tietoturvatiimi tarkistaa verkkotunnuksesi osana toimittajasopimusta. He eivät näe lähettäjän suojausta ja merkitsevät sinut riskiksi. Parhaassa tapauksessa sinun on korjattava asia kireässä aikataulussa; pahimmassa tapauksessa he valitsevat kilpailijan, joka läpäisi tarkistuksen.
Brändin myrkyttäminen. Verkkotunnustasi käytetään tietojenkalastelukampanjassa. Huijatut ihmiset epäilevät nyt kaikkia sähköpostejasi – jopa aidot tarjoukset ja uusimisviestit jätetään huomiotta tai ilmoitetaan roskapostiksi.

Kaikkien näiden taustalla on sama kaava: hyökkääjä ei maksa mitään, ja yrityksesi kantaa kustannukset ja vastuun.

Mitä SPF oikeasti on

Kun sähköposti saapuu, vastaanottava postipalvelin haluaa tietää yhden asian: onko tämä todella se, joka väittää olevansa? SPF vastaa osaan tästä kysymyksestä.

Julkaiset lyhyen tekstirivin verkkotunnuksesi DNS-asetuksissa – “TXT-tietueena” – joka nimeää sähköpostipalvelut, joilla on lupa lähettää puolestasi. Esimerkiksi:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Selkokielellä: “Aito posti meiltä tulee Googlen ja SendGridin palvelimilta – hylkää kaikki muut, jotka väittävät olevansa me.”

Kaksi osaa, jotka vaikuttavat arvoosi:

Onko tietue olemassa? Tämä on tärkein osa (sillä on suurin painoarvo kaikista sähköpostivarmistuksen tarkistuksista). Ilman tietuetta vastaanottajilla ei ole mitään listaa tarkistettavaksi, joten esiintyminen on täysin mahdollista. On myös hienosyinen vikamuoto: jos verkkotunnuksellasi on kaksi tai enemmän SPF-tietueita, säännöt sanovat, että kaikki niistä ovat mitättömiä – sinulla ei siis ole toimivaa SPF:ää lainkaan, vaikka se näyttäisi olevan.
Onko politiikka riittävän tiukka? Tietue voi olla olemassa, mutta silti hampaaton. Lopetus – “all”-mekanismi – on ohje vastaanottajille:
- -all (kova hylkäys) — hylkää kaikki, mitä listalla ei ole. Vahvin asetus. Täydet pisteet.
- ~all (pehmeä hylkäys) + DMARC asetettu reject-tilaan — nykyinen suositeltava asetus. Yhtä suojaava kuin kova hylkäys ilman riskiä, että uudelleenohjatut viestit pomppaisivat takaisin. Täydet pisteet.
- ~all + DMARC quarantine-tilassa — hyväksyttävä, hieman heikompi; siirrä DMARC reject-tilaan täyden suojan saamiseksi.
- ~all yksin (ei DMARC-vahvistusta) — heikko. Tämä sanoo “todennäköisesti väärennös, toimita silti.” Väärennetyt viestit pääsevät läpi. Tähän ansaan monet yritykset lankeaa luullen olevansa suojattuja.
- ?all (neutraali) — ei tarjoa suojaa.
- +all — aktiivisesti vaarallinen: se kertoo maailmalle, että kuka tahansa saa lähettää nimissäsi. Älä koskaan käytä tätä.

On vielä yksi näkymätön vikamuoto: SPF:llä on lupa käynnistää enintään 10 DNS-hakua arvioinnin aikana. Liian monta include:-merkintää ja tietue ylittää rajan, jolloin vastaanottajat tulkitsevat koko tietueen rikkinäiseksi – ja olet taas ilman suojaa. Tämä on yleinen, hiljainen ongelma yrityksille, jotka käyttävät paljon markkinointi- ja SaaS-työkaluja.

Hyvä asetus näyttää tältä: täsmälleen yksi SPF-tietue, jossa on lueteltu kaikki palvelut, jotka lähettävät viestejä nimissäsi, päättyy -all-merkintään (tai ~all yhdistettynä DMARC:iin p=reject), ja se pysyy reilusti alle 10 haun rajan.

Korjausohje (ilmainen, n. 10 minuuttia)

Anna tämä osio verkkotunnuksesi tai verkkosivustosi hallinnoijalle – ja huomioi, että korjaus on ilmainen. Se on muutos DNS-asetukseen, ei ostettava tuote. Veloitamme vain sen seurannasta, että asetus pysyy oikeana ajan mittaan.

Vaihe 1 – Luettele kaikki palvelut, jotka lähettävät sähköpostia nimissäsi. Tässä ihmiset tekevät virheen. Kirjoita kaikki ylös: sähköpostipalveluntarjoaja (Google Workspace, Microsoft 365 jne.) sekä kaikki uutiskirjetyökalut, CRM-järjestelmät, asiakaspalvelutyökalut, verkkokauppaalustat, laskutus-/kirjanpitosovellukset ja varausjärjestelmät. Jos jokin palvelu lähettää viestejä nimissäsi ja unohdat sen, SPF estää sen postin, kun tiukennat politiikkaa.

Vaihe 2 – Julkaise yksi TXT-tietue verkkotunnuksesi juuressa. Yhdistä kaikkien lähettäjiesi “include”-rivit yhdeksi tietueeksi. Yleisimpien alustojen include-arvot:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (tai alueellisesti sopiva verkkotunnus)

Yhdistetty tietue näyttää tältä:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Mistä lisätä, palveluntarjoajan mukaan:

Cloudflare: DNS → Tietueet → Lisää tietue → Tyyppi TXT, Nimi @, Sisältö = yllä oleva arvo.
Microsoft 365 / Google admin: ne julkaisevat käytettävän include-merkkijonon asetustoiminnoissaan; kopioi se DNS-palveluntarjoajasi TXT-tietueeseen.
GoDaddy / useimmat palveluntarjoajat: DNS-hallinta → Lisää → TXT, Isäntä/Nimi @, Arvo = tietue.

Vaihe 3 – Aloita turvallisesti, tiukenna sitten. Julkaise ensin ~all (pehmeä hylkäys) varmistaaksesi, ettei mikään aito posti esty. Kun olet varmistanut kaiken aidon postin kulkeutuvan läpi, tiukenna -all (kova hylkäys) – tai paremmin, pidä ~all ja lisää DMARC-politiikka p=reject, mikä on suositeltava nykyinen yhdistelmä.

Vaihe 4 – Varmista, että sinulla on täsmälleen YKSI tietue. Jos vanha SPF-tietue on jo olemassa, muokkaa sitä sen sijaan, että lisäät uuden. Kaksi v=spf1-tietuetta kumoavat toisensa ja jättävät sinut suojattomaksi.

Vaihe 5 – Seuraa hakujen määrää. Jos sinulla on monia lähettäjiä, saatat ylittää 10 haun rajan. Tässä tapauksessa konsolidoi – jotkut palveluntarjoajat tarjoavat “SPF-tasoittamista”, tai poista lähettäjät, joita et enää käytä.

Vaihe 6 – Tarkista verkkotunnuksesi uudelleen varmistaaksesi, että se nyt läpäisee tarkistuksen tietueen ja tiukan politiikan kanssa.

Yleisimmät virheet

Kaksi SPF-tietuetta. Yleisin hiljainen vikamuoto. Uuden tietueen lisääminen olemassa olevan muokkaamisen sijaan mitätöi molemmat. Niitä saa olla täsmälleen yksi.
Pysähtyminen ~all-asetukseen ja olettaminen, että se riittää. Pehmeä hylkäys ilman DMARC-vahvistusta on heikko väliaskel – se näyttää konfiguroidulta mutta suojaa tuskin lainkaan. Joko siirry -all-asetukseen tai yhdistä ~all DMARC:in p=reject-asetukseen.
Lähettäjän unohtaminen. Tiukentaminen -all-asetukseen ennen laskutusohjelman, CRM:n tai uutiskirjetyökalun listaamista alkaa estää omaa aitoaa postiasi. Luettele kaikki ensin.
10 haun rajan ylittäminen. Jokainen include: voi ketjuttaa lisää hakuja. Liian monta ja tietue tulkitaan rikkinäiseksi. Pidä se siistinä.
+all-käyttö. Tämä valtuuttaa nimenomaisesti koko internetin lähettämään nimissäsi. Se on pahempi kuin ei tietuetta lainkaan. Älä koskaan julkaise sitä.

Mihin tämä sopii

SPF on perusta, mutta se on yksi kolmesta kerroksesta. DKIM lisää kryptografisen allekirjoituksen, joka todistaa, ettei viestiä ole muutettu, ja DMARC on ohje, joka yhdistää SPF:n ja DKIM:n sekä kertoo vastaanottajille, mitä tehdä epäonnistuneille viesteille – mukaan lukien esiintymisen estäminen näkyvällä “lähettäjä”-nimellä, jonka asiakkaasi näkevät. Saa SPF kuntoon ensin (se on nopein voitto ja sillä on suurin painoarvo), ja lisää sitten DKIM ja DMARC sulkeaksesi oven kokonaan. Kaikki kolme korjausta ovat ilmaisia.

Asenna palveluntarjoajallasi

Vaiheittainen ohje suosituille palveluntarjoajille:

UKK

En ole tekninen – voiko tämän hoitaa itse?

Teknistä osaamista ei tarvita. Muutos on yksi tai kaksi riviä verkkotunnuksesi asetuksiin, jonka tekee verkkosivustosi tai IT-palveluntarjoajasi hallitsija. Anna heille alla oleva 'Korjausohje' – se vie yleensä muutaman minuutin eikä maksa mitään. Veloitamme vain sen jatkuvasta seurannasta, että asetukset pysyvät oikeina.

Meillä on jo SPF-tietue – eikö se riitä?

Ei välttämättä. Tietueen olemassaolo on ensimmäinen puoli; riittävän tiukan politiikan asettaminen on toinen. Tietue, joka päättyy '~all' (pehmeä hylkäys) ilman DMARC-vahvistusta, kertoo vastaanottajapalvelimille 'tämä voi olla väärennös, mutta toimita silti' – suoja on minimaalinen. Kaksi SPF-tietuetta tai yksi, jossa on liikaa hakuja, tulkitaan rikkinäiseksi eikä anna suojaa lainkaan, vaikka näyttäisi toimivan. Molemmat puolet täytyy olla kunnossa.

Voiko korjaaminen katkaista oman sähköpostini?

Se voi, jos tietue jättää jonkin laillisen lähettäjän pois – esimerkiksi laskutusohjelman tai uutiskirjetyökalun. Siksi turvallinen tapa on luetella ensin kaikki palvelut, jotka lähettävät viestejä nimissäsi, julkaista pehmeä '~all' vahvistuksen ajaksi ja tiukentaa sitten kovaan hylkäykseen. Tässä järjestyksessä ei katkea mitään.

Mitä eroa on '~all' ja '-all' välillä, ja kumpi kannattaa valita?

'-all' (kova hylkäys) käskee vastaanottajia hylkäämään kaiken listalta puuttuvan – vahvin asetus. '~all' (pehmeä hylkäys) sanoo 'todennäköisesti laiton, mutta hyväksy silti'. Nykyinen parhaiden käytäntöjen suositus on '~all' yhdistettynä DMARC-politiikkaan 'reject' – tämä pari antaa saman suojan kuin '-all' ilman riskiä, että uudelleenohjatut viestit pomppaisivat takaisin. '~all' yksin ilman DMARC:ia on se heikko konfiguraatio, jota kannattaa välttää.

Estääkö SPF kaiken sähköpostihuijauksen yksin?

Ei – se on välttämätön ensimmäinen kerros, ei koko vastaus. SPF kertoo, mitkä palvelimet saavat lähettää puolestasi, mutta ei kerro vastaanottajille, mitä tehdä epäonnistuneille viesteille, eikä se suojaa näkyvää 'lähettäjä'-nimeä. Täydelliseen suojaukseen tarvitaan myös DKIM ja DMARC. SPF on nopein ja vaikuttavin ensimmäinen askel – aloita siitä ja lisää sitten muut kaksi.

Kuinka kauan voimaantulo kestää, ja maksaako se jotain?

DNS-muutokset astuvat voimaan yleensä minuuteissa tai muutamassa tunnissa. Itse korjaus on aina ilmainen – kyseessä on vain asetuksen muokkaaminen DNS-palveluntarjoajalla. Jos joku väittää, että SPF-tietueen lisääminen vaatii maksullisen tuotteen, se ei pidä paikkaansa.