SPF-tietueen syntaksi: mekanismit, määreet ja rajat

SPF-tietue on yksi ainoa DNS:n TXT-tietue verkkotunnuksesi juuressa. Se alkaa merkinnällä v=spf1, luettelee palvelimet, jotka saavat lähettää postia nimissäsi, ja päättyy all-mekanismiin, joka kertoo vastaanottajille, mitä tehdä kaikelle muulle. v=spf1 include:_spf.google.com ~all on täydellinen ja kelvollinen tietue. Kaikki muu SPF-syntaksissa on muunnelmia näistä kolmesta osasta - sekä joukko kovia rajoja, jotka rikkovat äänettömästi tietueita, jotka muuten näyttävät oikeilta.

Ne rajat merkitsevät enemmän kuin useimmat odottavat. DMARCguard skannasi 27. helmikuuta 2026 yhteensä 5 499 028 Tranco-listan verkkotunnusta ja havaitsi, että 56,0 % julkaisee SPF-tietueen - enemmän kuin DMARC (30,4 %) tai DKIM (22,7 %) - mutta että 4,8 % näistä SPF-tietueista, 148 655 verkkotunnusta, ylittää RFC 7208:n asettaman kymmenen DNS-haun katon ja siten epäonnistuu arvioinnissa kokonaan.

Jokaisen SPF-tietueen kolme osaa

Jokainen kelvollinen tietue jakautuu samalla tavalla:

v=spf1  ip4:203.0.113.10  include:_spf.google.com  -all
  |            |                    |               |
versio     mekanismi           mekanismi        kaikki muut

1. Versiotunniste. v=spf1 on oltava ensimmäinen termi ja sen on täsmättävä täsmälleen. Mikä tahansa muu tarkoittaa, ettei tietue ole lainkaan SPF-tietue.
2. Mekanismit. Ne arvioidaan tiukasti vasemmalta oikealle. Ensimmäinen mekanismi, joka täsmää yhdistävään IP-osoitteeseen, ratkaisee tuloksen ja arviointi päättyy heti - järjestys ei ole kosmeettinen seikka.
3. Loppumekanismi. all-mekanismi viimeisenä terminä. Kaikki all-merkinnän jälkeen julkaistu ohitetaan.

Yksi asia kannattaa sanoa täsmällisesti: SPF tarkistaa kuoren lähettäjän eli SMTP-komennon MAIL FROM (Return-Path) sekä HELO-identiteetin. Se ei tarkista From:-otsaketta, jonka vastaanottaja todella näkee. Tämän aukon paikkaaminen on DMARC:n tehtävä, ja siksi ne otetaan aina käyttöön yhdessä. Jos hahmottelet vielä kokonaisuutta, DNS-suojauksen konfigurointioppaamme käy läpi, miten SPF, DKIM, DMARC ja DNSSEC nivoutuvat yhteen.

SPF:llä oli aikoinaan oma DNS-tietuetyyppinsä (tyyppi 99). RFC 7208 §3.1 poisti sen käytöstä huhtikuussa 2014 - julkaise SPF vain TXT-tietueena.

SPF-mekanismit: täydellinen viite

Yksi yksityiskohta menee usein väärin: include: ei ole tekstin liittämistä. Se suorittaa täyden, erillisen SPF-arvioinnin sisällytetylle verkkotunnukselle ja täsmää vain, jos arviointi palauttaa pass. Sisällytetyn tietueen -all ei siis hylkää postiasi - se vain estää include:-mekanismia täsmäämästä, ja arviointi jatkuu seuraavaan mekanismiisi.

Määreet: neljä merkkiä, jotka ratkaisevat tuloksen

Jokaisella mekanismilla voi olla määre-etuliite. RFC 7208 §4.6.2 määrittelee niitä täsmälleen neljä, ja oletus on +.

Älä koskaan julkaise merkintää +all. Se valtuuttaa koko internetin lähettämään nimissäsi ja on suoraan huonompi kuin ettei SPF-tietuetta olisi lainkaan.

Muuttajat: redirect ja exp

