Lopeta DNS:n arvaileminen: kehittäjäystävällinen kierros MX-, SPF-, DKIM- ja DMARC-tietueisiin

Miksi sähköpostin DNS-tietueilla on nyt merkitystä

Sähköpostin todennus oli ennen valinnaista. Vuonna 2026 se on perusvaatimus. Gmail ja Outlook edellyttävät sekä SPF:ää että DKIM:iä joukkolähettäjiltä, ja DMARC:sta on nopeasti tulossa pakollinen kaikille verkkotunnuksille, jotka lähettävät transaktiosähköpostia. Jos DNS-tietueesi ovat väärin, viestisi eivät saavu perille — ei palautusta, ei varoitusta, vain hiljaisuus.

Ongelma on, että nämä tietueet on dokumentoitu kuin RFC:t, ei kuin työkalut. Useimmat kehittäjät kopioivat esimerkit sähköpostipalveluntarjoajansa asennusohjeesta ja toivovat parasta. Se toimii siihen asti, kunnes pitää selvittää ongelmaa, lisätä toinen lähetyspalvelu tai selittää asiakkaalle, miksi yhteydenottolomakkeen viestit päätyvät roskapostiin.

Tämä opas käy läpi MX-, SPF-, DKIM- ja DMARC-tietueet siinä järjestyksessä, jossa niihin käytännössä törmäät. Mukana on tarpeeksi yksityiskohtia oikeaan määrittämiseen ja tarpeeksi taustaa vianmääritykseen, kun jokin hajoaa.

MX-tietueet: minne saapuva sähköposti menee

MX-tietueet kertovat internetille, mitkä postipalvelimet vastaanottavat sähköpostia verkkotunnuksellesi. Ne ovat nelikosta yksinkertaisimmat, mutta myös helpoimmat määrittää väärin.

MX-tietueessa on kaksi osaa: prioriteettiluku ja isäntänimi. Pienempiä prioriteettilukuja kokeillaan ensin. Jos käytät Google Workspacea, MX-tietueesi voivat näyttää tältä:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Lopun pisteillä on merkitystä — ne ilmaisevat, että isäntänimi on täysin määritelty. Useimmat DNS-palveluntarjoajat lisäävät ne automaattisesti, mutta eivät kaikki.

Yleisiä virheitä: MX-tietueiden osoittaminen A-tietueeseen isäntänimen sijaan, kaikkien prioriteettien asettaminen samaan lukuun (mikä tekee varapalvelimista turhia) tai vanhojen MX-tietueiden poistamisen unohtaminen palveluntarjoajaa vaihdettaessa. Vanhentuneet MX-tietueet eivät vain jää harmittomasti paikalleen — ne voivat aiheuttaa postisilmukoita tai jakaa toimituksen kahteen eri postilaatikkoon.

Jos ylläpidät omaa yhteydenottolomaketta ja haluat välttää roskapostia turvautumatta kolmannen osapuolen palveluihin, lomakkeiden roskapostivektoriksi muuttumisen ymmärtäminen on hyödyllinen lähtökohta.

SPF: mitkä palvelimet saavat lähettää nimissäsi

SPF (Sender Policy Framework) on TXT-tietue, joka luettelee IP-osoitteet ja verkkotunnukset, joilla on oikeus lähettää sähköpostia verkkotunnuksesi puolesta. Se on ensimmäinen tarkistus, jonka useimmat postipalvelimet tekevät vastaanottaessaan viestin, joka väittää olevansa sinulta.

Perusmuotoinen SPF-tietue näyttää tältä:

v=spf1 include:_spf.google.com ~all

Puretaan se osiin:

• v=spf1 ilmoittaa SPF-version
• include:_spf.google.com delegoi Googlen SPF-tietueeseen
• ~all on pehmeä hylkäys — hylkää luettelemattomista lähteistä tuleva posti, mutta älä ole liian tiukka

Voit käyttää myös ip4:- tai ip6:-mekanismeja tiettyjen osoitteiden sallimiseen tai a- ja mx-mekanismeja viittaamaan verkkotunnuksesi A- ja MX-tietueisiin. Lopussa oleva all-mekanismi määrittää, mitä tapahtuu viesteille lähteistä, joita et listannut: -all on kova hylkäys (reject), ~all on pehmeä hylkäys (merkitse epäilyttäväksi), ?all on neutraali (ei kantaa) ja +all sallii kaiken (älä käytä tätä).

