SPF beállítás: Lépésről lépésre útmutató

Mi az az SPF?

Az SPF (Sender Policy Framework) egy DNS-alapú e-mail hitelesítési protokoll, amely lehetővé teszi a domaintulajdonosok számára, hogy meghatározzák, mely levelezőszerverek jogosultak e-maileket küldeni az adott domain nevében. Az SPF egy egyszerű, de rendkívül hatékony módszer arra, hogy megvédd a domainedet az e-mail-hamisítástól (spoofing) és csökkentsd annak esélyét, hogy a leveleid spam mappába kerüljenek.

Az SPF technikai szempontból egy DNS TXT rekord, amelyet a domained DNS-zónájába kell elhelyezned. Ez a rekord tartalmazza azoknak a szervereknek, IP-címeknek és szolgáltatásoknak a listáját, amelyek jogosultak e-mailt küldeni a @tediomained.hu címekből. Amikor egy fogadó levelezőszerver (pl. Gmail, Outlook) e-mailt kap a domainedről, a következő lépéseket hajtja végre:

Megkapja az e-mailt és kiolvassa a feladó domain nevét az envelope-from (MAIL FROM) fejlécből.
DNS lekérdezést végez a feladó domain TXT rekordjára, és megkeresi az SPF bejegyzést.
Összehasonlítja a levelet ténylegesen küldő szerver IP-címét az SPF rekordban felsorolt engedélyezett IP-címekkel.
Döntést hoz: ha az IP-cím megtalálható az SPF rekordban, az SPF ellenőrzés sikeres (pass). Ha nem, az eredmény fail, softfail vagy neutral lehet, attól függően, hogyan van konfigurálva az SPF rekord.

Egyszerű analógia: Az SPF rekord olyan, mint egy portás lista egy irodaháznál. Amikor valaki azt állítja, hogy a cégedtől jött, a portás (fogadó szerver) megnézi a listát (SPF rekord), és csak akkor engedi be (kézbesíti a levelet), ha a személy neve (szerver IP-je) rajta van a listán.

Az SPF-et eredetileg az RFC 4408 specifikálta 2006-ban, majd az RFC 7208 váltotta fel 2014-ben. A protokoll az internet e-mail infrastruktúrájának alapvető eleme, és a DKIM (DomainKeys Identified Mail) és DMARC (Domain-based Message Authentication, Reporting and Conformance) mellett az e-mail hitelesítés három pillérének egyikét alkotja.

Miért fontos az SPF?

Az SPF beállítása nem csupán egy opcionális technikai lépés -- a modern e-mail kézbesítés szempontjából alapvető követelmény. Az alábbiakban részletezzük, miért elengedhetetlen a helyes SPF konfiguráció:

Spam-szűrés és kézbesíthetőség

SPF rekord nélkül a nagy levelezőszolgáltatók (Gmail, Outlook, Yahoo) automatikusan gyanúsnak tekintik a domainedről érkező leveleket. A Google 2024 februárjától megköveteli az SPF vagy DKIM hitelesítést minden feladótól, aki napi 5000-nél több levelet küld Gmail-címekre. De a gyakorlatban az 5000 alatti feladókat is érinti: SPF nélkül a leveleid nagy eséllyel a spam mappába kerülnek, vagy egyáltalán nem kerülnek kézbesítésre.

Figyelem: A Yahoo és a Gmail 2024 februárja óta aktívan visszautasítja azokat az e-maileket, amelyeknél sem SPF, sem DKIM hitelesítés nincs beállítva. Ez nem opcionális -- ha üzleti e-maileket küldesz, az SPF beállítása kötelező.

Spoofing (e-mail-hamisítás) elleni védelem

SPF nélkül bárki küldhet e-mailt a domained nevében. Egy támadó kihasználhatja ezt adathalász (phishing) támadásokra: e-maileket küldhet, amelyek úgy tűnnek, mintha a cégedtől érkeznének, és ezzel megtéveszthetik az ügyfeleidet, partnereidet vagy munkatársaidat. Az SPF rekord megakadályozza, hogy illetéktelen szerverekről érkező levelek sikeresen átmenjenek az SPF ellenőrzésen.

