Defaults.Exposed › Raportit

Miksi SPF:ni epäonnistuu? SaaS-palveluiden 10 DNS-haun ongelma Yhdistyneen kuningaskunnan ja EU:n lähettäjille (2026)

Julkaistu 2026-07-09

Luvut 2026-06-29 · metodologia v7. Koostetieto 261 miljoonasta arvioidusta verkkotunnuksesta. Katso miten arvioimme.

Kun SPF epäonnistuu SaaS-työkaluja käyttävältä yritykseltä Yhdistyneessä kuningaskunnassa tai EU:ssa, todennäköisin syy on yksi RFC-sääntö, jota sinun ei ole koskaan tarvinnut ajatella: yli 10 DNS-haun jälkeen SPF ei palauta “fail” — se palauttaa PermError, mikä tarkoittaa, että tietuetta käsitellään kuin sitä ei olisi olemassa. Vähintään 797,263 verkkotunnusta on jo ylittänyt tämän rajan. Lisäksi 2,119,539 on tasan 9–10 haussa — yksi uusi työkalu kaukana samasta jyrkänteestä.

Miksi SPF lakkaa toimimasta, kun lisäät SaaS-työkalun?

SPF toimii listaamalla sähköpostipalvelimet, joilla on lupa lähettää verkkotunnuksesi puolesta. Nykyaikaiset yritykset eivät pyöritä omia sähköpostipalvelimiaan — ne käyttävät Google Workspacea sisäiseen sähköpostiin, Mailchimpia kampanjoihin, HubSpotia myyntijaksoihin ja Pipedriveä CRM-viestintään. Jokainen alusta antaa sinulle include:-rivin liitettäväksi DNS:ään.

Ongelma: jokainen include: on itsessään DNS-haku. Ja jokainen tietue sisällä siinä include:ssa voi laukaista lisää hakuja rekursiivisesti. RFC 7208 §4.6.4 asettaa tiukan rajan kymmeneen. Kymmenen jälkeen vastaanottava sähköpostipalvelin lopettaa arvioinnin ja palauttaa PermError — eikä PermError ole pehmeä epäonnistuminen, joka päätyy roskapostiin. Se tarkoittaa, että SPF-tietuettasi käsitellään kuin se puuttuisi. Sähköpostin todennus epäonnistuu SPF-osaltaan.

Et näe tätä DNS-paneelissasi. Laskuri laukeaa vain live-arvioinnin aikana. Sinulla voi olla kolme include:-riviä näkyvässä tietueessasi ja silti olla kaksitoista hakua syvällä, koska jokaisen toimittajan SPF-tietue vetää mukanaan omia ali-include:jaan.

Kuinka monta verkkotunnusta on jo yli rajan?

Vähintään 797,263. Se on lukumäärä sen jälkeen, kun ratkaisimme jokaisen SPF include:-kohteen, johon viitataan 100 kertaa tai useammin — 10,842 erillistä kohdetta kattaen 95.2% kaikista include-viittauksista — ja hinnoittelimme jokaisen verkkotunnuksen koko ketjun. Pintamäärä (mitä löytäisit laskemalla vain tietueen näkyvät rivit) löytää noin 7,958. Ketjuhinnoiteltu luku on 100 kertaa suurempi, koska lähes kaikki vahinko on näkymätöntä include-kohteiden sisällä.

Tilanne, joka todennäköisimmin vaikuttaa eurooppalaiseen yritykseen:

Eurooppalaiset hosting-palveluntarjoajat ja heikot SPF-oletukset

Sillä hosting-palveluntarjoajalla, josta aloitit, on merkitystä — koska jotkut asettavat SPF-oletuksia, jotka kuluttavat jo useita kymmenestä haustasi ennen kuin yhdistät yhtäkään SaaS-työkalua.

Suurimpien hosting-palveluntarjoajien joukossa, joita eurooppalaiset verkkotunnukset käyttävät censuksessamme:

IONOS erottuu joukosta: 1.0% IONOS-hostatuista verkkotunnuksista on pakottava DMARC, mikä tarkoittaa, että suurella enemmistöllä ei ole merkityksellistä lähettäjän todennusta lainkaan. OVH-verkkotunnukset pärjäävät paremmin SPF-tiukka-asetuksessa (43.7%), mutta putoavat 2.2%:iin DMARC-pakottamisessa — SPF ilman DMARC:ia, joka kytkisi sen From:-otsikkoon, suojaa vain kirjekuoren, ei sitä, mitä vastaanottaja näkee.

Microsoft 365 on poikkeus hyvässä mielessä: 85.0% Microsoft-hostatuista verkkotunnuksista käyttää tiukkaa SPF:ää, suurelta osin siksi, että Microsoftin sähköpostivirran ohjattu asetus asettaa -all:n oletukseksi. Google Workspace asettaa ~all (softfail) oletukseksi, jättäen 92% sen verkkotunnuksista ilman tiukkaa suojaa.

SPF-virheen diagnosointi alle 60 sekunnissa

Nopein tarkistus on ilmainen työkalu, joka arvioi koko hakuketjun — ei vain näkyvää tietuetta. Suorita nslookup -type=TXT verkkotunnuksesi.com komentorivillä ja laske jokainen näkemäsi include:. Katso sitten jokainen näistä tietueista ja laske niiden. Jos sormet loppuvat ennen include:t, olet vaaravyöhykkeellä.

Luotettavampi lähestymistapa: tarkista verkkotunnuksesi täältä — skanneri arvioi koko ratkaistun ketjun, merkitsee PermError:n ja näyttää sinulle, mitkä mekanismit kuluttavat hakubudjettisi.

Kolme diagnostista tulosta:

• PermError — olet jo yli kymmenen. Jokainen lähettämäsi sähköposti epäonnistuu SPF-tarkastuksessa vastaanottajalla.
• 9–10 haussa — olet jyrkänteen reunalla. Seuraava SaaS-integraatio kaataa sinut yli.
• Softfail (~all) hardfail:n (-all) sijaan — olet rajan alla, mutta tietue on asetettu liian sallivaksi tarjoamaan todellista suojaa. Katso SPF-virheellisen konfiguraation raportti täydelliseen kuvaukseen -all vs. ~all.

SPF:n korjaaminen, kun käytät useita SaaS-työkaluja

On kolme lähestymistapaa pysyvyysjärjestyksessä:

1. Tarkasta ja karsinta. Aloita listaamalla jokainen include: nykyisessä tietueessasi. Poista kaikki alustat, joita et enää käytä — vanhat ESP:t, CRM-työkalut aiemmista sopimuksista, alustat, joita testasit mutta hylkäsit. Se on ilmaista ja palauttaa usein useita hakuja. Jokainen poistettu include: voi eliminoida 1–3 ali-hakua.

2. Litistä SPF-tietueesi. SPF-litistäminen ratkaisee kaikki include:-kohteet niiden taustalla oleviin IP-alueisiin ja kirjoittaa ne suoraan tietueeseen ip4:- ja ip6:-mekanismeina. IP-mekanismit eivät laukaise hakuja, joten litistetty tietue voi luetella kymmeniä lähetyslähteitä ja olla silti nollahaussa. Haittapuoli: sinun on litistettävä uudelleen aina, kun toimittaja päivittää lähettävät IP-osoitteensa, mikä tapahtuu ilman ennakkoilmoitusta. Useimmat organisaatiot käyttävät maksullista SPF-litistyspalvelua (PowerDMARC, EasyDMARC, Dmarcian ja muut tarjoavat tätä) tai rakentavat seurantatyöprosessin.

3. Käytä SPF-makroja. RFC 7208 -makrot mahdollistavat tietueiden rakentamisen, jotka suorittavat yhden DNS-haun per tarkistus ja vastaavat dynaamisesti, include-ketjun sijaan. Makrot edellyttävät DNS-hosting-tukea ja jonkin verran toteutustyötä, mutta ne ovat arkkitehtuurisesti puhdas ratkaisu organisaatioille, joilla on monia SaaS-lähettäjiä.

SPF:n korjaamisen jälkeen yhdistä se DMARC-pakottamiseen — SPF ilman DMARC:ia todentaa vain kirjekuoren lähettäjän, ei From:-otsikkoosoitetta, jonka vastaanottajat näkevät.

Usein kysytyt kysymykset

