Guides 6 min lukuaika

SPF, DKIM ja DMARC selitettynä: näin otat ne käyttöön rikkomatta sähköpostia

SPF, DKIM ja DMARC ratkaisevat, päätyykö sähköpostisi saapuneisiin ja voiko joku muu lähettää viestejä verkkotunnuksesi nimissä. Mitä kukin tietue tekee, miten ne otetaan käyttöön turvallisesti ja mitkä virheet rikkovat toimituksen huomaamatta.

SPF, DKIM ja DMARC ovat kolme DNS-tietuetta, jotka ratkaisevat kaksi asiaa: päätyykö lähettämäsi sähköposti saapuneisiin ja voiko joku muu lähettää viestejä, jotka näyttävät tulevan sinulta. Gmail, Yahoo ja Outlook.com vaativat nykyään kaikki kolme jokaiselta joukkopostia lähettävältä, ja ilman niitä viestit päätyvät muillakin todennäköisemmin roskapostiin.

Tietueet ovat lyhyitä, mutta niihin on helppo tehdä pieniä virheitä, ja ne hajoavat varoittamatta, kun jokin uusi työkalu alkaa lähettää postia puolestasi. Tämä opas kertoo, mitä kukin tietue tekee, miten ne otetaan käyttöön oikeassa järjestyksessä ja miten pidät ne kunnossa.

Miten ne toimivat yhdessä

Jokaisessa sähköpostissa on kaksi lähettäjäosoitetta: kirjekuoren lähettäjä, jonne postipalvelimet palauttavat palautusviestit, ja vastaanottajan näkemä From-osoite. Huijaukset perustuvat näiden väliseen aukkoon: kuka tahansa voi kirjoittaa mitä tahansa From-osoitteeksi. Nämä kolme tietuetta sulkevat aukon.

SPF (Sender Policy Framework) luettelee palvelimet, jotka saavat lähettää postia verkkotunnuksesi nimissä.

DKIM (DomainKeys Identified Mail) lisää jokaiseen viestiin kryptografisen allekirjoituksen, jonka vastaanottaja tarkistaa DNS:ssäsi olevaa julkista avainta vasten.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sitoo ne näkyvään From-osoitteeseen ja kertoo vastaanottajille, mitä tarkistuksessa epäonnistuneelle postille tehdään.

SPF: kuka saa lähettää

SPF-tietue on verkkotunnuksesi TXT-tietue. Siinä luetellaan palvelut ja palvelimet, jotka lähettävät postia puolestasi, ja lopussa kerrotaan, mitä kaikelle muulle tehdään:

example.com. TXT ”v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 ~all”

include: lisää toisen verkkotunnuksen SPF-tietueen. Näin postipalvelulle yleensä annetaan lupa.

ip4: ja ip6: sallivat tietyt osoitteet, kuten oman postipalvelimesi.

~all (soft fail) tai -all (fail) kertoo, mitä tapahtuu kaikille, joita ei ole lueteltu. Älä koskaan käytä +all-määritystä, joka sallii koko internetin.

Kaksi sääntöä kompastuttaa useimmat verkkotunnukset:

Vain yksi tietue. Verkkotunnuksella saa olla täsmälleen yksi SPF-tietue. Jos niitä on kaksi, vastaanottajat palauttavat pysyvän virheen ja SPF epäonnistuu jokaisen viestin kohdalla. Kun uusi palvelu neuvoo ”lisäämään tämän SPF-tietueen”, lisää sen include nykyiseen tietueeseesi.

Enintään 10 DNS-hakua. Jokainen include, a, mx ja redirect vie yhden haun, ja myös includejen sisällä olevat includet lasketaan. Yli kymmenellä SPF epäonnistuu. Tietue, jossa on Google Workspace, uutiskirjetyökalu, CRM ja asiakastukipalvelu, voi ylittää rajan kenenkään huomaamatta.

SPF:llä on heikkous: se tarkistaa kirjekuoren lähettäjän eikä vastaanottajan näkemää From-osoitetta, ja se hajoaa, kun posti välitetään eteenpäin. Siksi se ei yksin riitä.

DKIM: allekirjoitus jokaiseen viestiin

DKIM:ssä postipalvelusi allekirjoittaa jokaisen viestin yksityisellä avaimella. Julkinen avain on DNS:ssä nimen alla, jota kutsutaan valitsimeksi (selector):

google._domainkey.example.com. TXT ”v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…”

Vastaanottaja lukee valitsimen viestin DKIM-Signature-otsakkeesta, hakee avaimen ja tarkistaa, ettei viesti ole muuttunut matkalla. DKIM-allekirjoitus säilyy edelleenlähetyksessä, joten se on näistä kahdesta luotettavampi.