Muuttajat ovat nimi–arvo-pareja eivätkä mekanismeja, ja kumpikin saa esiintyä vain kerran.

• redirect=example.com korvaa tietueesi tuloksen kokonaan kohdeverkkotunnuksen SPF-tuloksella. Se maksaa yhden DNS-haun ja ohitetaan täysin, jos all-mekanismi on mukana, joten näiden kahden ei pitäisi esiintyä yhdessä.
• exp=explain.example.com osoittaa TXT-tietueeseen, joka sisältää ihmisluettavan selitystekstin fail-tapauksessa. Se ei maksa hakua arviointihetkellä.

Rajat, jotka rikkovat muuten kelvolliset tietueet

Täällä asuu suurin osa todellisista SPF-vioista. Kaikki alla oleva tulee suoraan RFC 7208 §3.4:stä ja §4.6.4:stä:

• Kymmenen DNS-kyselevää termiä. Mekanismit include, a, mx, ptr ja exists sekä muuttaja redirect kuluttavat kukin yhden. Kymmenen ylittäminen TÄYTYY palauttaa permerror - kova virhe, ei varoitus. all, ip4, ip6 ja exp ovat ilmaisia.
• Kaksi tyhjää hakua. Kysely, joka palauttaa NXDOMAIN tai tyhjän vastauksen, on "void lookup". Toteutusten tulisi rajoittaa nämä kahteen; rajan ylitys tuottaa myös permerror-tuloksen. Unohtuneet include:-merkinnät palveluille, joita ette enää käytä, ovat tavallisin syyllinen.
• Kymmenen osoitetietuetta per mx tai ptr. Kokonaisbudjetin lisäksi kukin yksittäinen MX-palvelin on rajattu kymmeneen A/AAAA-tietueeseen.
• Yksi tietue per verkkotunnus. Jos haku palauttaa useamman kuin yhden v=spf1-tietueen, tulos on permerror. Yhdistä ne yhdeksi tietueeksi; älä koskaan julkaise kahta.
• 255 merkkiä per merkkijono, 450 oktettia suositeltu kokonaisuus. TXT-tietue voi sisältää useita lainausmerkeissä olevia merkkijonoja, jotka yhdistetään ilman välilyöntejä. RFC 7208 §3.4 suosittaa pitämään koko DNS-vastauksen alle 450 oktetissa, jotta se mahtuu UDP-pakettiin.
• Kahdenkymmenen sekunnin arviointibudjetti. Vastaanottajien tulisi sallia vähintään 20 sekuntia ja palauttaa sen jälkeen temperror.

Minne kymmenen hakuasi todella menevät

Jokainen lisäämäsi ulkopuolinen lähettäjä maksaa vähintään yhden haun, ja osa maksaa enemmän, koska niiden omat tietueet sisältävät lisää include-merkintöjä.

Kuusi tai seitsemän palvelua, ja olet katossa. Korjaukset tärkeysjärjestyksessä: poista include-merkinnät palveluilta, jotka olette lopettaneet, siirrä lähettäjät omille aliverkkotunnuksille omine SPF-tietueineen, ja harkitse vasta sen jälkeen include-merkintöjen litistämistä kirjaimellisiksi ip4:-alueiksi - litistäminen poistaa hakuja mutta siirtää palveluntarjoajien IP-muutosten seurannan sinulle.

SPF-tietueen julkaisevien verkkotunnusten osuus verkkotunnuspäätteittäin. Lähde: DMARCguard, "State of Email Authentication 2026", 5 499 028 Tranco-verkkotunnuksen skannaus, 27. helmikuuta 2026.

Viisi syntaksivirhettä, jotka aiheuttavat PermError-virheen

1. Kaksi v=spf1-tietuetta samalla nimellä. Yleistä migraation jälkeen. Yhdistä, älä pinoa.
2. all-mekanismin määre, joka on ristiriidassa tarkoituksen kanssa - ?all näyttää varovaiselta mutta ei kerro vastaanottajille mitään, joten väärennetty posti menee suoraan läpi.
3. Termit all-merkinnän jälkeen. Kaikki all-merkinnän oikealla puolella on kuollutta tekstiä.
4. Unohtunut ptr. Sitä on vieroksuttu vuodesta 2014, se on hidas ja polttaa haun ilman hyötyä.
5. Include-merkinnät lopetetuille palveluille. Ne maksavat haun kukin ja voivat muuttua tyhjiksi hauiksi, kun palveluntarjoaja poistaa tietueensa.

