Defaults.Exposed › Jelentések

Miért hibásodik meg az SPF-em? A SaaS 10 DNS-lekérdezéses problémája az egyesült királyságbeli és EU-s küldők számára (2026)

Közzétéve 2026-07-09

Adatok: 2026-06-29 · módszertan v7. Összesített népszámlálási adatok 261 millió értékelt domain alapján. Lásd hogyan értékelünk.

Amikor az SPF meghibásodik egy SaaS-eszközöket használó vállalkozásnál az Egyesült Királyságban vagy az EU-ban, a legvalószínűbb ok egyetlen RFC-szabály, amelyre soha nem kellett gondolni: 10 DNS-lekérdezésen túl az SPF nem „fail”-t ad vissza — hanem PermError-t, ami azt jelenti, hogy a rekordot úgy kezelik, mintha nem létezne. Legalább 797,263 domain már átlépte ezt a határt. További 2,119,539 pontosan 9–10 lekérdezésnél jár — egyetlen új eszköz választja el őket ugyanattól a szakadéktól.

Miért hibásodik meg az SPF, ha SaaS-eszközt adsz hozzá?

Az SPF úgy működik, hogy felsorolja azokat a levelezőszervereket, amelyek jogosultak a domained nevében e-mailt küldeni. A modern vállalkozások nem üzemeltetnek saját levelezőszervereket — Google Workspace-t használnak a belső levelezéshez, Mailchimpet kampányokhoz, HubSpotot értékesítési sorozatokhoz, Pipedrive-ot CRM-outreachhoz. Minden platform ad egy include: sort, amelyet a DNS-be kell illeszteni.

A probléma: minden include: önmagában egy DNS-lekérdezés. És minden rekord az adott include belsejében rekurzívan további lekérdezéseket válthat ki. Az RFC 7208 §4.6.4 tízes kemény korlátot állapít meg. Tízen túl a fogadó levelezőszerver leállítja az értékelést és PermError-t ad vissza — és a PermError nem olyan puha hiba, amely spambe kerül. Azt jelenti, hogy az SPF-rekordod hiányzónak számít. Az e-mail hitelesítés megbukik az SPF részen.

Ezt nem fogod látni a DNS-panelben. A számláló csak az élő értékelés során indul el. Háromban include: sort tartalmazhat a látható rekordod, miközben tizenkét lekérdezésnyi mélységbe nyúlsz, mert minden szállító SPF-rekordja saját al-include-okat tölt be.

Hány domain lépte már át a korlátot?

Legalább 797,263. Ez a szám azon SPF include: célok feloldása után, amelyekre 100-szor vagy többször hivatkoznak — 10,842 különböző cél, amely az összes include-hivatkozás 95.2%-át fedi le — és az egyes domének teljes láncának kiszámítása után. A felszíni szám (amit csak a rekordban látható sorok megszámlálásával találnál) nagyjából 7,958. A láncon kiszámított szám 100-szor nagyobb, mert a károk szinte mindegyike láthatatlan az include-célok belsejében.

Az európai vállalkozásokat leginkább érintő helyzet:

Európai tárhelyszolgáltatók és gyenge SPF-alapbeállítások

A kiindulási tárhelyszolgáltató számít — mert néhányuk olyan SPF-alapértékeket állít be, amelyek már felhasználják a tíz lekérdezésedből néhányat, mielőtt egyetlen SaaS-eszközt is csatlakoztatnál.

A népszámlálásunkban európai domainek által használt legnagyobb tárhelyszolgáltatók közül:

Az IONOS kiemelkedik: az IONOS-nál tárolt domének 1.0%-ának van érvényesítő DMARC-ja, ami azt jelenti, hogy a túlnyomó többségnek egyáltalán nincs érdemleges küldőhitelesítése. Az OVH-domének jobban teljesítenek a szigorú SPF-beállítás terén (43.7%), de a DMARC-érvényesítésnél 2.2%-ra esnek — az SPF DMARC nélkül, amely a From: fejléchez köti, csak a borítékot védi, nem azt, amit a címzett lát.