Jokainen puolestasi postia lähettävä palvelu tarvitsee oman DKIM-määrityksensä, yleensä hallinta-asetuksissa kohdassa ”authentication” tai ”verified domain”. Käytä 2048-bittisiä avaimia, jos palvelu tarjoaa niitä. 1024-bittiset avaimet toimivat yhä, mutta ne ovat vähimmäistaso, ja lyhyemmät hylätään. Kun palvelu vaihtaa avaimensa, uuden valitsimen on oltava DNS:ssäsi ennen käyttöönottoa, tai allekirjoitukset epäonnistuvat.

DMARC: sido se From-osoitteeseen

DMARC on TXT-tietue verkkotunnuksesi nimessä _dmarc:

_dmarc.example.com. TXT ”v=DMARC1; p=none; rua=mailto:dmarc@example.com”

Se tekee kaksi asiaa, joihin SPF ja DKIM eivät yksin pysty.

Ensinnäkin se vaatii yhdenmukaisuutta (alignment). Viesti läpäisee DMARCin vain, kun SPF tai DKIM läpäistään samalle verkkotunnukselle kuin näkyvä From-osoite. Uutiskirje, joka lähetetään palvelun kautta, joka allekirjoittaa omalla verkkotunnuksellaan, läpäisee DKIM:n, mutta ei sinun verkkotunnuksellesi, joten DMARC epäonnistuu. Siksi jokaisen palvelun on allekirjoitettava sinun verkkotunnuksellasi.

Toiseksi se määrittää käytännön postille, joka epäonnistuu:

p=none: toimita normaalisti. Mikään ei muutu, mutta vastaanottajat voivat lähettää sinulle raportteja.

p=quarantine: siirrä roskapostiin.

p=reject: hylkää.

rua-tagi pyytää vastaanottajia lähettämään päivittäiset koosteraportit valitsemaasi osoitteeseen. Niistä näkyy, mitkä palvelimet lähettivät postia verkkotunnuksesi nimissä ja läpäisikö se tarkistukset. Näin löydät lähettäjät, jotka olit unohtanut.

Ota ne käyttöön oikeassa järjestyksessä

Suoraan p=reject-tasolle siirtyminen on klassinen tapa estää omien laskujen tai salasanan palautusviestien perillemeno. Etene vaiheittain:

Listaa kaikki, mikä lähettää postia verkkotunnuksesi nimissä. Sähköpostipalvelusi, uutiskirjetyökalu, CRM, asiakastuki, ajanvarausjärjestelmä, verkkokauppa-alusta, verkkosivuston yhteydenottolomake ja jokainen ilmoituksia lähettävä palvelin.

Määritä DKIM jokaiselle niistä omalla verkkotunnuksellasi kunkin palvelun ohjeiden mukaan.

Rakenna yksi SPF-tietue, jossa ovat sitä tarvitsevat palvelut, alle 10 hakua ja lopussa ~all.

Julkaise DMARC käytännöllä p=none ja rua-osoitteella, ja anna sen olla kahdesta neljään viikkoa.

Korjaa jokainen epäonnistuva oikea lähettäjä, yleensä palvelu, joka allekirjoittaa yhä omalla verkkotunnuksellaan.

Siirry tasolle p=quarantine, halutessasi määrityksellä pct=25, jolloin aloitat neljänneksestä epäonnistuvaa postia, ja sitten tasolle p=reject, kun mikään oikea posti ei enää epäonnistu.

Myös verkkotunnukset, jotka eivät koskaan lähetä sähköpostia, ansaitsevat suojan, koska niitä on helppo väärentää. Anna niille tietue, joka kertoo tämän:

example.org. TXT ”v=spf1 -all”
_dmarc.example.org. TXT ”v=DMARC1; p=reject”

Virheet, jotka rikkovat sähköpostin huomaamatta

Uutta palvelua varten lisätty toinen SPF-tietue, kun include olisi pitänyt lisätä ensimmäiseen.

SPF-tietue, joka ylitti 10 hakua, kun siihen lisättiin vielä yksi työkalu.

Uutiskirje tai CRM, joka lähettää omalla DKIM-verkkotunnuksellaan, jolloin DMARC epäonnistuu kelvollisesta allekirjoituksesta huolimatta.

DKIM-avain, joka vaihdettiin palveluntarjoajalla mutta jota ei koskaan julkaistu DNS:ssä.

DMARC-tietue, jossa on kirjoitusvirhe, kuten p=rejected, jonka vastaanottajat jättävät huomiotta.

Siirtyminen tasolle p=reject ennen kuin on varmistettu, että jokainen lähettäjä läpäisee tarkistukset.

Muuttunut MX-tietue tai estolistalle joutunut postipalvelin, mikä heikentää toimitusta tietueista riippumatta.

