SPF, DKIM ja DMARC selitettynä yrityksen näkökulmasta

SPF, DKIM ja DMARC ovat 3 DNS-tietuetta, jotka kertovat muulle internetille, mitkä palvelimet saavat lähettää sähköpostia verkkotunnuksenne nimissä ja mitä tehdä viesteille, jotka eivät läpäise näitä tarkistuksia. SPF luettelee sallitut lähettäjät, DKIM lisää jokaiseen viestiin kryptografisen allekirjoituksen, ja DMARC sitoo molemmat osoitteeseen, jonka ihmiset todella näkevät Lähettäjä-kentässä, sekä määrittää, mitä tehdään, kun tarkistus epäonnistuu.

Ilman niitä kuka tahansa voi lähettää viestin, jossa lukee From: billing@yourcompany.com, eikä monilla sähköpostipalveluilla ole juuri syytä epäillä sitä. Kun ne on määritetty oikein, väärennetty viesti ei läpäise todennusta, ja se voidaan hylätä tai ohjata roskapostiin, ennen kuin asiakkaanne lukee sen.

Hyvä uutinen: kaikki 3 ovat kenen tahansa luettavissa olevia DNS-tietueita, joten voitte tarkistaa omanne muutamassa minuutissa alla olevilla komennoilla.

SPF: kuka saa lähettää verkkotunnuksenne nimissä

SPF (Sender Policy Framework, RFC 7208) on verkkotunnuksenne TXT-tietue, joka luettelee palvelimet ja palvelut, joilla on lupa lähettää postia sen nimissä. Tyypillinen tietue näyttää tältä:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Loppuosa on tärkein:

• -all (fail): mitään luettelon ulkopuolista ei ole valtuutettu.
• ~all (softfail): kaikki luettelon ulkopuolinen on epäilyttävää.
• ?all (neutral): tietue ei ota kantaa, joten vastaanottajalla ei ole juuri mitään, minkä varassa toimia.
• +all: jokainen internetin palvelin saa lähettää nimissänne. Tämä ei ole koskaan oikein.

SPF:llä on myös ehdoton raja: tietuettanne arvioiva vastaanottaja saa tehdä enintään 10 DNS-hakua mekanismeille, kuten include, a, mx ja redirect (RFC 7208, kohta 4.6.4). Jokainen uusi markkinointityökalu lisää yhden include-merkinnän, ja kun määrä ylittää 10, SPF-tarkistus päättyy virheeseen hyväksynnän sijaan.

DKIM: allekirjoitus jokaisessa viestissä

DKIM:ssä (DomainKeys Identified Mail, RFC 6376) lähettävä palvelin allekirjoittaa jokaisen viestin yksityisellä avaimella. Vastaava julkinen avain on DNS:ssä valitsimen (selector) nimen alla, joten vastaanottaja voi varmistaa, ettei viestiä ole muutettu ja että sen on allekirjoittanut avaimenne haltija.

Jokaisen palvelun, joka lähettää puolestanne (sähköpostipalvelu, CRM, laskutustyökalu), pitäisi allekirjoittaa omalla valitsimellaan. DNS-tietue näyttää tältä:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DKIM:n puuttuminen ei näy päällepäin. Posti lähtee edelleen allekirjoittamattomana, eikä kukaan huomaa mitään, ennen kuin viestit alkavat päätyä roskapostiin tai palveluntarjoaja kiristää sääntöjään.

DMARC: käytäntö, joka yhdistää kaiken

DMARC määritellään nykyään standardissa RFC 9989, joka julkaistiin toukokuussa 2026 ja korvasi vanhemman RFC 7489:n. Se tarkistaa, läpäisikö SPF tai DKIM tarkistuksen verkkotunnuksella, joka vastaa näkyvää Lähettäjä-osoitetta (kohdistus eli alignment), ja kertoo vastaanottajille, mitä tehdä, kun kumpikaan ei läpäise:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

• p=none: pelkkä seuranta. Tarkistuksessa epäonnistunut posti toimitetaan tavalliseen tapaan, saatte vain raportteja.
• p=quarantine: epäonnistunutta postia tulee pitää epäilyttävänä, yleensä se ohjataan roskapostiin.
• p=reject: epäonnistunut posti tulee hylätä.