A Microsoft 365 pozitív kivétel: a Microsoft-nál tárolt domének 85.0%-a szigorú SPF-et használ, elsősorban azért, mert a Microsoft levelezési varázsló alapértelmezés szerint -all-t állít be. A Google Workspace alapértelmezés szerint ~all (softfail) értéket állít be, így domaineinek 92%-a szigorú védelem nélkül marad.

Az SPF-hiba diagnosztizálása 60 másodpercen belül

A leggyorsabb ellenőrzés egy ingyenes eszköz, amely a teljes lekérdezési láncot értékeli — nem csak a látható rekordot. Futtasd a nslookup -type=TXT adoamained.com parancsot a parancssorban, és számold meg az összes látható include:-ot. Ezután keresd meg mindegyiket, és számold meg azok include-jait is. Ha elfogynak az ujjaid, mielőtt elfogynak az include-ok, veszélyzónában vagy.

Megbízhatóbb megközelítés: ellenőrizd a domained itt — a szkenner kiértékeli a teljes feloldott láncot, jelöli a PermError-t, és megmutatja, melyik mechanizmus emészti fel a lekérdezési kereted.

Három diagnosztikai eredmény:

• PermError — már tízen túl vagy. Minden elküldött e-mail megbukik a fogadónál az SPF-ellenőrzésen.
• 9–10 lekérdezésnél — a szakadék szélén állsz. A következő SaaS-integráció áttol a határon.
• Softfail (~all) a hardfail (-all) helyett — a korlát alatt vagy, de a rekord túl megengedően van beállítva ahhoz, hogy valódi védelmet nyújtson. Lásd az SPF-hibás konfiguráció jelentést a -all és ~all teljes képéhez.

Az SPF javítása több SaaS-eszköz használata esetén

Három megközelítés létezik, a tartósság sorrendjében:

1. Audit és tisztítás. Kezdd az aktuális rekordban szereplő összes include: felsorolásával. Távolíts el minden olyan platformot, amelyet már nem használsz — régi ESP-ket, korábbi szerződések CRM-eszközeit, tesztelt, de elhagyott platformokat. Ez ingyenes, és általában több lekérdezést is visszaszerez. Minden eltávolított include: 1–3 al-lekérdezést is megszüntethet.

2. Az SPF-rekord simítása. Az SPF-simítás az összes include:-célt feloldja az alapul szolgáló IP-tartományokra, és közvetlenül ip4: és ip6: mechanizmusként írja be a rekordba. Az IP-mechanizmusok nem váltanak ki lekérdezéseket, ezért egy simított rekord tucatnyi küldési forrást is felsorolhat, és mégis nullán maradhat a lekérdezések száma. Hátránya: újra kell simítani, amikor egy szállító frissíti küldési IP-jeit, ami bejelentés nélkül történik. A legtöbb vállalkozás fizetős SPF-simítási szolgáltatást vesz igénybe (PowerDMARC, EasyDMARC, Dmarcian és mások kínálják ezt), vagy figyelési munkafolyamatot épít ki.

3. SPF-makrók használata. Az RFC 7208-makrók lehetővé teszik olyan rekordok létrehozását, amelyek ellenőrzésenként egyetlen DNS-lekérdezést végeznek, és dinamikusan válaszolnak, nem include-láncokat. A makrók DNS-tárhely-támogatást és bizonyos implementációs erőfeszítést igényelnek, de sok SaaS-küldővel rendelkező szervezetek számára ez az architekturálisan tiszta megoldás.

Az SPF javítása után párosítsd DMARC-érvényesítéssel — az SPF DMARC nélkül csak a boríték feladóját hitelesíti, nem a fejlécbeli From: címet, amelyet a címzettek látnak.

Gyakran ismételt kérdések