Domain-reputáció védelme

Ha valaki spameket küld a domained nevében, az negatívan befolyásolja a domained reputációját a levelezőszolgáltatók szemében. Egy alacsony reputációjú domainről érkező levelek -- még ha azok legitimek is -- nagyobb eséllyel kerülnek spam mappába. Az SPF beállításával megvéded a domain reputációdat azzal, hogy csak az általad engedélyezett szerverekről érkező levelek köthetők a domainedhez.

Gmail és Outlook követelmények

A nagy szolgáltatók explicit elvárásai:

Gmail: SPF vagy DKIM kötelező minden feladónak. Napi 5000+ levél esetén SPF és DKIM és DMARC is kötelező.
Microsoft 365 / Outlook: Erősen ajánlott az SPF beállítása; SPF nélküli levelek gyakrabban kerülnek karanténba.
Yahoo Mail: 2024 februárja óta megköveteli az SPF vagy DKIM hitelesítést.

SPF beállítás lépésről lépésre

Az SPF beállítása négy lépésből áll. Kövesd az alábbi útmutatót a domainedhez illesztve:

1. lépés: Azonosítsd a küldőszervereidet

Mielőtt megírnád az SPF rekordot, össze kell gyűjtened az összes forrást, ahonnan e-maileket küldesz a domained nevében. A tipikus küldőforrások:

Google Workspace (Gmail): Ha a céges e-mailjeidet a Google Workspace-en keresztül kezeled, az include:_spf.google.com bejegyzést kell hozzáadnod.
Microsoft 365: Ha az Outlook / Exchange Online-t használod, az include:spf.protection.outlook.com szükséges.
Saját SMTP szerver: Ha saját levelezőszervered van, annak IP-címét kell megadnod (ip4:123.45.67.89).
Hírlevélküldő szolgáltatás: Ha Mailchimp-et, SendGrid-et, Brevo-t (korábban Sendinblue) vagy más szolgáltatást használsz hírlevélküldésre, azok SPF include értékét is hozzá kell adnod. Például: include:sendgrid.net, include:servers.mcsv.net.
Tranzakciós e-mail szolgáltatás: Ha az alkalmazásod Postmark-on, Amazon SES-en vagy Mailgun-on keresztül küld tranzakciós leveleket, azok include-ját is meg kell adnod.

Tipp: Nézd meg a meglévő e-mailjeid fejlécét (header-jét) -- a Received: mezőkben megtalálod azoknak a szervereknek az IP-címeit, amelyek ténylegesen küldik a leveleidet. Ez segít abban, hogy ne felejts ki egyetlen küldőforrást sem.

2. lépés: Hozd létre vagy módosítsd az SPF rekordot

Az SPF rekord egy egyszerű szöveges sor, amely mindig a v=spf1 prefixszel kezdődik. Az alábbi példa egy tipikus SPF rekordot mutat, amely Google Workspace-et és SendGrid-et használó domainhoz készült:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Nézzük meg az egyes elemeket:

v=spf1 -- az SPF verzióazonosító, mindig ezzel kell kezdeni.
include:_spf.google.com -- engedélyezi a Google Workspace levelezőszervereit.
include:sendgrid.net -- engedélyezi a SendGrid hírlevélküldő szervereit.
~all -- softfail: a rekordban nem szereplő szerverekről érkező leveleket gyanúsként jelöli, de nem utasítja el véglegesen.

Ha Microsoft 365-öt és Mailchimp-et használsz, az SPF rekordod így nézhet ki:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

Ha saját szervered is van egy adott IP-címen:

v=spf1 ip4:203.0.113.50 include:_spf.google.com ~all

3. lépés: Add hozzá a DNS-hez

Az elkészített SPF rekordot TXT rekordként kell hozzáadnod a domained DNS-zónájához. A pontos lépések a DNS-szolgáltatódtól függnek (pl. Cloudflare, GoDaddy, Rackhost, Tárhely.Eu, DNSIMPLE), de az általános folyamat a következő:

Lépj be a DNS-szolgáltatód kezelőfelületére.
Navigálj a domained DNS-beállításaihoz.
Adj hozzá egy új TXT rekordot.
A név/host mezőbe írd be a @ jelet (ez a domain gyökerét jelenti) vagy hagyd üresen, ha a szolgáltató ezt várja.
Az érték/tartalom mezőbe másold be a teljes SPF rekordot (pl. v=spf1 include:_spf.google.com ~all).
A TTL értéket állítsd 3600-ra (1 óra) vagy hagyd az alapértelmezetten.
Mentsd el a beállítást.

Fontos: A DNS-változások propagációja akár 24-48 órát is igénybe vehet, bár általában 1-4 óra alatt megtörténik. A beállítás után ne aggódj, ha az ellenőrző eszközök nem mutatják azonnal az új rekordot.

4. lépés: Ellenőrizd az SPF rekordot

A beállítás után ellenőrizd, hogy az SPF rekordod helyesen jelenik-e meg. Parancssorból a következő parancsot használhatod:

nslookup -type=TXT pelda.hu

Linux vagy macOS rendszeren a dig parancs is használható:

dig TXT pelda.hu +short

Az eredményben meg kell jelennie a teljes SPF rekordodnak. Online eszközök is rendelkezésre állnak az ellenőrzéshez:

MXToolbox SPF Record Lookup -- részletes elemzés a rekord szintaxisáról
SPF Record Testing Tools -- szintaxis validálás
dmarcian SPF Survey -- vizuális SPF elemzés

Tipp: Az ellenőrzés után küldj egy teszt e-mailt a Gmail-fiókodra, és nézd meg a levél fejlécét (három pont > "Eredeti megjelenítés"). Keress rá az spf=pass bejegyzésre -- ha ez megjelenik, az SPF beállításod helyesen működik.

Gyakori SPF hibák és megoldásaik

Az SPF beállítása során számos gyakori hiba fordulhat elő, amelyek a hitelesítés sikertelenségéhez és kézbesítési problémákhoz vezethetnek. Az alábbiakban a leggyakoribb hibákat és azok megoldásait mutatjuk be:

"Too many DNS lookups" -- Túl sok DNS keresés

A probléma: Az SPF szabvány (RFC 7208) maximum 10 DNS keresést engedélyez egy SPF rekord feldolgozása során. Minden include:, a, mx és redirect mechanizmus egy-egy DNS keresésnek számít. Ha az SPF rekordod (beleértve a beágyazott include-okat is) összesen több mint 10 DNS keresést igényel, az SPF ellenőrzés automatikusan permerror eredménnyel zárul, és a levél nem kap SPF hitelesítést.

Megoldás: Használj ip4: és ip6: mechanizmusokat az include: helyett, ahol lehetséges -- ezek nem számítanak DNS keresésnek. Alternatívaként használj SPF "flattening" szolgáltatást (pl. AutoSPF), amely automatikusan feloldja az include-okat IP-címekre.

Több SPF rekord ugyanazon a domainen

A probléma: Az SPF szabvány szerint egy domainhez csak egyetlen SPF rekord tartozhat. Ha két vagy több TXT rekordot adsz hozzá, amelyek mindegyike v=spf1-gyel kezdődik, az SPF ellenőrzés permerror eredményt ad, és egyik rekord sem lesz érvényes.

Megoldás: Egyesítsd az összes SPF bejegyzést egyetlen rekordba. Ahelyett, hogy két külön rekordot hoznál létre:


v=spf1 include:_spf.google.com ~all
v=spf1 include:sendgrid.net ~all


v=spf1 include:_spf.google.com include:sendgrid.net ~all

A `-all` túl agresszív használata

A probléma: A -all (hard fail) mechanizmus utasítja a fogadó szervert, hogy utasítsa el az összes e-mailt, amely nem a felsorolt szerverekről érkezik. Ez önmagában nem hiba, de ha nem vetted számba az összes küldőforrást, a -all miatt a saját legális leveleid is visszautasításra kerülhetnek.

Megoldás: Kezdetben használj ~all (softfail) beállítást, amely jelzi a gyanús levelet, de nem utasítja el véglegesen. Miután meggyőződtél arról, hogy az SPF rekordod tartalmazza az összes küldőforrást, válts -all-ra a maximális védelem érdekében.