Näin tarkistat oman tietueesi

Lue tietue suoraan DNS:stä yhdellä kyselyllä:

dig +short TXT example.com

Windowsissa vastine on nslookup -type=TXT example.com. Etsi täsmälleen yksi merkkijono, joka alkaa merkinnällä v=spf1, ja laske sen jälkeen hakuja kuluttavat termit käsin - muista laskea myös ne, jotka piileksivät jokaisen include:-merkinnän sisällä.

Helmikuusta 2024 lähtien Google ja Yahoo ovat vaatineet massalähettäjiltä (noin 5 000 viestiä päivässä tai enemmän) todennusta sekä SPF:llä että DKIM:llä sekä vähintään p=none-tason DMARC-tietuetta. Rikkinäisen SPF-tietueen permerror vaarantaa tämän vaatimustenmukaisuuden, joten se kannattaa varmistaa eikä olettaa.

Aja ilmainen 60 sekunnin FortifyNet-skannaus, niin tarkistamme SPF-tietueesi yhdessä DKIM:n, DMARC:n, TLS-asetustesi, tietoturvaotsakkeiden ja dark web -altistumisen kanssa - ilman rekisteröitymistä.

Usein kysytyt kysymykset

Voiko verkkotunnuksella olla kaksi SPF-tietuetta? Ei. Jos haku palauttaa useamman kuin yhden v=spf1-tietueen, RFC 7208 §4.5 edellyttää vastaanottajalta permerror-tulosta, jolloin SPF epäonnistuu kokonaan. Yhdistä mekanismit yhteen tietueeseen.

Pitäisikö käyttää -all vai ~all? Aloita merkinnällä ~all samalla kun varmistat, että kaikki lailliset lähettäjät on lueteltu, ja siirry sitten merkintään -all. -all on vahvempi signaali väärentämistä vastaan, mutta vasta kun lähettäjäinventaariosi on todella täydellinen.

Lasketaanko ip4:-merkinnät kymmenen haun rajaan? Ei. ip4:, ip6:, all ja exp eivät aiheuta DNS-kyselyjä arviointihetkellä ja ovat vapautettuja. Vain include, a, mx, ptr, exists ja redirect lasketaan.

Estääkö SPF yksinään väärentämisen? Ei. SPF validoi kuoren lähettäjän, ei From:-otsaketta, jonka vastaanottaja lukee. Hyökkääjä voi läpäistä SPF:n hallitsemallaan verkkotunnuksella ja näyttää silti sinun tunnustasi. DMARC sitoo nämä kaksi identiteettiä yhteen, ja juuri se paikkaa aukon.

Kuinka pitkä SPF-tietue voi olla? Jokainen yksittäinen merkkijono TXT-tietueessa on rajattu 255 merkkiin, joskin useat merkkijonot yhdistetään. RFC 7208 suosittaa pitämään koko DNS-vastauksen alle 450 oktetissa, jotta se säilyy UDP-paketissa.

Aiheeseen liittyvät oppaat

• SPF-tietueen tarkistus: näin testaat, luet ja korjaat SPF:n
• DMARC-käyttöönotto vaihe vaiheelta
• Mikä on DKIM? DomainKeys Identified Mail selitettynä

---

Lähteet: RFC 7208, Sender Policy Framework (SPF) versio 1, IETF, huhtikuu 2014 (§3.1, §3.4, §4.5, §4.6.2, §4.6.4, §5.5, §6.1, §6.2) · DMARCguard, "State of Email Authentication 2026", 5 499 028 Tranco-verkkotunnuksen skannaus, 27. helmikuuta 2026 · Googlen ja Yahoon massalähettäjien vaatimukset, voimassa helmikuusta 2024.