SPF:ssä on kaksi terävää reunaa. Ensinnäkin se hajoaa, kun sähköposti välitetään eteenpäin, koska välittävä palvelin ei ole SPF-tietueessasi. Toiseksi SPF-tietueilla on kymmenen DNS-kyselyn hakuraja. Jos sisällytät liian monta kolmannen osapuolen palvelua, ylität rajan ja SPF lakkaa toimimasta. Korjaus on litistää SPF-tietue — korvata include:-direktiivit todellisilla IP-alueilla — mutta tämä vaatii ylläpitoa, kun palveluntarjoajat muuttavat IP-osoitteitaan.

DKIM: kryptografinen todiste lähettäjän identiteetistä

DKIM (DomainKeys Identified Mail) lisää digitaalisen allekirjoituksen lähtevään sähköpostiisi. Vastaanottava palvelin tarkistaa allekirjoituksen DNS:ssä julkaistua julkista avainta vasten. Jos allekirjoitus on kelvollinen eikä viestiä ole muutettu matkalla, DKIM läpäisee tarkistuksen.

Toisin kuin SPF, DKIM kestää edelleenlähetyksen, koska allekirjoitus kulkee viestin mukana. Se on myös joustavampi — eri lähetyspalveluille voi olla useita DKIM-avaimia, joista jokaisella on oma valitsimensa.

DKIM-DNS-tietue näyttää tältä:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Valitsin (default tässä esimerkissä) on vapaavalintainen — sähköpostipalveluntarjoajasi valitsee sen. p=-arvo on julkinen avain, yleensä pitkä base64-koodattu merkkijono. Sähköpostipalveluntarjoajasi luo yksityisen avaimen ja käyttää sitä lähtevien viestien allekirjoittamiseen.

DKIM-asetukset hoitaa lähes aina sähköpostipalveluntarjoajasi. Sinun tehtäväsi on kopioida heidän antamansa TXT-tietue ja liittää se DNS:ään. Hankala kohta on, että jotkut DNS-palveluntarjoajat eivät käsittele pitkiä TXT-tietueita hyvin — ne joko katkaisevat ne tai edellyttävät arvon jakamista useisiin lainausmerkeissä oleviin merkkijonoihin.

Voit varmistaa DKIM:n toiminnan lähettämällä testiviestin Gmail-osoitteeseen ja tarkistamalla otsakkeet. Etsi dkim=pass Authentication-Results-otsakkeesta.

DMARC: käytännön valvonta ja raportointi

DMARC (Domain-based Message Authentication, Reporting and Conformance) sitoo SPF:n ja DKIM:n yhteen ja kertoo vastaanottaville palvelimille, mitä tehdä, kun todennus epäonnistuu. Se mahdollistaa myös raportoinnin, joten näet, kuka lähettää sähköpostia verkkotunnuksesi nimissä — sekä aidosti että väärennetysti.

Minimaalinen DMARC-tietue näyttää tältä:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none tarkoittaa pelkkää seurantaa — älä hylkää tai siirrä karanteeniin epäonnistuneita viestejä
• rua=mailto:[email protected] määrittää, mihin koontiraportit lähetetään

Kun olet varma, että SPF ja DKIM toimivat, voit kiristää käytännöksi p=quarantine (ohjaa epäonnistumiset roskapostiin) tai p=reject (palauta ne suoraan). Voit myös määrittää aliverkkotunnuskäytännön sp=-asetuksella ja määrittää pct=-asetuksella, mihin prosenttiosuuteen viesteistä käytäntöä sovelletaan.

DMARC-raportit ovat XML-tiedostoja, joita suuret vastaanottajat lähettävät päivittäin. Ne ovat laveita ja raakana vaikealukuisia, mutta kertovat tarkasti, mitkä viestit läpäisivät tai eivät läpäisseet todennusta ja miksi. Jos näet aitoja viestejä hylättävän, raportit näyttävät, mikä SPF- tai DKIM-tarkistus epäonnistuu.

Yksi kompastuskivi: DMARC edellyttää kohdistusta. SPF:n kohdalla Return-Path-otsakkeen verkkotunnuksen on vastattava From-otsakkeen verkkotunnusta (tai oltava sen aliverkkotunnus). DKIM:n kohdalla DKIM-allekirjoituksen d=-verkkotunnuksen on vastattava From-verkkotunnusta. Jos käytät kolmannen osapuolen lähetyspalvelua, sen on tuettava mukautettuja palautuspolkuja tai DKIM-allekirjoitusta sinun verkkotunnuksellasi, ei omallaan.