rua-osoitteeseen tulee koosteraportteja suurilta sähköpostipalveluilta (miten DMARC-koosteraporttia luetaan). Raportit näyttävät jokaisen lähteen, joka lähettää postia nimissänne, myös ne, jotka olette unohtaneet, ja ne, jotka eivät ole teidän.

Miten tarkistatte oman verkkotunnuksenne

Ajakaa nämä missä tahansa päätteessä (korvatkaa example.com omalla verkkotunnuksellanne):

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

DKIM:ää varten tarvitsette valitsimen nimen. Avatkaa mikä tahansa yrityksenne lähettämä sähköposti, katsokaa viestin alkuperäinen lähdekoodi ja etsikää DKIM-Signature: ja sen s=-arvo. Samat otsakkeet näyttävät myös rivin Authentication-Results:, jossa on spf=pass, dkim=pass ja dmarc=pass tai epäonnistumiset.

Mitä etsiä:

1. Täsmälleen yksi SPF-tietue (2 v=spf1-tietuetta rikkoo SPF:n kokonaan).
2. SPF:n loppuosa ~all tai -all, ei ?all tai +all.
3. DKIM-allekirjoitus jokaisen puolestanne lähettävän palvelun postissa.
4. DMARC-tietue, joka on olemassa ja jossa on rua-osoite, jota joku todella lukee.
5. Suunnitelma siirtyä käytännöstä p=none käytäntöön p=quarantine tai p=reject.

Yleiset virheet ja niiden korjaus

2 SPF-tietuetta. Ylimääräinen tietue jää usein jäljelle palveluntarjoajan vaihdosta. Yhdistäkää ne yhdeksi tietueeksi.

Liian monta hakua. Poistakaa palvelut, joita ette enää käytä, ja korvatkaa include-merkinnät tarkoilla osoitealueilla, jos palveluntarjoajanne sallii sen.

Unohtuneet lähettäjät. Uutiskirjetyökalu tai asiakastukijärjestelmä, joka lähettää ilman DKIM:ää, ei läpäise DMARCia, kun otatte pakottavan käytännön käyttöön. Lukekaa DMARC-raportteja ensin muutaman viikon ajan ja ottakaa sitten DKIM käyttöön jokaiselle oikealle lähteelle.

Jääminen pysyvästi tasolle p=none. Seuranta on oikea ensimmäinen askel, mutta p=none pyytää vastaanottajia toimittamaan väärennetynkin postin. Kun raportit osoittavat, että kaikki aito posti läpäisee, siirtykää tasolle p=quarantine ja sitten p=reject.

Pysäköidyt ja käyttämättömät verkkotunnukset. Verkkotunnusta, joka ei koskaan lähetä postia, voi silti väärentää. Julkaiskaa sille v=spf1 -all ja DMARC-tietue, jossa on p=reject.

Nämä tietueet vaikuttavat myös toimitettavuuteen. Gmail, Yahoo ja Outlook vaativat niitä nykyään joukkolähettäjiltä, mistä kerromme artikkelissa Gmailin ja Yahoon lähettäjävaatimukset. Ne ovat myös yksi puolustuskerros väärennettyjen laskujen huijauksia vastaan, joita kuvaamme artikkelissa miten yrityssähköpostihuijaus toimii.

Lyhyt tarkistuslista

• Yksi SPF-tietue, loppuosa ~all tai -all, alle 10 hakua.
• DKIM-allekirjoitus käytössä jokaisessa nimissänne lähettävässä palvelussa.
• DMARC julkaistu, raportit menevät seurattuun postilaatikkoon.
• Käytäntö etenee kohti tasoa p=reject, kun raportit ovat puhtaita.
• Pysäköidyt verkkotunnukset lukittu asetuksilla -all ja p=reject.

Miten Datahorses auttaa

Sähköpostin todennus on yksi alueista, joita valvomme ulkoapäin joka päivä yhdessä verkkotunnustenne, varmenteidenne ja verkkosivustonne kanssa. Kun SPF-tietue muuttuu, DKIM-valitsin katoaa tai DMARCia heikennetään, ihminen tarkistaa muutoksen ja saatte tarkat ohjeet tietueiden korjaamiseen. Katsokaa koko luettelo kohdasta mitä valvomme ja se, miksi emme tarvitse pääsyä järjestelmiinne. Laajemman kuvan saatte artikkelista mitä ulkoisen hyökkäyspinnan valvonta on.