Szüntesse meg az SPF rekord technikai hibáit véglegesen

SPF “túl hosszú” hiba (10 DNS lookup limit) – hogyan javítsd úgy, hogy ne romoljon a kézbesítés

A feladóként megjelenő e-mail megbízhatósága kulcskérdés minden vállalkozás számára, különösen ha hírleveleket, automatikus értesítőket vagy CRM-rendszerből generált leveleket küld ki. A modern e-mail infrastruktúrák egyik alapvető biztonsági eleme az SPF rekord, amely megakadályozza, hogy illetéktelen szerverek a nevünkben leveleket küldjenek. Azonban, ha nem figyelünk oda, könnyen belefuthatunk egy gyakori, mégis kevéssé ismert korlátba: az SPF “túl hosszú” hiba – amelyet a DNS lookup limit okoz.

Mi az az SPF rekord, és miért van rá szükség?

Az SPF (Sender Policy Framework) rekord egy speciális DNS bejegyzés, amely felsorolja azokat az IP-címeket vagy szervereket, amelyek jogosultak e-mailt küldeni az adott domain nevében. Ha például az info@cegem.hu címről kiküldött levelet a Gmail vagy az Outlook szervere fogadja, első lépésként ellenőrizni fogja a cégem.hu domain SPF rekordját, és megnézi, hogy az adott levélküldő szerver szerepel-e az engedélyezett listában.

Ez a rendszer alapvetően megbízható és szükséges, de a bonyolult e-mail infrastruktúrák (például amikor egyszerre használunk Mailchimpet, Google Workspace-et, egy webtárhelyes SMTP-t és mondjuk egy számlázóprogramot) gyorsan felduzzaszthatják az SPF rekordot.

A 10 DNS lookup limit: korlát, amelyre kevesen gondolnak

Az SPF szabvány egyik kevésbé ismert technikai korlátja az, hogy legfeljebb 10 DNS lookup engedélyezett. Ez azt jelenti, hogy ha egy SPF rekord sok include: vagy redirect= hivatkozást tartalmaz, amelyek önmaguk is más SPF rekordokat húznak be, gyorsan elérhetjük ezt a bűvös határt.

A tipikus hibaüzenet a következő lehet:

SPF Permanent Error: too many DNS lookups

Ez nemcsak technikai probléma, hanem komoly kézbesítési gondokat is okozhat. A fogadó e-mail szerverek ugyanis a hibás SPF rekord esetén úgy viselkedhetnek, mintha egyáltalán nem lenne SPF, ami spamként való megjelöléshez, vagy akár levélelutasításhoz is vezethet.

Mit lehet tenni, ha elérted a 10 lookup limitet?

Az első és legfontosabb, hogy ne ess pánikba és ne törölj vakon sorokat a rekordból. A cél az, hogy optimalizáld a bejegyzést úgy, hogy a hitelesítés megmaradjon, és ne ronts a kézbesíthetőségen.

1. Auditáld az SPF rekordod tartalmát

Használj eszközöket, mint a MXToolbox SPF record checker, amelyek kilistázzák, hány lookup történik, és mely include: sorok mekkora láncot generálnak. Ilyen auditálásnál kiderülhet például, hogy több különböző szolgáltató include: rekordja ugyanarra az aldomainre mutat, így redundanciát is kiszűrhetsz.

2. Használj ip4: vagy ip6: címeket, ahol lehet

Ha van rá lehetőség, az adott szolgáltató által biztosított konkrét IP-címtartományokat közvetlenül beírhatod, ezzel csökkentve a DNS lekérdezéseket.

3. Fogd össze az azonos szolgáltatókat

Például, ha több Google-hoz tartozó szolgáltatás van (pl. Google Workspace, Firebase), azokat elég egyetlen include:_spf.google.com-ként szerepeltetni. Ugyanez igaz sok más platform esetén is – de figyelj rá, hogy a legáltalánosabb szintet válaszd, amely tartalmazza az összes alá tartozó elemet.

4. Minimalizáld a harmadik féltől származó szolgáltatók számát

Vizsgáld meg, valóban szükség van-e minden egyes e-mailküldő szolgáltatóra, vagy megoldható egy központi SMTP-n keresztül. Sok cég és egyéni vállalkozó egyszerűen túl sok rendszert használ párhuzamosan, ami felesleges komplexitást eredményez.

1b.hu megoldási javaslatai és tanácsai

Az 1b.hu hosting- és domainkezelési rendszeren belül számos ügyfél találkozott már ezzel a problémával. A tapasztalataink alapján a következő javaslatokat szoktuk adni:

Ne használj +all, ~all, vagy ?all záróelemeket gondolkodás nélkül. A -all a legszigorúbb, és ha biztos vagy a rekordodban, ez a legjobb. De ha bizonytalan vagy, használj ~all-t (softfail), míg tesztelsz.

Nálunk lehetőség van arra is, hogy a túlzottan hosszú SPF rekordokat részekre bontva, több aldomainen keresztül optimalizáld. Így egy központi domain továbbítja az e-maileket, míg a küldést lebonyolító szerverek saját SPF rekordjuk alapján működnek.

Az 1b.hu rendszere automatikusan figyelmeztet, ha túllépnéd a 10 lookup határt, és javaslatot tesz optimalizálásra, így nem kell fejben számolnod.

Mikor érdemes újratervezni a teljes SPF struktúrát?

Ha egy vállalkozás folyamatosan új szolgáltatókat von be (pl. új CRM, marketingautomatizálás, helpdesk), akkor időnként elkerülhetetlenné válik, hogy újragondold a teljes e-mail küldési infrastruktúrát. Ilyenkor érdemes lehet:

Központosítani a küldést egyetlen szolgáltatóra (pl. SMTP relay)

Visszaszorítani az automatizált levélküldést, ha annak kézbesíthetősége nem kritikus

Vagy bevezetni DMARC és DKIM védelmeket is, hogy ne csak SPF-re épüljön a biztonság

Záró gondolat

A „túl hosszú SPF” probléma nem csak technikai kérdés – az üzleti kommunikáció megbízhatóságát érinti. Nem elegendő beállítani egyszer, majd évekig nem nyúlni hozzá. Az SPF karbantartása folyamatos figyelmet igényel, különösen a dinamikusan változó digitális környezetben. Szerencsére a megfelelő tudás és eszközök birtokában – mint amit az 1b.hu kínál – ez a kihívás könnyedén kezelhető, és nem kell kompromisszumot kötni a kézbesíthetőség rovására.