SPF: ki küldhet levelet a domainje nevében?

4. modul: Rekordok az e-mailhez · Olvasási idő: 10 perc

Tanulási cél: E lecke után képes lesz elolvasni egy SPF-rekordot, helyesen hozzáadni egy szolgáltatást, és elkerülni a három legismertebb SPF-hibát: két rekord, +all és tíznél több keresés.

Alapfogalmak: SPF, v=spf1, mechanizmus (a, mx, ip4, ip6, include), minősítő (+ - ~ ?), all, egyetlen SPF-rekord, a DNS-keresések 10-es korlátja, boríték feladó (Return-Path)

A probléma: bárki használhatja az Ön nevét

Az e-mailt a nyolcvanas években találták ki, egy kicsi, barátságos internet számára. Minden levélkiszolgáló küldhet levelet info@example.com feladóval, akkor is, ha az a kiszolgáló semmilyen kapcsolatban nincs az example.com domainnel. A csalók ezt szívesen kihasználják.

Az SPF (Sender Policy Framework, RFC 7208) az első lépés ennek megelőzésére. Az SPF-rekordban megadja, mely kiszolgálók küldhetnek levelet az Ön domainje nevében. A fogadó levélkiszolgáló minden beérkező levélnél megnézi: ez a levél egy olyan kiszolgálótól érkezett, amely szerepel a listán?

Képzelje el egy ajtónál lévő vendéglistaként. A portás (a fogadó levélkiszolgáló) lekéri a listát az Ön domainjétől, és megnézi, hogy a látogató (a küldő kiszolgáló) szerepel-e rajta.

Hogyan néz ki egy SPF-rekord?

Az SPF-rekord egy TXT-rekord a domainnevén, amely v=spf1-gyel kezdődik:

example.com.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"

Balról jobbra olvassa. A fogadó egymás után végignézi az elemeket, és megáll az elsőnél, amelyik illeszkedik.

A vég: ~all, -all, ?all vagy +all

Minden elem előtt állhat egy jel, amely megmondja, mi történik, ha az elem illeszkedik. Az all esetében (amely mindig illeszkedik) ez a jel teszi a különbséget:

Ha nincs jel, akkor a + érvényes. Az mx tehát ugyanazt jelenti, mint a +mx.

Melyiket válassza? A ~all egy biztonságos alapbeállítás. A -all szigorúbb, és akkor jó, ha biztos benne, hogy minden küldője szerepel a rekordban. Ha DMARC-ot használ (4.5. lecke), végső soron a DMARC-irányelv határozza meg, mi történik; sok rendszergazda ekkor is a ~all-t választja.

1. hiba: két SPF-rekord

Domainenként csak egy SPF-rekord lehet. Ha a fogadó kettőt talál, az eredmény hiba (permerror lesz), és az SPF-je egyáltalán nem számít. Ez rosszabb, mintha egyáltalán nem lenne SPF.

A gyakorlatban ez gyakran elromlik. Egy hírlevélszolgáltató vagy a Microsoft 365 azt mondja: „adja hozzá ezt az SPF-rekordot”, és ekkor hirtelen egy második v=spf1-rekord jelenik meg a régi mellett. A megoldás: a meglévő rekordhoz adja hozzá az új szolgáltatást.

Hibás:

"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"

Helyes:

"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"

Figyeljen arra, hogy összevonáskor ne távolítsa el azokat a kiszolgálókat, amelyeket még használ. Ha a weboldala a tárhelyszolgáltatója kiszolgálóján keresztül küld levelet, annak bent kell maradnia, akkor is, ha a szokásos levelezése a Microsoft 365-be megy. Egy tárhelycsomaghoz gyakran tartozik már egy alap SPF egy tárhelyszolgáltatótól származó include-dal (a WebOkénál ez például include:webawere.nl); hagyja benn, amíg a weboldala vagy az űrlapjai azon a kiszolgálón keresztül küldenek levelet.

2. hiba: +all vagy egy túl tág rekord

A +all a végén, vagy egy hatalmas tartomány, mint az ip4:0.0.0.0/0, azt jelenti, hogy bárki küldhet levelet. Ekkor az SPF-je már semmit sem véd, és a spamszűrők ezt rossz jelnek tekintik.

3. hiba: tíznél több keresés

Az SPF-rekord ellenőrzéséhez a fogadónak néha további DNS-lekérdezéseket kell indítania. Minden include, a, mx, exists, ptr és redirect egy-egy keresésbe kerül, és egy include az általa hivatkozott rekord összes keresését is beleszámítja. Az RFC 7208 szerint az összesen nem haladhatja meg a tíz keresést. Ha ez megtörténik, az eredmény permerror lesz, és az SPF megbukik.

Az ip4 és az ip6 nem igényel keresést. Az all szintén nem.

Emellett legfeljebb kettő keresés jöhet vissza „üresen” (egy nem létező név, vagy válasz nélküli lekérdezés). Egy olyan include, amely egy már régóta nem használt szolgáltatásra mutat, és amelynek rekordját eltávolították, szintén problémát okozhat.