Harmadik féltől származó küldők kihagyása

A probléma: Sok vállalkozás elfelejti hozzáadni a hírlevélküldő szolgáltatásokat (Mailchimp, SendGrid), a CRM rendszereket (HubSpot, Salesforce) vagy az ügyfélszolgálati platformokat (Zendesk, Freshdesk) az SPF rekordhoz. Ezekből a rendszerekből küldött levelek SPF-ellenőrzése sikertelen lesz.

Megoldás: Készíts egy teljes leltárt az összes rendszerről és szolgáltatásról, amely e-maileket küld a domained nevében. Minden szolgáltatás dokumentációjában megtalálod a szükséges SPF include értéket. Rendszeresen frissítsd az SPF rekordat, ha új küldőszolgáltatást vezetsz be.

SPF szintaxis gyorsreferencia

Az alábbi táblázat összefoglalja az SPF rekordokban használható mechanizmusokat és minősítőket:

Mechanizmus	Leírás	Példa
`include:`	Egy másik domain SPF rekordját is érvényesnek tekinti. Külső szolgáltatások (Google, Microsoft, hírlevélküldők) engedélyezésére használatos.	`include:_spf.google.com`
`ip4:`	Egy adott IPv4-címet vagy CIDR tartományt engedélyez. Saját szerverek megadására ideális.	`ip4:203.0.113.50` vagy `ip4:203.0.113.0/24`
`ip6:`	Egy adott IPv6-címet vagy CIDR tartományt engedélyez.	`ip6:2001:db8::1` vagy `ip6:2001:db8::/32`
`a`	A domain A (vagy AAAA) rekordjához tartozó IP-címet engedélyezi. DNS keresésnek számít.	`a` vagy `a:mail.pelda.hu`
`mx`	A domain MX rekordjainak IP-címeit engedélyezi. DNS keresésnek számít.	`mx` vagy `mx:pelda.hu`
`all`	Az összes többi forrásra vonatkozó alapértelmezett szabály. Mindig az SPF rekord végén áll, minősítővel együtt.	Lásd alább a minősítőkkel

Minősítők (qualifiers)

A minősítők meghatározzák, mi történjen azokkal a levelekkel, amelyek nem felelnek meg az SPF rekordnak:

Minősítő	Jelentés	Ajánlás
`~all`	Softfail -- A nem egyező leveleket gyanúsnak jelöli, de nem utasítja el. A fogadó szerver dönt a kézbesítésről.	Ajánlott kezdőknek és a beállítás tesztelési fázisában.
`-all`	Hard fail -- A nem egyező leveleket határozottan elutasítja. A fogadó szerver visszautasítja a levelet.	Ajánlott, ha biztos vagy abban, hogy minden küldőforrás szerepel a rekordban.
`+all`	Pass -- Bármely szerver küldhet a domain nevében. Gyakorlatilag kikapcsolja az SPF-et.	Soha ne használd! Teljesen értelmét veszti az SPF védelem.
`?all`	Neutral -- Nem mond semmit a nem egyező levelekről. Az SPF ellenőrzés "neutral" eredményt ad.	Ritkán hasznos; sem nem véd, sem nem árt.

Összefoglalva: Egy jól összeállított SPF rekord a v=spf1 prefixszel kezdődik, tartalmazza az összes engedélyezett küldőforrást (include:, ip4:, ip6:, a, mx), és a ~all vagy -all minősítővel zárul. A maximális DNS keresések száma 10 -- ezt tartsd szem előtt, ha sok szolgáltatást használsz.

Teljes példa

Íme egy tipikus magyar KKV SPF rekordja, amely Google Workspace-et használ levelezésre, SendGrid-et hírlevélküldésre, és rendelkezik egy saját SMTP szerverrel:

v=spf1 ip4:185.25.100.42 include:_spf.google.com include:sendgrid.net ~all

Ez a rekord összesen 3 DNS keresést igényel (az ip4: nem számít), ami bőven a 10-es limit alatt van. A ~all softfail a nem engedélyezett szerverekről érkező leveleket gyanúsként jelöli, de nem utasítja el azonnal.