Miksi SPF-tietueeni läpäisee DNS-työkaluni, mutta epäonnistuu silti sähköpostiotsakkeissa? Useimmat DNS-hakutyökalut laskevat vain mekanismit, jotka näkyvät omassa tietueessasi, eivät ali-hakuja, joita nämä mekanismit laukaisevat. Sinulla voi olla kaksi include:-riviä ja olla silti yli rajan, jos jokainen toimittajan tietue sisältää useita lisää. Vain ketjuhinnoittelutyökalu (tai vastaanottava sähköpostipalvelin) laskee koko syvyyden. Tarkista verkkotunnuksesi nähdäksesi todellisen ketjumäärän.

Tarkoittaako SPF:n epäonnistuminen, että sähköpostini menevät roskapostiin? PermError (liian monta hakua) tarkoittaa, että todennuksen SPF-osa palauttaa ei-tuloksen — käytännössä puuttuvan. DMARC arvioi sekä SPF:n että DKIM:n; jos DKIM läpäisee, DMARC voi silti läpäistä SPF PermError:sta huolimatta. Jos kumpikaan ei läpäise, DMARC epäonnistuu, ja lopputulos riippuu DMARC-käytännöstäsi. p=none-asetuksella sähköposti toimitetaan edelleen, mutta epäonnistuminen kirjataan lokiin. p=quarantine- tai p=reject-asetuksella sähköposti suodatetaan tai palautetaan. Korjaa SPF, jotta et nojaa pelkästään DKIM:iin.

Kuinka monta hakua tyypillinen SaaS-pino käyttää? P99 SPF-tietue censuksessamme on jo 9 haussa — juuri rajalla — ennen mitään lisäyksiä. Google Workspace -tietue lisää 3–4 hakua; Mailchimp lisää 1–2; HubSpot lisää 1–3 riippuen nykyisestä konfiguraatiostaan. Kolme valtavirtaistyökalua plus hosting-palveluntarjoajan oletus riittää usein kaatamaan yli kymmenen.

Onko SPF-litistäminen turvallista? Kyllä, edellyttäen, että pidät sen ajan tasalla. Litistäminen muuntaa include:-ketjut staattisiksi IP-alueiksi — jos toimittaja kiertää lähettävät IP-osoitteensa eikä sinä litistä uudelleen, alat hylätä heidän postinsa. Useimmat organisaatiot käyttävät hallittua litistyspalvelua, joka valvoo IP-muutoksia manuaalisen ylläpidon sijaan.

SPF:ni on ollut tällainen vuosia — miksi se epäonnistuu yhtäkkiä? Koska toimittajasi päivittivät SPF-tietueensa, eivät sinun. Joka kerta, kun SaaS-alusta lisää uuden lähettävän IP-alueen tai sisällyttää toisen include:n, ketjukustannuksesi nousee ilman mitään muutosta omalta puoleltasi. 10-haun raja arvioidaan live-tilassa viestin vastaanottamisen yhteydessä, joten toimittajan muutos tiistai-aamuna voi rikkoa SPF:si tiistai-iltapäivään mennessä.

Parantaako SPF:n korjaaminen sähköpostin toimitettavuutta? Se poistaa todennusvirheen lähteen, joka on edellytys johdonmukaiselle toimitukselle — etenkin kun Google ja Yahoo nyt pakottavat DMARC-kohdistuksen massalähettäjille. SPF yksinään ei ole koko kuva: yhdistä se DKIM:iin ja DMARC:iin täydellistä sähköpostin todennusta varten.

Tarkista SPF:si ilmaiseksi

Jos et ole varma, onko SPF-tietueesi yli hakurajan — tai onko se asetettu liian heikosti suojaamaan verkkotunnustasi — suorita ilmainen tarkistus. Se arvioi koko ratkaistun ketjun ja näyttää sinulle tarkalleen, mihin budjetti kuluu.

Tarkista verkkotunnuksesi → · Korjaa SPF → · SPF PermError -raportti → · SPF-virheellisen konfiguraation raportti → · SPF-omaksumisen kypsyysmalli → · Korjaa DMARC → · Vain koostetietoja. Tiedot tallennetaan ja käsitellään EU:ssa.