Miért megy át az SPF-rekord a DNS-eszközömön, de mégis megbukik az e-mail fejlécekben? A legtöbb DNS-keresőeszköz csak a saját rekordodban látható mechanizmusokat számlja, nem azokat az al-lekérdezéseket, amelyeket ezek a mechanizmusok váltanak ki. Lehet két include: sorod, mégis a korlát felett lehetsz, ha az egyes szállítók rekordjában még több szerepel. Csak egy lánckiszámító eszköz (vagy egy fogadó levelezőszerver) számlálja a teljes mélységet. Ellenőrizd a domained a valós láncdszám megtekintéséhez.

Azt jelenti-e az SPF-hiba, hogy az e-mailjeim spambe kerülnek? A PermError (túl sok lekérdezés) azt jelenti, hogy a hitelesítés SPF-lába nem eredményt ad vissza — ténylegesen hiányzik. A DMARC mind az SPF-et, mind a DKIM-et értékeli; ha a DKIM átmegy, a DMARC még az SPF PermError ellenére is átmehet. Ha egyik sem megy át, a DMARC megbukik, és az eredmény a DMARC-házirendedtől függ. p=none esetén az e-mail továbbra is kézbesül, de a hibát naplózzák. p=quarantine vagy p=reject esetén az e-mailt szűrik vagy visszaküldik. Javítsd az SPF-et, hogy ne csak a DKIM-re támaszkodj.

Hány lekérdezést használ egy tipikus SaaS-csomag? A népszámlálásunkban szereplő p99 SPF-rekord már 9 lekérdezésnél jár — pont a korlát szélén — bármit is hozzáadna. Egy Google Workspace-rekord 3–4 lekérdezést ad hozzá; a Mailchimp 1–2-t; a HubSpot 1–3-at az aktuális konfigurációtól függően. Három általános eszköz plusz a tárhelyszolgáltatód alapértéke gyakran elegendő a tíz túllépéséhez.

Biztonságos az SPF-simítás? Igen, ha naprakészen tartod. A simítás az include:-láncokat statikus IP-tartományokra konvertálja — ha egy szállító lecseréli küldési IP-jeit, és te nem simítasz újra, elkezdik visszautasítani a leveleiket. A legtöbb szervezet kezelt simítási szolgáltatást alkalmaz, amely figyeli az IP-változásokat, ahelyett hogy manuálisan tartaná karban.

Az SPF-em évek óta ilyen — miért hibásodik meg most hirtelen? Mert a szállítóid frissítették az SPF-rekordjaikat, nem a tiéd. Minden alkalommal, amikor egy SaaS-platform új küldési IP-tartományt ad hozzá vagy beágyaz egy másik include-ot, a lánc költsége nő, anélkül hogy a te oldalon bármilyen változás történne. A 10 lekérdezéses korlátot élőben értékelik az üzenet fogadásakor, így egy szállítói változás kedden reggel már kedden délutánra tönkreteheti az SPF-edet.

Javítja-e az SPF javítása az e-mail kézbesíthetőségét? Megszüntet egy hitelesítési hiba-forrást, amely a következetes kézbesítés előfeltétele — különösen azért, mert a Google és a Yahoo mostanra DMARC-összhangot követel meg a tömeges küldőktől. Az SPF önmagában nem a teljes kép: párosítsd DKIM-mel és DMARC-kal a teljes e-mail-hitelesítés érdekében.

Ellenőrizd az SPF-edet ingyenesen

Ha nem tudod, hogy az SPF-rekordod túllépi-e a lekérdezési korlátot — vagy túl gyengén van-e beállítva a domain védelméhez — végezz ingyenes ellenőrzést. Kiértékeli a teljes feloldott láncot, és megmutatja pontosan, hol használják fel a keretet.

Ellenőrizd a domained → · SPF javítása → · Az SPF PermError-jelentés → · SPF-hibás konfiguráció jelentés → · Az SPF-elfogadás érettségi modellje → · DMARC javítása → · Kizárólag összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.