Nykyisten asetusten auditointi

Useimmat DNS-ongelmat ovat näkymättömiä, kunnes ne aiheuttavat häiriön. Näin tarkistat tietueesi ennen kuin jokin hajoaa:

1. Kysy MX-tietueet: dig MX example.com pitäisi palauttaa postipalvelimesi isäntänimet ja prioriteetit. Varmista, että ne vastaavat sähköpostipalveluntarjoajasi dokumentaatiota.

1. Tarkista SPF-syntaksi: dig TXT example.com ja etsi v=spf1-tietue. Aja se SPF-validaattorin läpi syntaksivirheiden ja hakurajan ylitysten löytämiseksi.

1. Varmista DKIM-avaimet: Lähetä testiviesti ja tarkista DKIM-Signature-otsake. Poimi valitsin ja verkkotunnus ja kysy sitten dig TXT selector._domainkey.example.com varmistaaksesi, että julkinen avain on olemassa.

1. Validoi DMARC-käytäntö: dig TXT _dmarc.example.com pitäisi palauttaa DMARC-tietueesi. Varmista, että rua= osoittaa osoitteeseen, jota oikeasti seuraat.

1. Testaa päästä päähän: Käytä esimerkiksi mail-tester.com-palvelua tai lähetä viesti Gmail-osoitteeseen ja tarkista täydet otsakkeet. Etsi spf=pass, dkim=pass ja dmarc=pass Authentication-Results-otsakkeesta.

Jos selvität, miksi viestit eivät saavu perille, otsakkeet ovat paras työkalusi. Useimmat sähköpostiohjelmat antavat tarkastella raakamuotoisia otsakkeita — Gmailissa avaa viesti, napsauta kolmea pistettä ja valitse 'Näytä alkuperäinen'. Authentication-Results-otsake kertoo tarkasti, mikä tarkistus epäonnistui ja miksi.

Milloin aliverkkotunnuskäytäntöjä kannattaa käyttää

Jos lähetät sähköpostia useista aliverkkotunnuksista — esimerkiksi newsletter.example.com markkinointiin ja app.example.com transaktioviesteihin — voit määrittää aliverkkotunnuskohtaisia DMARC-käytäntöjä. Näin voit käyttää tiukkoja käytäntöjä hallitsemissasi aliverkkotunnuksissa ja pitää pääverkkotunnuksen käytännön väljemmän.

Haittapuoli on monimutkaisuus. Jokainen aliverkkotunnus tarvitsee omat SPF-, DKIM- ja DMARC-tietueensa, ja sinun on seurattava, mitkä lähetyspalvelut on valtuutettu millekin aliverkkotunnukselle. Useimmille pienille tiimeille yksi hyvin määritetty verkkotunnus on yksinkertaisempi ja yhtä turvallinen.

Mitä tehdä, kun todennus hajoaa

Yleisin vikatilanne on uuden lähetyspalvelun lisääminen päivittämättä DNS:ää. Jos alat käyttää uutta transaktiosähköpostipalveluntarjoajaa, sinun on lisättävä heidän SPF-include tai IP-alueensa, määritettävä DKIM-allekirjoitus verkkotunnuksellasi ja varmistettava DMARC-kohdistus.

Toiseksi yleisin ongelma on edelleenlähetys. Jos käyttäjät välittävät sähköpostisi toiseen osoitteeseen, SPF epäonnistuu, koska välittävä palvelin ei ole SPF-tietueessasi. DKIM yleensä kestää edelleenlähetyksen, joten kunhan DKIM läpäisee tarkistuksen ja DMARC-käytäntösi sallii osittaisen kohdistuksen, viestin pitäisi silti mennä perille. Jos näet edelleenlähetettyä postia hylättävän, tarkista DMARC-käytäntösi — p=reject yhdessä tiukan kohdistuksen kanssa rikkoo edelleenlähetyksen.

Kolmas ongelma on DNS:n propagointi. DNS-tietueiden muutosten leviämisessä voi kestää tunteja, ja eri postipalvelimet välimuistittavat tietueita eri pituisia aikoja. Jos olet juuri päivittänyt tietueen eikä se toimi, odota muutama tunti ja testaa uudelleen. Voit tarkistaa propagoinnin esimerkiksi whatsmydns.net-työkalulla.

