Täydellinen sähköpostitodennuksen käyttöönotto: SPF, DKIM ja DMARC nollasta p=reject-tasolle

Sähköposti on edelleen yleisin väylä organisaatioihin kohdistuvissa hyökkäyksissä. Verizon Data Breach Investigations Report mukaan kalastelu ja sosiaalinen manipulointi ovat mukana valtaosassa tietoturvaloukkauksia, ja useimmat näistä alkavat väärennetyllä lähettäjän osoitteella. Kolme DNS-pohjaista todennusstandardia — SPF, DKIM ja DMARC — on luotu tekemään verkkotunnuksesi väärentämisestä teknisesti havaittavaa ja täydessä täytäntöönpanossa hylättävää.

Tämä opas on kirjoitettu IT-päälliköille, joiden on vietävä organisaatio — jolla on uutiskirjeitä, CRM, asiakaspalvelujärjestelmä, laskutusohjelmisto ja markkinointialusta, jotka kaikki lähettävät postia yrityksen verkkotunnukselta — nollasta täyteen DMARC-käytäntöön p=reject, menettämättä yhtäkään oikeaa viestiä. Varaudu 6–10 viikon projektiin, joka vaatii vain muutaman tunnin käytännön työtä viikossa.

Miten kolme protokollaa liittyvät toisiinsa

Ennen DNS-asetuksiin koskemista on tärkeää ymmärtää perusmalli, sillä useimmat epäonnistuneet käyttöönotot johtuvat alignment-käsitteen väärinymmärtämisestä.

• SPF (RFC 7208) julkaisee DNS-tietueessa listan IP-osoitteista, joilla on lupa lähettää postia käyttäen verkkotunnustasi SMTP-kuoressa (MAIL FROM).
• DKIM (RFC 6376) allekirjoittaa viestit kryptografisesti yksityisellä avaimella; julkinen avain julkaistaan DNS:ssä. Vastaanottaja varmentaa allekirjoituksen varmistaakseen, ettei viestiä ole muokattu ja että se on kyseisen verkkotunnuksen valtuuttama.
• DMARC (RFC 7489) yhdistää nämä kaksi. Se kertoo vastaanottajalle: "jos viesti väittää olevansa peräisin verkkotunnukseltani näkyvässä From:-otsakkeessa, sen on läpäistävä SPF tai DKIM alignment-vaatimuksen mukaisesti — ja tässä on toimintaohje, jos se ei läpäise, sekä raportointiosoite."

Todennusprosessi vastaanottavalla sähköpostipalvelimella näyttää tältä:

            Saapuva viesti, jonka From: billing@example.com
                                 |
              +------------------+------------------+
              |                                     |
        SPF-tarkistus                          DKIM-tarkistus
   Onko lähettävä IP-osoite               Vahvistuuko d=-allekirjoitus
   example.com:n SPF-tietueessa           DNS:n julkista avainta vasten?
   kuorilähettäjälle?
              |                                     |
              +------------------+------------------+
                                 |
                          DMARC-alignment
        Täsmääkö todennuksen läpäissyt verkkotunnus (SPF:n kuoriverkkotunnus,
        DKIM:n d=-verkkotunnus) näkyvään From:-verkkotunnukseen?
                                 |
              +------------------+------------------+
              |                                     |
         PASS: toimita                    FAIL: käytä käytäntöä
                                          p=none  -> toimita, raportoi
                                          p=quarantine -> roskapostiin
                                          p=reject -> hylkää viesti

Kriittinen yksityiskohta: viesti voi läpäistä SPF- ja DKIM-tarkistuksen jollekin verkkotunnukselle ja silti epäonnistua DMARC-tarkistuksessa, koska DMARC vaatii, että läpäisevä verkkotunnus on linjassa (aligned) käyttäjän näkemän From:-otsakkeen kanssa. Juuri tämä pysäyttää kalastelijat, jotka allekirjoittavat viestit oman verkkotunnuksensa DKIM-avaimella.

Vaihe 0 — Kartoita jokainen laillinen lähettäjä (viikko 1)

Yleisin syy sähköpostien katoamiseen DMARC-käyttöönotossa on unohtunut lähetyspalvelu. Ennen kuin julkaiset mitään, tee lähettäjäkartoitus. Haastattele markkinoinnin, myynnin, talouden ja HR:n tiimejä ja tarkista DNS:n olemassa olevat include:-mekanismit.

Tyypillinen kartoitus 50 hengen yritykselle:

Kaksi peukalosääntöä tästä vaiheesta:

1. Kaikki, mikä ei tue DKIM:ää, tulisi siirtää todennetun välityspalvelimen (kuten Workspace SMTP relay tai palvelut kuten Postmark tai SES) kautta sen sijaan, että lähetettäisiin suoraan web-palvelimelta.
2. Älä arvaile. Seuraava DMARC-valvontavaihe löytää sen, mikä haastatteluissa jäi huomaamatta — juuri sitä varten se on.

Vaihe 1 — Julkaise oikea SPF-tietue (viikko 1–2)

SPF on yksi TXT-tietue verkkotunnuksesi juuressa. Kerää include-mekanismit kunkin tarjoajan ohjeista ja yhdistä ne yhdeksi tietueeksi — verkkotunnuksella saa olla täsmälleen yksi SPF-tietue; kaksi tietuetta aiheuttaa pysyvän virheen (permerror) ja estää SPF:n toiminnan.

example.com.  IN TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.hubspot.com ip4:203.0.113.25 ~all"

Keskeiset päätökset:

• Käytä ~all (softfail), älä -all, käyttöönoton aikana. DMARC ei vaadi -all-merkintää toimiakseen, ja -all yhdistettynä puutteelliseen kartoitukseen palauttaa lailliset sähköpostit heti. Voit tiukentaa sen -all-muotoon, kun valvonta varmistaa, että kartoitus on täydellinen.
• Pysy alle 10 DNS-haun rajoissa. Jokainen include, a, mx ja redirect-mekanismi kuluttaa haun; yli kymmenen määrä aiheuttaa permerror-virheen (RFC 7208 §4.6.4). Laske myös sisäkkäiset haut (pelkkä Googlen include kuluttaa kolme). Jos olet lähellä rajaa, käytä SPF-tiivistystä (flattening) varoen tai siirrä suuret lähettäjät aliverkkotunnukselle.
• Käytä ip4:/ip6:-merkintöjä hallitsemillesi palvelimille a:-mekanismien sijaan — ne eivät kuluta hakuja.

Validoi tarkistustyökalulla (esim. FortifyNetin MX & email security tool) ja dig-komennolla:

dig +short TXT example.com | grep spf1

Vaihe 2 — Ota DKIM käyttöön kaikkialla (viikko 2–3)

DKIM-asetukset riippuvat palveluntarjoajasta, mutta noudattavat samaa kaavaa: tarjoaja luo avainparin, sinä julkaiset julkisen avaimen osoitteessa selector._domainkey.example.com, ja tarjoaja aloittaa allekirjoittamisen.

• Google Workspace: Hallintapaneeli → Sovellukset → Gmail → Sähköpostin todennus. Luo 2048-bittinen avain (1024-bittiset ovat heikkoja; NIST ja M3AAWG suosittelevat 2048-bittisiä). Julkaise TXT-tietue, odota DNS-päivitystä ja klikkaa "Käynnistä todennus".
• Microsoft 365: Defender-portaali → Sähköpostin todennusasetukset → DKIM. Microsoft käyttää kahta CNAME-tietuetta (selector1, selector2), mikä mahdollistaa automaattisen avainten kierrätyksen.
• Mailchimp, HubSpot, Zendesk jne.: jokaisella on "authenticate your domain" -velho, joka antaa 2–4 CNAME-tietuetta.

Tarkista jokainen valitsin julkaisun jälkeen:

dig +short TXT google._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

Lähetä testi Gmail-osoitteeseen, avaa "Näytä alkuperäinen" ja varmista, että näet DKIM: PASS with domain example.com — "with domain"-osa on se linjaus (alignment), jonka DMARC tarkistaa.

Suunnittele avainten kierrätys 6–12 kuukauden välein. CNAME-pohjaiset ratkaisut hoitavat tämän puolestasi; manuaalisille avaimille kannattaa luoda muistutus tietoturvakalenteriin heti, sillä kukaan ei muista tätä myöhemmin.

Vaihe 3 — DMARC valvontatilassa (viikko 3–4)

Julkaise DMARC-tietue osoitteessa _dmarc.example.com käytännöllä p=none. Tämä ei muuta sähköpostin kulkua — se vain kytkee raportoinnin päälle.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r"

Mitä kukin tägi tekee:

Käytännön huomioita:

• Käytä erillistä postilaatikkoa tai vielä parempaa, DMARC-raporttien käsittelijää — raakamuotoiset raportit ovat gzip-pakattuja XML-tiedostoja, joita tulee suurilta vastaanottajilta päivittäin. Ilmaisversiot yleisistä analyysityökaluista riittävät yhdelle verkkotunnukselle.
• Jos raportointiosoite on eri verkkotunnuksella kuin valvottava kohde, raportointiverkkotunnuksen on julkaistava ulkoinen vahvistustietue (RFC 7489 §7.1).
• Anna valvonnan pyöriä vähintään kaksi täyttä viikkoa, mieluiten neljä, jotta kuukausittaiset ajot (laskutukset, johdon raportit) näkyvät datassa.

Vaihe 4 — Lue raportit ja korjaa virheet (viikko 4–6)

Koostetut raportit vastaavat kolmeen kysymykseen jokaisesta lähettävästä IP-osoitteesta: paljonko postia, läpäisikö SPF, läpäisikö DKIM. Lajittele ne kolmeen ryhmään:

1. Linjassa läpäissyt (SPF tai DKIM): terve tilanne. Valtaosan Workspace/M365-postista pitäisi olla tässä heti alusta alkaen.
2. Oma palvelu, linjaus epäonnistuu: esim. CRM läpäisee DKIM-tarkistuksen, mutta allekirjoittaa d=crm-provider.com-osoitteella. Korjaa suorittamalla kyseisen palvelun todennusvelho, jotta se allekirjoittaa sinun verkkotunnuksellasi. Tämä ryhmä on Phase 4 -työjonosi.
3. Tuntemattomat IP-osoitteet, kaikki epäonnistuu: tämä on väärennystä (tai edelleenlähetystä). Älä yritä korjata tätä — täytäntöönpano neutraloi nämä. Näiden olemassaolo on liiketoimintaperuste koko projektille.

Yksi laillinen lähde epäonnistuu aina: postituslistat ja tietyt välityspalvelimet rikkovat SPF:n (uusi lähettävä IP) ja joskus DKIM:n (alaviite lisätään). ARC (RFC 8617) auttaa suurilla vastaanottajilla, mutta rehellinen vastaus on, että pieni virheprosentti (selvästi alle 1%) on normaali ja hyväksyttävä täytäntöönpanossa.

Vaihe 5 — Siirtyminen täytäntöönpanoon (viikko 6–10)

Älä koskaan hyppää suoraan p=none-tasosta p=reject-tasoon. Käytä pct-tägiä porrastamiseen:

Seuraa joka vaiheessa kahta signaalia: koosteraportteja (läpäisyasteen pitäisi pysyä tasaisena) ja asiakaspalvelua (tikettejä aiheesta "asiakas sanoo postin palautuneen"). Peruutus on yksi DNS-muutos takaisin edelliseen vaiheeseen — aseta TTL 3600 sekuntiin rampin aikana, jotta virheet on helppo korjata.

Kun saavutat p=reject-tason, viimeistele työ:

• Lisää eksplisiittinen aliverkkotunnusten käytäntö: sp=reject, ellei jokin aliverkkotunnus vaadi väljempiä sääntöjä.
• Suojaa parkkeeratut verkkotunnukset, joista et lähetä postia: anna jokaiselle v=spf1 -all, tyhjä DKIM-käytäntö ja v=DMARC1; p=reject. Parkkeeratut tunnukset ovat väärentäjien suosikkikohde.
• Harkitse BIMI-tunnusta (brändilogo sähköpostiohjelmiin) — se vaatii DMARC-toteutuksen, joten olet juuri avannut mahdollisuuden sen käyttöön.

Vianmäärityksen pikaopas

Käyttöönotto pähkinänkuoressa

Lisää tämä taulukko projektitikettiin; jokainen rivi on luonteva viikoittainen tilannepäivitys johdolle, ja "Tulos"-sarake pitää projektin rehellisenä siitä, mitä "valmis" tarkoittaa kussakin vaiheessa.

DMARC:n jälkeen — MTA-STS ja TLS-RPT

DMARC todentaa lähettäjän; se ei kerro, kulkiko viesti salattuna. SMTP siirtyy edelleen salaamattomaan tilaan, jos TLS-neuvottelu epäonnistuu, ja verkkotason hyökkääjä voi pakottaa tämän epäonnistumisen. Kaksi täydentävää standardia korjaavat tämän aukon, ja koska olet jo DNS-konsolissa, nyt on oikea viikko ottaa ne käyttöön.

MTA-STS (RFC 8461) antaa verkkotunnuksesi ilmoittaa "toimita posti minulle vain suojattua TLS-yhteyttä käyttäen". Se koostuu DNS-tietueesta ja pienestä HTTPS:n kautta tarjottavasta käytäntötiedostosta:

_mta-sts.example.com.  IN TXT  "v=STSv1; id=20260828T000000"

https://mta-sts.example.com/.well-known/mta-sts.txt:
  version: STSv1
  mode: testing
  mx: mail.example.com
  max_age: 86400

Aja testing-tilaa kaksi viikkoa, vaihda sitten mode: enforce ja nosta max_age arvoon 604800. mx-rivien on täsmättävä todellisiin MX-palvelinnimiin täysin — kirjoitusvirhe tässä hylkää saapuvan postin enforce-tilassa hiljaisesti, minkä vuoksi testing-vaihe on olemassa.

TLS-RPT (RFC 8460) on MTA-STS:n raportointikanava, samoin kuin rua-raportointi DMARC:lle:

_smtp._tls.example.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Lähettäjät, jotka eivät pysty toimittamaan postia TLS-yhteydellä, kertovat syyn päivittäin koneellisesti luettavassa JSON-muodossa. Käytännössä raportit ovat hiljaisia — mikä on juuri se vahvistus, jonka haluat ennen pakottamista.

Koosteraportin lukeminen käsin

Jopa analyysityökalun kanssa, lue yksi raakadata-raportti kerran, jotta data lakkaa olemasta musta laatikko. Pakatun XML-tiedoston sisällä jokainen record-lohko sisältää kolme tärkeää asiaa:

<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

Lue se lauseena: "198.51.100.7 lähetti 412 viestiä väittäen olevansa example.com; SPF linjassa, DKIM ei; nykyisellä käytännöllä ei tehty mitään." Tarkista IP-osoite (reverse DNS ja palveluntarjoajan alueet), niin tiedät, kuuluuko tämä ryhmään 1, 2 vai 3. Kymmenen minuuttia yhden raportin parissa opettaa enemmän kuin mikään dashboard-esittely.

Hallinnointi — käytännön ylläpito

Sähköpostitodennus ei ole projekti, jolla on päättymispäivä; se on pysyvä ominaisuus. Leivo nämä osaksi normaalia toimintaa ennen tiketin sulkemista:

• DNS-muutosten valvonta: jokainen uusi SaaS-työkalu, joka "vain tarvitsee lähettää postia meidän nimissämme", menee sinun kauttasi, saa DKIM:n kuntoon ja lisätään lähettäjätaulukkoon. Vaihtoehtona on, että markkinointi ottaa työkalun käyttöön marraskuussa ja sen posti päätyy hiljaisesti roskapostiin p=reject-sääntösi vuoksi.
• Neljännesvuosittainen tarkistus: vartti vuosineljänneksessä analyysityökalun skannaamiseen uusien epäonnistuvien lähteiden varalta. Kalenteroi tämä.
• Tietueiden valvonta: SPF-, DKIM- ja DMARC-tietueet voivat rikkoutua viattomassa DNS-migraatiossa. Ulkoinen valvonta, joka hälyttää muutoksista (kuten FortifyNetin domain-valvonta), muuttaa hiljaisen regression saman päivän korjaukseksi.
• Poistaminen: kun lähetyspalvelu lopetetaan, poista sen include- ja DKIM-tietueet samalla viikolla. Vanhentuneet tiedot ovat sekä haittana haun budjetille että toimitusketjun riski: jos tarjoajan IP-avaruus vapautuu, kuka tahansa sen saa, voi lähettää todennettua postia sinuna.

Viimeinen tarkistuslista

• Lähettäjäkartoitus hyväksytetty markkinoinnilla, taloudella ja tuella
• Tasan yksi SPF-tietue, alle 10 hakua, päättyy ~all (myöhemmin -all)
• DKIM 2048-bit, validoitu per valitsin, kierrätys aikataulutettu
• DMARC p=none rua-raportoinnilla, 2–4 viikon data analysoitu
• Kaikki lailliset lähettäjät linjattu (ryhmä 2 tyhjä)
• Ramppi: quarantine 10% → 50% → 100% → reject, vähintään viikko per vaihe
• sp=reject asetettu; parkkeeratut verkkotunnukset lukittu
• Suorita täysi FortifyNet-skannaus varmistaaksesi tietueiden puhtauden

Lähteet

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• RFC 7489 — Domain-based Message Authentication, Reporting & Conformance (DMARC)
• M3AAWG Email Authentication Best Practices
• Google Workspace — Set up DMARC
• Microsoft 365 — Use DMARC to validate email
• Verizon Data Breach Investigations Report