"SPF-rekord nem található" — de van ilyen rekordja? Az 5 valódi ok (2026)

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

Adatok: 2026-06-29 · módszertan v7. Összesített cenzusadatok 261 millió értékelt domain alapján. Lásd: hogyan osztályozunk.

Ha egy ellenőrző azt jelzi, hogy „SPF-rekord nem található”, de Ön biztos benne, hogy közzétette, a rekord általában láthatatlan, nem hiányzik: 1,013,416 domain — a SPF-et kísérők körülbelül egy a 138 arányban — két vagy több SPF-rekordot tesz közzé, ami PermError (RFC 7208 §3.2), amelyet sok ellenőrző nem találtként jelez, a Defaults.Exposed 261 milliós domaincenzusza szerint.

Öt valódi ok létezik, mind megoldható egy ülésen: rossz gazdagép, duplikált rekord, rossz DNS-típus vagy torz idézőjel, inkonzisztens névszerverek, illetve hosszúság- vagy CNAME-ütközés. Alább: a 60 másodperces teszt mindegyikhez, az ellenőrzés sorrendjében, majd a javítási lépések.

Valóban létezik a rekord?

Kezdje a kellemetlen lehetőséggel, mert messze ez a leggyakoribb: a Defaults.Exposed cenzuszban értékelt 261,086,232 domain közül 121,145,609 — 46.4% — egyáltalán nem rendelkezik SPF-rekorddal. Sok „de én beállítottam” eset úgy végződik, hogy a rekordot egy teszt-zónához vagy egy régi DNS-szolgáltatóhoz adták hozzá, amely már nem autoritatív. Ellenőrizze azt a DNS-szolgáltatót, amelyre a névszerverek ténylegesen mutatnak (sokszor nem a regisztrátor), egy v=spf1-gyel kezdődő TXT rekordot keresve. Ha valóban nincs ott, hagyja a nyomozást, és menjen egyenesen az SPF-rekord javításához.

Hogyan ellenőrizze helyesen az SPF-rekordot?

A webes ellenőrzők a saját gyorsítótárazó feloldójukon keresztül kérdezik le a DNS-t. Az igazsághoz kérdezze meg közvetlenül a domain autoritatív névszerverét:

# keresse meg az autoritatív névszervereket
dig NS yourdomain.com +short

# kérdezze meg az egyiket közvetlenül a TXT rekordokért
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Windows rendszeren: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Két értelmezési szabály. Először: számolja meg a v=spf1-gyel kezdődő sorokat — a szám ugyanolyan fontos, mint a tartalom. Másodszor: ellenőrizze, hogy a megfelelő nevet kérdezte-e le: a fogadók az SPF-et a Return-Path (RFC5321.MailFrom, a „boríték feladója”) domainnel szemben értékelik — nem a címzett által látott From-cím alapján. Ha a hírlevélküldő eszköz a bounce.yourdomain.com által pattan vissza a leveleket, a csúcsdomainen lévő tökéletes rekord nem az, amit a fogadók megkeresnek.

Melyek az öt valódi ok?

#	Ok	A 60 másodperces teszt	A megoldás
1	Rekord rossz gazdagépen (aldomain vs. csúcsdomain)	`dig TXT` a Return-Path-ban szereplő pontos domainre	Tegye közzé azon a névnél, amelyik ténylegesen küld
2	Két vagy több `v=spf1` rekord = PermError	`dig TXT` 2+ `v=spf1` sort ad vissza	Olvassza össze pontosan egyetlen rekordba
3	99-es rekordtípusként közzétéve, vagy torz idézőjel	Ellenőrizze a rekord típusát és a téves idézőjeleket	Tegye újra közzé egyetlen tiszta TXT rekordként
4	Elavult gyorsítótár / inkonzisztens névszerverek	Kérdezze le közvetlenül minden NS-t; hasonlítsa össze a válaszokat	Javítsa a lemaradó névszervert, várja ki a régi TTL-t
5	255 karakternél hosszabb felosztás vagy CNAME-ütközés	Keresse a törött string-darabokat vagy egy CNAME-t ugyanazon a névnél	Hagyja, hogy a szolgáltató helyesen ossza fel a stringeket; vigye a rekordot a CNAME-elt névről

Adatok: 2026-06-29.

1. Rossz gazdagépen van a rekord?