Ha sok szolgáltatást használ, számolja át egy SPF-ellenőrző eszközzel (8.3. lecke), és távolítsa el azokat a szolgáltatásokat, amelyeket már nem használ.

Amit az SPF nem tesz meg

Az SPF a boríték feladóját ellenőrzi: azt a technikai feladócímet (Return-Path), amelyet a levélkiszolgálók egymás között használnak. Ez nem mindig ugyanaz a cím, mint a „Feladó:” cím, amelyet a levelezőprogramjában lát. Egy hírlevélszolgáltató gyakran saját Return-Pathtel küld. Az SPF önmagában tehát nem állít meg minden hamisított feladót. Erre szolgál a DKIM (4.4. lecke) és a DMARC (4.5. lecke).

Az SPF a továbbításnál is megszakad: ha automatikusan továbbítja a levelét egy másik címre, a levél a végső fogadóhoz egy olyan kiszolgálótól érkezik, amely nem szerepel az Ön SPF-jében.

Miért számít mindez

A nagy levelezőszolgáltatók szigorúbbak lettek. 2024 februárja óta a Gmail és a Yahoo megköveteli, hogy mindenki, aki levelet küld, rendelkezzen legalább SPF-fel vagy DKIM-mel, és hogy aki sok levelet küld (naponta kb. 5000-nél többet), annak SPF-je, DKIM-je ÉS DMARC-ja is legyen. A Microsoft 2025 májusa óta ugyanezt az elvárást állítja fel az Outlook.com, a Hotmail és a Live.com esetében. Akkor is segít egy jó SPF-rekord a spam mappába kerülés ellen, ha keveset levelez.

A gyakorlatban: így néz ki egy vezérlőpulton

Ebben a példában a DirectAdmint használjuk. A DNS adminisztrációban kattintson a ceruzára a v=spf1-gyel kezdődő TXT-rekord mögött. A DirectAdmin megnyit egy SPF-segédeszközt: a Beleértve a domaineket mezőbe írja be a szolgáltatás domainjét (az include: nélkül), a Mód mezőben válassza a SoftFail (~all) vagy a Sikertelen (-all) lehetőséget. Alul megjelenik a teljes rekord. A Fiókom hasonló SPF-segédeszközzel rendelkezik a DNS fülön.

Más vezérlőpultokon nincs mindig ilyen segédeszköz. Ekkor a TXT-rekordot egyszerű szövegként szerkeszti; a tartalma pontosan ugyanaz.

Összefoglalás

• Az SPF egy TXT-rekord, amely v=spf1-gyel kezdődik, és megadja, mely kiszolgálók küldhetnek levelet az Ön domainje nevében.
• Domainenként pontosan egy SPF-rekord. Új szolgáltatás? Egészítse ki a meglévő rekordot.
• Végezze ~all-lal vagy -all-lal, soha ne +all-lal.
• Legfeljebb tíz DNS-keresés (include, a, mx, exists, ptr, redirect), az ip4/ip6 nem számít bele.
• Az SPF a boríték feladóját nézi; a valódi védelemhez DKIM-re és DMARC-ra is szükség van.

Kvíz

Feladat

Z4.3 feladat: SPF keresése. Keresse meg a google.com SPF-rekordját (vagy a saját domainjéét). Illessze be a teljes rekordot, és töltse ki, mivel végződik (~all, -all, ?all vagy +all). A saját domainje esetén a feladat azt is ellenőrzi, hogy pontosan egy SPF-rekordja van-e.

O4.3 feladat: Önálló beállítás a gyakorlózónájában. A gyakorlózónában egy álszolgáltatást használ; a valódi domainjénél a valódi include-ot használja, amelyet a levelezési szolgáltatója ad meg (például include:_spf.google.com). Hozzon létre a <code>.dnspractice.eu gyakorlózónájában egy SPF-rekordot, amely engedélyezi: a zóna MX-kiszolgálóit (mx), a 192.0.2.25 címet és a _spf.mailsuite-demo.dnspractice.eu gyakorlószolgáltatást. Más kiszolgálók gyanúsak vagy nem engedélyezettek, tehát a rekord ~all-lal vagy -all-lal végződik.

További olvasnivaló

Az ezekben a cikkekben szereplő lépések a WebOké vezérlőpultjaira vonatkoznak; más vezérlőpultokon hasonlóan működik.

• DirectAdmin útmutató 5.7: SPF beállítása és kiegészítése
• Hogyan működik az SPF-rekord a DNS-ben?
• SPF-rekord hozzáadása vagy módosítása a DirectAdminban
• WebOké útmutató 5.5: DNS-segédeszközök: MX, SPF, DMARC, CAA és SRV
• RFC 7208 (SPF), különösen a 4.6.4. szakasz (a tíz keresés és a két üres keresés korlátja)