Keskeiset opit

• MX-tietueet reitittävät saapuvan postin; SPF, DKIM ja DMARC todentavat lähtevän postin. Ne ratkaisevat eri ongelmia, ja tarvitset ne kaikki neljä.
• SPF hajoaa edelleenlähetyksessä ja sillä on kymmenen haun raja. DKIM kestää edelleenlähetyksen, mutta vaatii palvelukohtaisen määrityksen. DMARC sitoo ne yhteen ja mahdollistaa raportoinnin.
• Aloita DMARC:ssa asetuksella p=none, seuraa raportteja muutaman viikon ajan ja kiristä sitten arvoon p=quarantine tai p=reject, kun olet varma, että aito posti läpäisee tarkistukset.
• DNS-virheet ovat hiljaisia. Testaa määrityksesi oikealla sähköpostilla ja tarkista otsakkeista, että SPF, DKIM ja DMARC läpäisevät tarkistukset.
• Jos todennus hajoaa uuden lähetyspalvelun lisäämisen jälkeen, tarkista SPF-include-määritykset, DKIM-valitsimet ja DMARC-kohdistus. Otsakkeet kertovat, mikä tarkistus epäonnistui.

FAQ

Q: Voinko käyttää useita SPF-tietueita?

A: Et. Useat SPF-tietueet johtavat siihen, että ne kaikki jätetään huomiotta. Jos sinun täytyy valtuuttaa useita palveluja, käytä include:-direktiivejä yhdessä SPF-tietueessa tai listaa IP-alueet suoraan. Muista kymmenen haun raja.

Q: Tarvitsenko DMARC:n, jos lähetän vain muutaman sähköpostin päivässä?

A: Kyllä. DMARC:ssa ei ole kyse volyymista — vaan siitä, että todistat olevasi se, joka väität olevasi. Myös pienet verkkotunnukset hyötyvät DMARC:sta, koska se estää väärentämistä ja antaa näkyvyyttä toimitusongelmiin. Aloita asetuksella p=none ja raportointiosoitteella.

Q: Mitä tapahtuu, jos sekä DKIM että SPF epäonnistuvat, mutta viesti näyttää aidolta?

A: Se riippuu DMARC-käytännöstäsi. Jos käytössä on p=none, posti toimitetaan varoituksen kanssa. Jos käytössä on p=quarantine, se menee roskapostiin. Jos käytössä on p=reject, se palautetaan. Siksi DMARC-raportteja kannattaa seurata ennen tiukan käytännön käyttöönottoa — sinulla voi olla aitoja lähettäjiä, joista et tiennyt.

Q: Voinko käyttää samaa DKIM-avainta useille verkkotunnuksille?

A: Teknisesti kyllä, mutta älä tee niin. Jokaisella verkkotunnuksella pitäisi olla oma DKIM-avainparinsa. Avainten jakaminen vaikeuttaa kierrätystä ja kasvattaa vaikutusalaa, jos yksityinen avain vaarantuu.

Q: Kuinka usein DKIM-avaimet pitäisi kierrättää?

A: Yleispätevää sääntöä ei ole, mutta kerran vuodessa on kohtuullista useimmille verkkotunnuksille. Jos epäilet avaimen vaarantuneen, kierrätä se heti. Varmista, että julkaiset uuden julkisen avaimen DNS:ssä ennen kuin alat allekirjoittaa uudella yksityisellä avaimella, ja jätä vanha avain DNS:ään muutamaksi päiväksi kierrätyksen jälkeen viivästyneiden viestien käsittelemiseksi.

<!-- tool-cta:start -->

💡 Kokeile tätä: Tarkista minkä tahansa verkkotunnuksen julkaistu käytäntö DMARC Lookup -työkalulla nähdäksesi, miten MX-, SPF- ja DMARC-tietueet sopivat käytännössä yhteen.

<!-- tool-cta:end -->

Lähteet

• RFC 7208: Sender Policy Framework (SPF) — SPF-määrittely, mukaan lukien syntaksisäännöt ja kymmenen haun raja.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM-määrittely, joka kattaa allekirjoituksen luonnin ja tarkistuksen.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC-määrittely, mukaan lukien käytäntösyntaksi ja koontiraportoinnin muoto.
• Google Workspace: Prevent spoofing and spam — Käytännön ohjeita SPF-, DKIM- ja DMARC-määrityksiin Google Workspace -verkkotunnuksille.