Mikään näistä ei tuota virhettä, jonka näkisit. Posti vain alkaa mennä roskapostiin, ja kuulet siitä viikkoja myöhemmin, kun asiakas kertoo, ettei lasku koskaan tullut perille.

Tarkista tietueesi

Voit tarkistaa verkkotunnuksesi heti ilmaisella SPF-, DKIM- ja DMARC-tarkistimellamme. Se lukee tietueet DNS:stä, laskee SPF:n haut, etsii DKIM-avaimia yleisimmistä valitsimista ja kertoo, mitä pitää korjata, sekä antaa tietueen valmiiksi liitettäväksi.

Tänään oikein olevat tietueet hajoavat, kun joku lisää palvelun ensi kuussa. Uptimecheckin sähköpostin todennuksen valvonta tarkistaa SPF:n, DKIM:n ja DMARCin verkkotunnusvalvonnoissasi kahdesti päivässä, selittää jokaisen ongelman selkokielellä, antaa sen korjaavan DNS-tietueen ja hälyttää vain, kun uusi ongelma ilmenee. Se myös tarkistaa itse ylläpitämiesi postipalvelinten osoitteet estolistoilta, jotta listaus ei jää huomaamatta. Lisää se verkkotunnusten valvontaan, joka jo kertoo, ennen kuin itse verkkotunnus vanhenee.

Tarkistuslista

Listaa jokainen palvelu, joka lähettää sähköpostia verkkotunnuksesi nimissä.

Määritä DKIM omalla verkkotunnuksellasi jokaiseen niistä, mahdollisuuksien mukaan 2048-bittisenä.

Pidä yksi SPF-tietue, alle 10 hakua, lopussa ~all tai -all.

Julkaise DMARC tasolla p=none ja raporttiosoitteella.

Korjaa jokainen oikea lähettäjä, jonka yhdenmukaisuus epäonnistuu.

Siirry tasolle p=quarantine ja sitten p=reject.

Suojaa postia lähettämättömät verkkotunnukset määrityksillä v=spf1 -all ja p=reject.

Tarkista tietueet säännöllisesti ja aina, kun uusi työkalu alkaa lähettää postia puolestasi.

Kysymykset

Tarvitsenko kaikki kolme?

Käytännössä kyllä. Gmail, Yahoo ja Outlook.com vaativat SPF:n, DKIM:n ja DMARCin jokaiselta joukkopostia lähettävältä, ja ilman niitä viestit päätyvät muillakin todennäköisemmin roskapostiin. Yhdessä ne myös estävät muita lähettämästä sähköpostia, joka näyttää sinun lähettämältäsi.

Voiko minulla olla kaksi SPF-tietuetta?

Ei. Verkkotunnuksella on oltava täsmälleen yksi SPF-tietue. Jos niitä on kaksi, vastaanottajat tulkitsevat SPF:n pysyväksi virheeksi ja se epäonnistuu jokaisen viestin kohdalla. Yhdistä ne yhdeksi tietueeksi.

Mitä tapahtuu, kun SPF tarvitsee yli 10 hakua?

SPF palauttaa pysyvän virheen ja epäonnistuu, myös oikean postisi kohdalla. Poista palvelut, joita et enää käytä, korvaa includet ip4-osoitealueilla, jos palveluntarjoaja sen sallii, tai siirrä osa lähetyksistä aliverkkotunnukseen.

Riittääkö p=none?

Se on oikea paikka aloittaa, koska se ei muuta toimitusta mitenkään sillä aikaa, kun tarkistat, että kaikki postisi läpäisee tarkistukset. Se ei kuitenkaan suojaa verkkotunnustasi väärentämiseltä. Siirry tasolle quarantine ja sitten reject, kun jokainen oikea lähettäjä läpäisee tarkistukset.

Tarkistaako Uptimecheck SPF:n, DKIM:n ja DMARCin?

Kyllä. Verkkotunnusvalvonnat tarkistavat ne kahdesti päivässä, selittävät jokaisen ongelman selkokielellä ja antavat sen korjaavan DNS-tietueen. Ilmainen DMARC-tarkistin osoitteessa uptimecheck.com tekee samat tarkistukset kerran, ilman tiliä.

Jatka lukemista

Guides 6 min lukuaika

SSL-varmenteiden voimassaolo lyhenee 47 päivään: mitä tehdä

Julkisten TLS-varmenteiden voimassaolo on rajattu 200 päivään 15. maaliskuuta 2026 alkaen, sitten 100 ja 47 päivään. Aikataulu, mikä muuttuu verkkotunnuksen validoinnissa ja tarkistuslista valmistautumiseen.

Luku

Katkot ovat menneisyyttä.

Luo ensimmäinen valvontasi alle minuutissa – tai tutustu ensin live-demoon.

14 päivän ilmainen kokeilu · Sen jälkeen ilmainen 5 valvonnalle · Ei luottokorttia