A klasszikus eset: SPF hozzáadva a mail.yourdomain.com nevű gazdagéphez, miközben a levelek a yourdomain.com nevében érkeznek, vagy fordítva. Az SPF nem öröklődik lefelé — a csúcsdomainen lévő rekord semmit sem mond az aldomainekről, és fordítva. Tegye közzé pontosan azon a névnél, amely a Return-Path-ban szerepel. Egy saját visszapattanó aldomaint használó szállítónak erre az aldomainre kell rekord — általában egy CNAME vagy TXT, amelyet a szállító biztosít (a GoDaddy SPF beállítási útmutató megmutatja, hol találhatók ezek a mezők).

2. Van két SPF-rekordja?

A fő ok, és az e-mail hitelesítés legmegtévesztőbb hibaüzenete. Az RFC 7208 §3.2 egyértelműen kimondja: egy domainnek pontosan egy SPF-rekorddal kell rendelkeznie. Kettő vagy több PermError — a fogadók érvénytelennek tekintik az SPF-et. Néhány ellenőrző ezt pontosan jelzi („több rekord található”); mások a végeredményt jelzik: nem található érvényes SPF-rekord. Ön lát egy rekordot a panelen, és arra következtet, hogy az ellenőrző hibás. Nem az — egyszerűen eggyel több rekordja van a kelleténél.

A cenzusz 1,013,416 domaint talált, amely két vagy több SPF-rekordot tartalmaz — a SPF-et kísérők körülbelül egy a 138 arányban — mindegyiknél az SPF hatékonyan ki van kapcsolva. Ez általában egy szolgáltatóváltás során történik: az új szolgáltató varázslója egy friss rekordot ad hozzá a régi szerkesztése helyett. A megoldás az összevonás, soha nem egy második rekord: mindent egyetlen v=spf1 … ~all sorba kell összevonni, és a többit törölni. A két SPF-rekord egyenlő a semmivel cikkünk részletezi, hogyan jutott ide egymillió domain; ha ez migráció után kezdődött, lásd: Az SPF leállt a szolgáltatóváltás után. Az összevonáskor ne másolja be vakon az összes include: sort — mindegyik DNS-keresésbe kerül az SPF 10-es kemény korlátjával szemben, és a nem-talált hibát PermError: túl sok DNS-keresés váltja fel.

3. Rossz rekordtípust tett közzé — vagy a felület eltorzította?

A korai SPF-nek saját DNS-rekordtípusa volt (99-es típus, szó szerint „SPF” nevet viselt). Ez elavult: az RFC 7208 TXT típust ír elő, a fogadók nem kérdezik le a 99-es típust. Egyes DNS-panelek még mindig kínálnak „SPF” lehetőséget a rekordtípus legördülő menüjében; ha ezt választja, a rekord valóságos, jól formázott és láthatatlan. Ellenőrizze a típusoszlopot, és tegye újra közzé TXT-ként.

A finomabb változat az idézőjel. Ha egy értéket idézőjelben illeszt be egy olyan mezőbe, amely maga is hozzáadja az idézőjeleket, ""v=spf1 …"" keletkezik — ami már nem v=spf1-gyel kezdődik, tehát az ellenőrző számára nem létezik. A dig kimenete megmutatja az igazságot; a DNS-panel ezt gyakran kozmetikailag elrejti.

4. Valóban „még terjed”?

„Adjon meg 24–48 órát a terjedésre” a DNS leggyakrabban túlírt tanácsa. A terjedés csupán a gyorsítótárak lejáratát jelenti: amint a rekord TTL-je lejárt (általában 1 óra, ritkán több mint 24), minden feloldó láthatja az új választ. 24 óra után is nem találja? A terjedés nem az ok.

A két valódi bűnös: negatív gyorsítótárazás — egy feloldó, amely mielőtt hozzáadta volna a rekordot kereste fel, a „nincs ilyen rekord” választ tárolja a negatív TTL lejártáig — és az áttelepítés utáni inkonzisztens névszerverek, ahol a domain még mindig a régi szolgáltató névszervereit sorolja fel az újakkal együtt, és a világ fele egy olyan zónát olvas, amelyet már nem szerkeszt. Kérdezze le közvetlenül minden felsorolt névszervert; ha a válaszok különböznek, megtalálta. Javítsa a regisztrátor NS-delegálását, hogy csak az általa valóban szerkesztett szolgáltató legyen autoritatív.

5. Túl hosszú a rekord, vagy egy CNAME blokkolja?

