SPF: kuka saa lähettää
RFC 7208 lähtee havainnosta: mikään sähköpostiprotokollassa ei estä palvelinta ilmoittamasta mitä tahansa lähettäjän osoitetta. SPF:n avulla verkkotunnuksen omistaja voi julkaista DNS:ssä luettelon palvelimista, jotka saavat lähettää sen nimissä, ja vastaanottava palvelin voi tarkistaa tämän luvan.
Kaksi tarkennusta muuttaa kaiken:
- SPF tarkistaa kirjekuoriosoitteen (palvelinten välisen keskustelun osoitteen, ns. ”MAIL FROM”) ja palvelimen ilmoittaman nimen, ei osoitetta, jonka vastaanottaja lukee ”Lähettäjä”-kentästä.
- SPF arvioi viimeisen palvelimen, joka toimitti viestin. Kun toinen palvelin välittää viestin edelleen, sitä ei enää toimita alkuperäisen verkkotunnuksen valtuuttama palvelin: tarkistus voi epäonnistua, vaikka viesti on aito.
Verkkotunnus julkaisee vain yhden SPF-tietueen. Kaikki lähetyslähteet on lueteltava siinä: sähköposti, laskutusohjelmisto, uutiskirjetyökalu, CRM ja sähköpostiin skannaava monitoimilaite.
DKIM: viesti on allekirjoitettu
RFC 6376:n mukaan DKIM antaa allekirjoittavan verkkotunnuksen omistajalle mahdollisuuden ottaa osittainen vastuu viestistä kryptografisen allekirjoituksen avulla. Julkinen avain on DNS:ssä. Allekirjoituksen tarkistaminen osoittaa, että allekirjoitetut osat eivät ole muuttuneet allekirjoituksen jälkeen.
Allekirjoitus kulkee viestin mukana. Se kestää siis välityksen tai edelleenlähetyksen paremmin kuin SPF, kunhan välittäjä ei muuta aihetta tai sisältöä. Postituslista, joka lisää viestin loppuun maininnan, rikkoo sen.
Mitä DKIM ei saman RFC:n mukaan tee: se ei salaa viestiä, epäonnistuminen ei velvoita hylkäämään sitä, eikä allekirjoittavan verkkotunnuksen tarvitse olla sama kuin ”Lähettäjä”-kentässä näkyvä. Juuri tämän aukon DMARC paikkaa.
DMARC: kohdistus ja politiikka
RFC 7489 määrittelee DMARC:n keinoksi, jolla verkkotunnuksen omistaja voi ilmaista verkkotunnustason politiikan. Mekanismi perustuu kohdistukseen (alignment): ”Lähettäjä”-kentässä näkyvän osoitteen verkkotunnuksen on vastattava SPF:n tai DKIM:n vahvistamaa verkkotunnusta. Jos kumpikaan ei ole kohdistettu, DMARC epäonnistuu.
Verkkotunnus julkaisee silloin toiveensa:
- none: toimenpiteitä ei pyydetä, tilannetta seurataan;
- quarantine: viestiä käsitellään epäilyttävänä;
- reject: viesti hylätään.
DMARC määrittelee myös raportit: koosteraportit, jotka tiivistävät, mitkä palvelimet ovat lähettäneet verkkotunnuksen nimissä ja millä tuloksella, sekä viestikohtaiset virheraportit. Niiden avulla löytyy unohtunut työkalu, joka lähettää puolestanne, tai joku, joka väärentää verkkotunnustanne.
| Mekanismi | Mitä se tarkistaa | Mitä se ei katso |
|---|
| SPF | Viestin toimittava palvelin on valtuutettu kirjekuoren verkkotunnukselle | Näytetty osoite, sisältö |
| DKIM | Allekirjoitettua viestiä ei ole muutettu; verkkotunnus ottaa siitä vastuun | Näytetty osoite, sisällön rehellisyys |
| DMARC | Näytetty verkkotunnus on kohdistettu SPF:n tai DKIM:n kanssa; politiikka epäonnistumisen varalle | Samannäköiset verkkotunnukset, näyttönimi, teksti |
Pysäyttääkö DMARC tietojenkalastelun?
Se pysäyttää osan verkkotunnuksen väärentämisestä, ei tietojenkalastelua yleisesti. RFC 7489 sanoo sen suoraan: DMARC ei käsittele visuaalisesti samankaltaisia verkkotunnuksia eikä näyttönimen väärinkäyttöä, ja sisällön analyysi on sen soveltamisalan ulkopuolella. Se ei pyri ratkaisemaan kaikkia vilpillisen postin ongelmia.
Käytännössä DMARC ei näe:
- samannäköistä verkkotunnusta: huijari todentaa moitteettomasti oman verkkotunnuksensa, joka muistuttaa teidän verkkotunnustanne;
- väärennettyä näyttönimeä: ”Kirjanpito” kirjoittaa osoitteesta, jolla ei ole mitään yhteyttä yritykseen;
- murrettua tiliä, joka allekirjoittaa oikein, koska lähettäjä on aito palvelin;
- viestiä, jolla ei ole yhteyttä verkkotunnukseenne: kuljetusyhtiön väärä ilmoitus tulee verkkotunnuksesta, jolla ei ole mitään tekemistä teidän verkkotunnuksenne kanssa;
- verkkotunnusta ilman politiikkaa: jos jäljitelty verkkotunnus julkaisee ”none”, vastaanottajalla ei ole hylkäysohjetta.
Nämä tapaukset kuuluvat muille analyyseille: verkkotunnusten samankaltaisuus, maine, sisältö ja käyttäytyminen. Katso roskaposti, tietojenkalastelu, haittaohjelmat ja murrettu tili.
Edelleenlähetykset ja postituslistat: ARC
Edelleenlähetys rikkoo usein SPF:n, viestiä muuttava lista rikkoo DKIM:n, ja DMARC epäonnistuu silloin aidolle viestille. RFC 8617:ssä (kokeellinen asema) kuvattu ARC antaa jokaiselle välittäjälle mahdollisuuden vahvistaa havaitsemansa todennustuloksen. Lopullinen palvelin voi päättää ottaa sen huomioon.
Oman verkkotunnuksen suojaaminen ja saapuvan postin suodatus
Nämä kaksi asiaa sekoitetaan usein.
- Lähettävän verkkotunnuksen suojaaminen: SPF:n, DKIM:n ja DMARC:n julkaiseminen verkkotunnuksellenne, jotta muut voivat hylätä sitä väärentävät viestit. Te julkaisette; vastaanottajat soveltavat.
- Saapuvan postin suodatus: muiden verkkotunnusten tietueiden tarkistaminen vastaanottamassanne postissa ja sen jälkeen kaikki muut analyysit.
Vaiheittainen käyttöönotto
- Kartoitus kaikesta, mikä lähettää verkkotunnuksen nimissä.
- Yksi SPF-tietue, joka sallii ne; DKIM-allekirjoitus jokaiselle palvelulle, joka pystyy allekirjoittamaan.
- DMARC tilassa ”none” ja osoite raporttien vastaanottoon.
- Raporttien lukeminen useiden viikkojen ajan; unohtuneiden lähteiden korjaaminen.
- Siirtyminen tilaan ”quarantine” ja sitten ”reject”, kun kaikki aidot lähetykset on kohdistettu.
Esimerkki havainnollistukseksi. Toimisto julkaisee DMARC:n tilassa ”none” ja lukee ensimmäiset raporttinsa. Niistä paljastuu kolme lähdettä: sen sähköposti, joka on kohdistettu oikein; sen laskutusohjelmisto, joka lähettää laskut toimiston verkkotunnuksella ilman DKIM-allekirjoitusta; ja tuntematon ulkomainen palvelin, joka lähettää satoja viestejä sen nimissä. Toimisto korjaa laskutusohjelmiston, odottaa puhtaan raporttijakson ja siirtyy tilaan ”quarantine”: DMARC:ia soveltavat vastaanottajat käsittelevät nyt tuntemattoman palvelimen viestejä epäilyttävinä.
Kun sähköpostijärjestelmää vaihdetaan, nämä tietueet valmistellaan ennen MX-tietueen muutosta. Opas sähköpostin migraatio ilman käyttökatkoa kuvaa tämän vaiheen; sitä ei toisteta tässä.
Usein kysyttyä
Suojaako DMARC-politiikka ”none”?
Ei. Sen avulla voi seurata tilannetta raporttien kautta. Suojaus alkaa politiikoista ”quarantine” ja ”reject”.
Miksi aito viesti epäonnistuu DMARC-tarkistuksessa?
Useimmiten syynä on edelleenlähetys, postituslista tai palvelu, joka lähettää puolestanne olematta ilmoitettu SPF:ssä ja allekirjoittamatta DKIM:llä.
Sähköpostimme ei allekirjoita DKIM:llä: mitä tehdä?
Lähetysten reitille sijoitettu yhdyskäytävä voi allekirjoittaa sen puolesta. Katso Nykyisen sähköpostinne suojaaminen.
Mistä näiden tarkistusten tuloksen näkee vastaanotetusta viestistä?
Viestin otsakkeista. Klytic MTA:n osalta katso Suodattimen päätöksen lukeminen ja vienti.
Klyticin asema
Klytic MTA hoitaa molemmat asiat minkä tahansa sähköpostin edessä:
- Essential ja Advanced: SPF-, DKIM- ja MX-tarkistus; DMARC-tarkistus myös edelleenlähetetyille viesteille ARC:n ansiosta; lähetysten DKIM-allekirjoitus, vaikka sähköpostinne ei sitä tekisi.
- Advanced: DMARC-konsoli, jossa ovat verkkotunnustenne raportit, hälytykset ja korjausehdotukset vaiheittaista siirtymistä kohti ”reject”-politiikkaa varten.
DMARC on vain yksi kerros: Klytic MTA lisää samannäköisten verkkotunnusten, näyttönimen ja huijauskuvioiden tunnistuksen, jota kuvataan oppaassa lähettäjän väärentäminen ja toimitusjohtajahuijaus.
Jos käytätte Klytic Mailia, SPF, DKIM ja DMARC määritetään verkkotunnuksellenne: se on lähettävän verkkotunnuksen suojaus. Klytic MTA:n puolestaan voi tilata Klytic Mailin kanssa tai ilman sitä.
Lähteet
Tarkistettu lokakuussa 2026.
- RFC 7208, SPF: verkkotunnuksen omistaja julkaisee isännät, jotka saavat käyttää sen verkkotunnusta ”MAIL FROM”- tai ”HELO”-identiteetissä, ja vastaanottaja tarkistaa tämän luvan. rfc-editor.org
- RFC 6376, DKIM: verkkotunnus ottaa vastuun viestistä kryptografisella allekirjoituksella; ei salausta, ei pakollista hylkäystä, allekirjoittava verkkotunnus voi poiketa näytetystä laatijasta. rfc-editor.org
- RFC 7489, DMARC: ”From”-verkkotunnuksen kohdistus SPF:n tai DKIM:n kanssa, politiikat none, quarantine ja reject, kooste- ja virheraportit; visuaalisesti samankaltaiset verkkotunnukset, näyttönimi ja sisällön analyysi soveltamisalan ulkopuolella. rfc-editor.org
- RFC 9989 (toukokuu 2026), joka korvaa RFC 7489:n: samat politiikka-arvot ja samat rajaukset (samannäköiset verkkotunnukset, näyttönimi). rfc-editor.org
- RFC 8617, ARC (kokeellinen): todennettu välitysketju; DMARC-vastaanottaja voi hyväksyä kelvollisen ARC-ketjun välittämät arviot. rfc-editor.org
- Klytic, Klytic MTA -sivu: Essential- ja Advanced-pakettien todennustarkistukset, lähtevän postin DKIM-allekirjoitus ja DMARC-konsoli, lisäpalvelut, käyttöönottotavat, käyttöönotto MX-tietueen kautta. klytic.com
