Defaults.Exposed › Korjaukset › Guides
SPF PermError: Miten korjata "liian monta DNS-hakua" rikkomatta sähköpostiasi (2026)
Julkaistu 2026-07-08
Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.
Vähintään 797,263 verkkotunnusta rikkoo SPF:n 10 DNS-haun rajan Defaults.Exposed-palvelun 261,086,232 verkkotunnuksen väestölaskennan mukaan — 139 miljoonasta SPF:n julkaisijasta. Kymmenen haun jälkeen vastaanottaja pysähtyy ja palauttaa PermErrorin: SPF on mitätön, ja DMARC laskee PermErrorin epäonnistumisena.
Korjauksella on tiukka järjestys, ja useimmat oppaat saavat sen takaperin. Laske todelliset, ratkaistut hakusi; poista kuolleet ja käyttämättömät includet — se yksin korjaa useimmat tietueet; siirrä joukkolähettäjät aliverkkotunnuksiin omalla SPF-budjetillaan; litistä vain viimeisenä keinona ja vain automaattisella uudelleenlitistämisellä, koska staattinen litistäminen mätänee ja rikkoo toimituksen hiljaisesti.
Mitä “SPF PermError: liian monta DNS-hakua” tarkoittaa?
RFC 7208 §4.6.4 rajoittaa jokaisen SPF-tarkistuksen 10 DNS-hakuun. Kymmenen jälkeen vastaanottaja pysähtyy ja palauttaa PermErrorin — koko tietue käsitellään rikkinäisenä, ei vain ylibudjettissa oleva osa. Sama osio lisää vähemmän tunnetun toisen katon: enintään 2 “tyhjää hakua” (kyselyt, jotka palauttavat vastauksen tai NXDOMAIN), joten muutama kuollut include:-merkintä perutetuille palveluille voi mitätöidä SPF:si yksinään.
Seuraus on pahempi kuin “ei SPF:ää”: DMARC käsittelee PermErrorin SPF-epäonnistumisena, joten verkkotunnus, joka rikkoo oman SPF:nsä, on todennettu kaikissa DMARC-arvioinneissa SPF-osalla. Jos DKIM ei ole asetettu tai hajoaa siirrossa, kyseinen posti epäonnistuu nyt DMARC:ssa suoraan.
Yksi väestölaskentaluku näyttää, kuinka julma tämä vikatila on: 112,215 verkkotunnusta julkaisee tiukan -all-tietueen, joka on mitätön hakuylityksen takia — 54,655,923:stä verkkotunnuksesta, jotka julkaisevat -all:ia ylipäänsä. Niiden omistajat tekivät vaikean osan — valitsivat tiukan lopetuksen — ja yksi include liikaa kytki koko tietueen pois. Ne näyttävät tiukoilta; ne ovat rikki. Täydellinen datakuva: SPF PermError -raportti.
Miksi SPF:ni hajosi, vaikka en muuttanut mitään?
Koska budjetti kuluu suurimmaksi osaksi muiden tietueista. Jokainen include: arvioidaan rekursiivisesti, ja jokainen hakumekanismi sisällään laskee kymmenesosasi. Yksi rivi DNS-paneelissasi voi maksaa neljä tai viisi hakua ratkaistuna. Tarjoaja upottaa yhden includin lisää, ja SPF kuolee ilman yhtään muutosta vyöhykkeessäsi.
Suuret alustat eivät ole ongelma: Google ja Microsoft ovat molemmat litistäneet oman SPF:nsä — _spf.google.com ja spf.protection.outlook.com laajenevat puhtaiksi IP-listoiksi maksaen nolla sisäistä hakua (tarkistettu live-DNS:ltä, heinäkuu 2026). Todelliset räjähdykset tulevat useita kerroksia syvistä isäntäpaneelin include-ketjuista ja rehellisestä SaaS-pinosta — postilaatikko plus uutiskirje plus CRM plus tukipalvelu, jokainen “vain yksi include”. Kukaan ei lisää yhdestoista hakua tarkoituksella; se saapuu kohtuullisten päätösten summana. Siksi klippireuna on niin tungosta: 2,119,539 verkkotunnusta sijaitsee täsmälleen 9–10 ratkaistussa haussa — noin 1 66:sta kaikista SPF-julkaisijoista, hyvin tänään, mitätön päivänä kun joku liimaa yhden includin lisää. 99. persentiilin SPF-tietue ratkaisuu jo 9 hakuun. Jos pinosi on SaaS-painotteinen, SPF epäonnistuu SaaS-työkaluille -opas kattaa toimittajakohtaisen version.
Mitkä osat SPF-tietueessa lasketaan DNS-hauiksi?
| Mekanismi | Hakukustannus | Huomio |
|---|---|---|
include: | 1 + kaikki sisällä, rekursiivisesti | mistä lähes kaikki räjähdykset tulevat |
a | 1 kukin | jopa paljaan a:n omalle verkkotunnukselle |
mx | 1 kukin (plus MX-isäntien A-haut) | usein unohdettu |
ptr | 1 — ja poistettu käytöstä vuodesta 2014 | poista riippumatta |
exists: | 1 kukin | harvinainen |
redirect= | 1 + kohdetietueen sisältö | laskee kuten include |
ip4: / ip6: | 0 | siksi litistäminen toimii |
-all / ~all / ?all | 0 | kvalifioija on ilmainen |
Laske ratkaistu kokonaismäärä, ei näkyviä rivejä. Neljä includia voi olla neljä hakua tai neljätoista.
Miten korjaan “liian monta DNS-hakua” rikkomatta sähköpostia?
- Aja ilmainen skannaus ennen DNS:n koskemista. Se ratkaisee täydellisen include-ketjusi ja näyttää todellisen hakumääräsi, jotta korjaat todellisen ongelman — ei tietuetta sellaisena kuin se näkyy paneelissasi. (Jos se sanoo, ettei sinulla ole SPF:ää lainkaan, se on eri virhe — katso “SPF-tietuetta ei löydy”.)
- Poista kuolleet ja käyttämättömät includet ensin. Työkalu, jonka lopetit 2023, vanhan isäntäkoneen include, joka selvisi migraatiosta, kaksoiskohdat, kaikki
ptr-mekanismit. Kuolleet includet ovat kahdesti myrkyllisiä: ne kuluttavat hakubudjettia ja ovat tavallinen tyhjien hakujen lähde. Useimmat ylibudjetissa olevat tietueet pääsevät alle 10:n pelkästään tässä vaiheessa. Jos tietueesi kantaa edelleen edellisen tarjoajan mekanismeja, seuraa migraation siivousopasta. - Tarkista, tekeekö jokainen jäljellä oleva include mitään. Vastaanottajat arvioivat SPF:n Return-Path (RFC5321.MailFrom) -verkkotunnusta vastaan, ei From-otsiketta — ja monet SaaS-työkalut laittavat oman palautusosoitteensa Return-Path:iin, joten niiden include tietueessasi ei tee mitään paitsi kuluttaa budjettia. Pidä includet vain palveluille, jotka käyttävät verkkotunnustasi Return-Path-osoitteena; muille, ota käyttöön toimittajan oman verkkotunnuksen DKIM sen sijaan.
- Siirrä joukkolähettäjät aliverkkotunnuksiin. Uutiskirjeet
news.sinunverkkotunnuksesi.com-osoitteesta, transaktiosähköpostitmail.sinunverkkotunnuksesi.com-osoitteesta. Jokaisella aliverkkotunnuksella on oma SPF-tietueensa tuoreella 10-haun budjetilla, eikä yhden virta ongelma vaikuta toisiin. - Vasta sitten harkitse litistämistä — ja vain automaattista litistämistä. Katso alla.
- Skannaa uudelleen vahvistaaksesi, että olet mukavasti alle 10 — tavoittele liikkumatilaa, ei täsmälleen 10:ä, tai olet vain liittynyt takaisin 2.1 miljoonan verkkotunnuksen joukkoon kliippireunan partaalla. Käy sitten läpi kaikki muut skannauksen liputtamat asiat korjaa SPF -sivulla.
Pitäisikö minun litistää SPF-tietueeni?
Litistäminen korvaa includet niiden taustalla olevilla ip4:/ip6:-lohkoilla, jotka eivät maksa hakuja. Se toimii — ja käsin tehtynä se on viivästetyn toimituskatkoksen aiheuttaja.
| Lähestymistapa | Hakumäärä | Ajan myötä |
|---|---|---|
| Karsinta + aliverkkotunnukset (vaiheet 2–4) | Yleensä alle 10 | Vakaa; tarjoajat hallitsevat omia IP:tään |
| Automaattinen litistäminen (palvelu tai ajoitettu tehtävä ratkaisee uudelleen ja julkaisee) | Lähellä 0 | Seuraa tarjoajan IP-muutoksia; turvallinen |
| Kertaluonteinen manuaalinen litistäminen | Lähellä 0 — tänään | Mätänee hiljaisesti: tarjoajat kierrättävät IP:tä, laillinen posti alkaa epäonnistua SPF:ssä ilman virhettä puolellasi |
Tarjoajat kierrättävät lähettäviä IP:tä rutiininomaisesti ilmoittamatta siitä kenellekään. Staattinen IP-lista on oikea päivänä, jolloin liimaat sen, ja hiljaa väärä kuukausien sisällä — ja koska virhe näkyy muiden vastaanottamatta postiasi, saat tietää myöhään. Jos karsinta ja aliverkkotunnukset saavat sinut alle rajan, pysähdy sinne; älä koskaan kopioi kolmannen osapuolen IP-lohkoja tietueeseen pysyvänä korjauksena.
Usein kysytyt kysymykset
Tarkoittaako SPF PermError, että sähköpostini lakkaa toimituksesta? Ei heti — siitä se on vaarallista. DMARC laskee PermErrorin SPF-epäonnistumisena, joten toimitus nojaa kokonaan DKIMiin; jos DKIM puuttuu tai hajoaa siirrossa, epäonnistut DMARC:ssa. 139 miljoonasta SPF-julkaisijasta väestölaskennassamme (2026-06-29 mukaan), vähintään 797,263 on tässä tilassa — useimmat tietämättään.
Tietueessani on vain neljä includia — miten se voi olla yli 10 hakua? Includit lasketaan rekursiivisesti: kaikki jokaisen includin sisällä (ja sen includien sisällä) veloitetaan budjetistasi, joten neljä näkyvää riviä voi ratkaista neljääntoista hakuun. Laske resolvoivalla työkalulla, ei silmällä — ketjujen ratkaiseminen on se, miten PermError-raporttimme löysi ~100× enemmän rikkinäisiä verkkotunnuksia kuin pintayksilölaskennat näyttävät.
Tietueeni päättyy -all:iin — eikö se tarkoita, että olen suojattu?
Vain jos tietue arvioidaan. Väestölaskentamme (2026-06-29 mukaan) löysi 112,215 verkkotunnusta, joiden tiukat -all-tietueet ovat mitättömiä hakuylityksen takia. Tiukka kvalifioija PermError-tietueella ei suojaa mitään.
Onko raja 10 hakua per include vai koko tietueelle? Koko arviointiin: RFC 7208 §4.6.4 rajoittaa koko tarkistuksen 10:een, plus enintään 2 tyhjää hakua. Jokainen aliverkkotunnus saa oman tietueensa ja budjettinsa — siksi vaihe 4 toimii.
Laskevatko ip4- ja ip6-merkinnät rajan suuntaan? Ei — IP-mekanismit eivät maksa mitään, mikä on täsmälleen siksi litistäminen vähentää määrää.
Lähetä omistajalle raportti
Jos korjaat tätä asiakkaalle tai työnantajallesi, viimeistele työ todisteella. Aja ilmainen skannaus uudelleen muutosten jälkeen ja lähetä arvioitu raportti yrityksen omistajalle: selkokielinen, päivätty, PermError poissa. Se on artefakti, jota he tarvitsevat kyberturvallisuusvakuutuksen uusimiseen ja seuraavaan asiakkaan turvallisuuskyselyyn — ero “muutin joitain DNS-tietueita” ja dokumentoidun ennen-jälkeen -raportin välillä.
Tarkista verkkotunnuksesi ilmaiseksi
Katso todellinen, ratkaistu hakumääräsi — ja kaikki muut SPF-, DKIM- ja DMARC-asiat — yksityisesti ja vain omistajalle.
Tarkista verkkotunnuksesi → · Korjaa SPF → · SPF epäonnistuu SaaS-työkaluille → · Aseta SPF GoDaddylle → · Miten arvioimme → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.