Egy TXT rekord egyetlen stringje legfeljebb 255 karakterből állhat. A hosszabb SPF rekordok érvényesek, de egy rekordon belül több idézőjeles stringbe kell felosztani — és a DNS-szolgáltató webes felületei rendszeresen elrontják a felosztást, csonkítják az értéket, vagy félbeszakítják azt egy mechanizmusnál, így az már nem értelmezhető. Ha a rekordja hosszú, ellenőrizze a dig kimenetét, hogy az érték nem végződik-e hirtelen.

Ezen felül a DNS tiltja a TXT rekordot olyan névnél, amelynek már van CNAME-je. Ha a mail.yourdomain.com egy CNAME a szolgáltatójára, ott nem helyezhet el SPF-et — egyes panelek elfogadják, majd csak a CNAME-t küldik. Helyezze a rekordot oda, ahová a CNAME mutat (ha Ön irányítja), vagy alakítsa át, hogy a küldő neve ne legyen CNAME-elve. A tiszta TXT-kezelésű szolgáltatók mindkettőt megkönnyítik — lásd a Cloudflare SPF beállítási útmutatót.

Hogyan javítsa lépésről lépésre?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon — az élő DNS-t olvassa be, és megmutatja, melyik öt állapotban van, mielőtt bármihez hozzányúlna.
Erősítse meg, melyik névszerverek az autoritatívak (dig NS), és hogy mindegyik egyező választ ad.
Kérdezze le a TXT rekordot az autoritatív névszervertől a pontos Return-Path domain nevén.
Számolja meg a v=spf1 sorokat: nulla → tegyen közzé egyet; kettő vagy több → vonja össze egybe.
Ellenőrizze, hogy a típus TXT, az érték pontosan v=spf1-gyel kezdődik-e, és nem kerültek-e be téves idézőjelek vagy csonkítás.
Várja ki az egy TTL-t, majd szkennelje újra, hogy megerősítse: a rekord mindenhol tisztán feloldódik.

Gyakran ismételt kérdések

Miért mondja az ellenőrző, hogy „nem található”, ha látom a rekordot a DNS-panelen? Általában a 2. vagy 4. ok: egy második v=spf1 rekord mindkettőt érvényteleníti — ez PermError, amelyet néhány eszköz nem találtként jelez, ebben az állapotban van 1,013,416 domain 2026-06-29 szerint — vagy a panel nem az autoritatív DNS.

Mennyi ideig tart, amíg az ellenőrzők látják a javítást? Egy TTL — általában egy óra, legfeljebb 24. Ezen túl a „terjedés” nem magyarázat; ellenőrizze újra az öt okot, a névszerver-konzisztenciával kezdve.

Használjam a DNS-panel által kínált „SPF” rekordtípust? Nem. A 99-es típus elavult; az RFC 7208 kizárólag TXT típust ír elő. A 99-es típusú rekord láthatatlan a modern fogadók számára.

A rekord most megtalálható — miért bukik el még mindig az SPF a levelemen? Mert az SPF-et a Return-Path domain alapján ellenőrzik, nem a From fejléc alapján, és a rekordnak valóban fel kell sorolnia az Ön nevében küldő szervereket. A megtalálás az első lépés; az SPF-rekord javítása útmutató részletezi a sikeres átmenést.

Valóban ilyen gyakori, hogy nincs SPF-rekord? Igen — 121,145,609 domain, a Defaults.Exposed cenzuszban értékelt 261,086,232 tartomány 46.4%-a (2026-06-29 szerint) egyáltalán nem tesz közzé SPF-et. A nem-talált az internet alapértelmezett állapota.

Küldje el a tulajdonosnak a jelentést

Amint a rekord tisztán feloldódik, futtassa újra a vizsgálatot, és továbbítsa az értékelt jelentést annak a cégtulajdonosnak vagy ügyfélnek, akinek a domainje ez. Egyszerű nyelven megmutatja, mi volt törve, mit javított, és hol áll most a domain — pontosan az a bizonyíték, amelyre a kiberbizosítás megújításakor és a szállítói biztonsági kérdőíveken szükség lesz. A jelentés a munkát igazoló nyugta.

Ellenőrizze az SPF-rekordját ingyen

Nézze meg, melyik öt nem-talált állapotban van a domainje — privát módon, csak a tulajdonos számára.

Ellenőrizze domainjét → · SPF javítása → · SPF leállt a szolgáltatóváltás után → · Hogyan osztályozunk → · Csak összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.