Defaults.Exposed › Javítások › SPF (Sender Policy Framework)

Hogyan javítsd ki: SPF (Sender Policy Framework)

Az SPF egy sor a domain beállításaiban, amely meghatározza, mely levelezőszolgáltatások küldhetnek e-mailt a vállalkozás nevében. Enélkül bárki a világon küldhet olyan e-mailt, amely úgy néz ki, mintha tőled jönne – és a valódi e-mailjeid sokkal nagyobb eséllyel landolnak az ügyfelek spamjébe.

Az üzleted szempontjából lényeg: Bárki küldhet a vállalkozásod nevében e-mailt – ügyfeleknek, munkatársaknak és beszállítóknak – számlákat, fizetési adatmódosítási kéréseket és egyebeket. Közben a valódi ajánlataid és számláid is nagyobb eséllyel kerülnek spambe, ezért az üzletek csendben elakadnak.

Mibe kerülhet ez neked

Egy csaló a nevedben küld e-mailt az ügyfelednek, saját bankszámlaszámával ellátott számlával – és az ügyfél fizet. Hetekkel később derül ki, amikor az ügyfél rákérdez a megrendelt árura – és most a te hírneved, sőt esetleg a te felelősséged is forog kockán.
Az ajánlataid, számláid és válaszaid csendben az ügyfelek spamjébe kerülnek, mert a nagy e-mail-szolgáltatók nem tudják hitelesíteni, hogy valóban tőled jöttek. Az üzletek elakadnak, és soha nem tudod meg, miért.
Egy csaló a cégtulajdonos vagy a pénzügyis nevében e-mailt küld a munkatársaknak, sürgős átutalást vagy ajándékkártyát kérve. Az üzenet valóban a te domainedrről látszik jönni, ezért valaki fizet.
Egy nagyobb ügyféljelölt IT- vagy biztonsági csapata megvizsgálja a domained, nem lát feladóvédelmet, és vagy visszalép, vagy javítást kér aláírás előtt – az üzlet elvész, vagy heteket késik.
Azt hiszed, védett vagy, mert van SPF-rekordod – de 'soft fail' értékre van állítva, semmi sem kényszeríti ki, vagy csendben hibás, így a hamisított levelek továbbra is átmennek.

Miért fontos. Az e-mail feladó-mezőjének meghamisítása rendkívül egyszerű, és semmibe sem kerül a támadónak. Az SPF a legolcsóbb, leggyorsabb módja annak, hogy a domained nehezebben megszemélyesíthető legyen, és a valódi leveleid kimaradjanak a spamből. A Google és a Yahoo ma már aktívan spamezi vagy visszautasítja a nem hitelesített domainekről érkező e-maileket – ez tehát már nem opcionális, hanem a kézbesítés alapfeltétele.

Röviden

Jelenleg – ha az SPF nincs helyesen beállítva – a világ bármely pontjáról bárki küldhet olyan e-mailt, amely a vállalkozásodtól látszik jönni. Hamis számlákat küldhetnek az ügyfeleidnek, hamis fizetési kéréseket a munkatársaidnak, és levelezhetnek a beszállítóiddal, mintha te lennél – és az üzenetek hitelesnek tűnnek, mert semmi a domaineden nem mond mást.

Az SPF (Sender Policy Framework) a megoldás. Egyetlen szöveges sor a domain DNS-beállításaiban, amely megnevezi, mely levelezőszolgáltatások jogosultak valóban e-mailt küldeni a nevedben. A fogadó levelezőszolgáltatók – Gmail, Outlook és mindenki más – ellenőrzik ezt a listát, mielőtt eldöntik, hiteles-e az üzenet. Lista nélkül, vagy gyenge listával semmit nem tudnak kezdeni.

Ez az oldal két dologgal foglalkozik, amelyeknek egyszerre kell helyesnek lenniük: egyáltalán létezik-e SPF-rekord, és elég szigorúan van-e beállítva ahhoz, hogy valóban elvégezze a feladatát.

Mibe kerülhet ez neked

Ezek azok a mindennapi, valós módok, ahogyan egy hiányzó vagy gyenge SPF-rekord pénzbe és bizalomvesztésbe kerül. Sosem nevesítünk valódi vállalkozást – ezek az adatokban látott minták.

A számla-átirányítás. Egy bűnöző pontosan olyan e-mailt küld az ügyfelednek, mintha tőled jönne, egy valódinak tűnő számlát mellékelve saját bankszámlaszámával. Az ügyfél fizet. Először akkor hallasz róla, amikor az ügyfél rákérdez a megrendelt árura. Most dühös ügyfél, egy bűnözőhöz kerülő kifizetés, és egy nehéz beszélgetés arról, ki viseli a veszteséget.
A vezérigazgató/pénzügyi átverés. Valaki a nevedben e-mailt küld a könyvelőnek: „Gyors szívesség – el tudod utalni ezt a fizetést a nap vége előtt?” Mivel az üzenet valóban a domainedről látszik jönni, nem vált ki senkiben gyanút. A pénz kikerül a cégtől.
A csendes kézbesítési adó. Az ajánlataid és számláid elkezdenek az ügyfelek spamjébe kerülni, mert a Gmail és a Yahoo nem tudja hitelesíteni, hogy valóban tőled jöttek. Nem kapsz visszapattanást, nem kapsz hibaüzenetet – az üzletek egyszerűen elhallgatnak. Üzleteket veszítesz, és még csak látni sem tudod, hogy ez történik.
Az elveszett szerződés. Egy nagyobb ügyfél beszerzési vagy biztonsági csapata alapvető ellenőrzést végez a domaineden az onboarding részeként. Nem lát feladóhitelesítést, és kockázatként jelöl meg téged. A legjobb esetben meredek határidő alatt kapkodva javítasz; a legrosszabb esetben egy olyan versenytárshoz mennek, aki megfelelt az ellenőrzésen.
A márkámérgező hullám. A domained egy, a nyilvánosságnak szánt adathalász kampányban szerepel. Azok, akiket megkárosítottak, mostantól a neveddel ellátott minden e-mailt bizalmatlansággal kezelnek – így a valódi ajánlataid és megújítási értesítőid is figyelmen kívül maradnak vagy spam-jelölést kapnak.

Az összes forgatókönyv közös fonala: a támadó nem költ semmit, a vállalkozásod viseli a költséget és a felelősséget.

Mi is ez pontosan

Amikor egy e-mail megérkezik, a fogadó levelezőszerver egy dolgot akar tudni: valóban attól jön, akitől állítja? Az SPF ennek a kérdésnek a részét válaszolja meg.

A domain DNS-beállításaiban közzéteszel egy rövid szövegsort – egy „TXT-rekordot” –, amely megnevezi a levelezőszolgáltatásokat, amelyek küldhetnek e-mailt a nevedben. Például:

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

Egyszerű szavakkal: „A tőlünk érkező hiteles levelek a Google és a SendGrid szervereiről jönnek – utasíts el mindent mást, ami a nevünkben érkezik.”

A két rész, amely a besorolásod szempontjából számít:

Létezik-e egyáltalán a rekord? Ez a legfontosabb (az összes e-mail-ellenőrzés közül a legtöbb súlyt viseli). Rekord nélkül a fogadóknak nincs mit ellenőrizniük, így a megszemélyesítés teljesen nyitva van. Van egy finom meghibásodási mód is: ha a domainnek kettő vagy több SPF-rekordja van, a szabályok szerint mindkettő érvénytelen – tehát tulajdonképpen nincs SPF-ed, még ha úgy is tűnik.
Elég szigorú-e a politika? Egy rekord létezhet, de mégis hatástalan lehet. A végső rész – az „all” mechanizmus – az utasítás a fogadóknak:
- -all (hard fail) – utasítson el mindent, ami nincs a listán. A legerősebb. Teljes pontszám.
- ~all (soft fail) + DMARC ‘reject’ értékre állítva – a modern ajánlott beállítás. Egyenértékű védelmet nyújt a hard fail-lel, anélkül, hogy a továbbított levelek visszapattannának. Teljes pontszám.
- ~all + DMARC ‘quarantine’ értékre állítva – elfogadható, kissé gyengébb; teljes védelem érdekében mozdítsd a DMARC-ot ‘reject’ értékre.
- ~all önmagában (DMARC-kényszerítés nélkül) – gyenge. Ez azt mondja: „valószínűleg hamis, de kézbesítsd mégis.” A hamisított levelek még mindig átmennek. Ebbe a csapdába sok vállalkozás beleesik, azt gondolva, hogy védett.
- ?all (semleges) – semmilyen védelmet nem nyújt.
- +all – aktívan veszélyes: azt mondja a világnak, hogy bárki küldhet e-mailt a nevedben. Soha ne használd ezt.

Van még egy láthatatlan meghibásodási mód: az SPF-et kiértékeléskor legfeljebb 10 DNS-keresés végezhet. Ha túl sok include: bejegyzést halmozol fel, a rekord túllépi ezt a határt, és a fogadók az egészet hibásnak tekintik – visszakerülsz a védelem nélküli állapotba. Ez egy általános, csendes probléma a sok marketing- és SaaS-eszközt használó vállalkozásoknál.

Mit jelent a „jó” beállítás: pontosan egy SPF-rekord, amely felsorolja az összes olyan szolgáltatást, amely jogilag küldhet e-mailt a nevedben, ‘-all’ értékkel végzik (vagy ~all párosítva DMARC p=reject értékkel), és jóval a 10 keresési limit alatt marad.

Hogyan javítsd ki (ingyenes, ~10 perc)

Add át ezt a részt annak, aki a domained vagy weboldaladat kezeli – és jegyezd meg, hogy a javítás ingyenes. Ez egy DNS-beállítás módosítása, nem egy megvásárolandó termék. Mi csak azt számítjuk fel, hogy figyeljük, hogy idővel helyes marad-e, a módosítást nem.

1. lépés – Listázd az összes e-mailt küldő szolgáltatást a nevedben. Ez az a rész, ahol az emberek hibáznak. Írd össze az összeset: a postafiók-szolgáltatót (Google Workspace, Microsoft 365 stb.), valamint minden hírlevélküldő eszközt, CRM-et, helpdesket, e-kereskedelmi platformot, számlázó/könyvelő alkalmazást és foglalási rendszert. Ha egy szolgáltatás a neveddel küld e-mailt, és kihagyod, az SPF blokkolni fogja a leveleit, amikor megszorítod a politikát.

2. lépés – Tegyél közzé egy TXT-rekordot a gyökérdomaineden. Kombináld az összes feladód „include” sorait egyetlen rekordba. Az egyes platformok szerint:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (vagy a régiódhoz megfelelő domain)

Egy kombinált rekord így néz ki:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Hova kell hozzáadni, szolgáltatónként:

Cloudflare: DNS → Records → Add record → Type TXT, Name @, Content = a fenti érték.
Microsoft 365 / Google admin: megadják a pontos include-karakterláncot a beállítási varázslójukban; másold be a DNS-gazdád TXT-rekordjába.
GoDaddy / legtöbb host: DNS kezelés → Hozzáadás → TXT, Host/Name @, Érték = a rekord.

3. lépés – Kezdj biztonságosan, majd kényszerítsd ki. Amíg megerősíted, hogy a feladólistád teljes, tedd közzé ~all (soft fail) értékkel, hogy semmi jogos ne blokkolódjon véletlenül. Miután meggyőződtél arról, hogy minden valódi leveled továbbra is megérkezik, szigorítsd -all (hard fail) értékre – vagy, ami jobb, tartsd meg a ~all értéket, és adj hozzá DMARC-politikát p=reject értékkel, ami az ajánlott modern párosítás.

4. lépés – Győződj meg róla, hogy pontosan EGY rekordod van. Ha már létezik egy régi SPF-rekord, szerkeszd azt, ne adj hozzá egy másikat. Két v=spf1 rekord kölcsönösen érvényteleníti egymást, és védtelenül hagy.

5. lépés – Figyeld a keresési számot. Ha sok feladód van, átlépheted a 10 keresési limitet. Ha ez történik, konszolidálj – egyes szolgáltatók „SPF-lapítást” kínálnak, vagy hagyd el a már nem használt feladókat.

6. lépés – Ellenőrizd újra a domained, hogy most már megfelel-e, a rekord megvan-e és a politika elég szigorú-e.

Gyakori hibák

Két SPF-rekord. A leggyakoribb csendes meghibásodás. Egy új rekord hozzáadása a meglévő szerkesztése helyett mindkettőt érvényteleníti. Pontosan egy kell.
Megállni ~all értéknél és azt hinni, kész vagy. A mögöttes DMARC nélküli soft fail a gyenge középút – konfigurálva tűnik, de alig véd. Vagy menj -all értékre, vagy párosítsd a ~all értéket DMARC p=reject beállítással.
Kifeledni egy feladót. A -all értékre való szigorítás a számlázóalkalmazás, CRM vagy hírlevélküldő eszköz listázása előtt blokkolni fogja a saját valódi leveleidet. Előbb listázz mindent.
Átlépni a 10 keresési limitet. Minden include: további keresésekhez vezet. Túl sok és a rekord hibásnak minősül. Tartsd karcsúan.
+all használata. Ez kifejezetten felhatalmazza az egész internetet arra, hogy a nevedben küldjön e-mailt. Rosszabb, mint ha nincs rekord. Soha ne tedd közzé.

Hol illeszkedik ez a képbe

Az SPF az alap, de háromrétegű védelemből csak az egyik réteg. A DKIM kriptográfiai aláírást ad, amely bizonyítja, hogy az üzenetet nem manipulálták, a DMARC pedig az az utasítás, amely összeköti az SPF-et és a DKIM-et, és megmondja a fogadóknak, mit tegyenek valójában a meghibásodó levelekkel – beleértve az ügyfelek által látott „from” név megszemélyesítésének blokkolását. Helyezd el az SPF-et (ez a leggyorsabb nyeremény és a legtöbb súlyt hordozza), majd add hozzá a DKIM-et és a DMARC-ot az ajtó teljes bezárásához. Mindhárom javítás ingyenes.

Állítsd be a tárhelyszolgáltatódnál

Lépésről lépésre a népszerű szolgáltatóknál:

GYIK

Nem vagyok technikai beállítottságú – meg tudom ezt oldani magam?

Nem kell értened a részletekhez. A módosítás egy-két sor a domain beállításaiban, amelyet az a személy végez el, aki a weboldaladat vagy IT-támogatásodat kezeli. Add át nekik az alábbi 'Hogyan javítsd ki' részt – általában néhány percet vesz igénybe, és ingyenes. Mi csak azt számítjuk fel, hogy idővel figyeljük, helyesen marad-e.

Már van SPF-rekordunk – nem jelenti ez, hogy védve vagyunk?

Nem feltétlenül. A rekord megléte az első fél; a szigorú beállítás a második. Egy '~all' (soft fail) végű rekord DMARC nélkül azt üzeni a fogadó szervereknek: 'ez talán hamis, de mégis kézbesítsd' – ami minimális védelmet nyújt. Két SPF-rekord, vagy egy, amely túl sok keresést végez, hibásnak minősül, és semmilyen védelmet nem ad, annak ellenére, hogy látszólag létezik. Mindkét félnek helyesnek kell lennie.

A javítás véletlenül megszakítja a saját e-mailjeim kézbesítését?

Igen, ha a rekordból kimarad egy jogos feladó – például a számlázóalkalmazásod vagy a hírlevélküldőd. Ezért az a biztonságos megközelítés, hogy előbb listázol minden e-mailt küldő szolgáltatást, '~all' soft fail értékkel teszed közzé, miközben ellenőrzöd, hogy semmi sem marad ki, majd megszorítasz '-all' értékre. Ebben a sorrendben elvégezve semmi nem romlik el.

Mi a különbség a '~all' és a '-all' között, és melyiket használjuk?

A '-all' (hard fail) azt jelzi a fogadóknak, hogy utasítsanak el mindent, ami nincs a listán – ez a legerősebb beállítás. A '~all' (soft fail) azt mondja: 'valószínűleg nem hiteles, de fogadd el mégis'. A modern legjobb gyakorlat a '~all' kombinálása 'reject' DMARC-politikával – ez ugyanolyan védelmet nyújt, mint a '-all', anélkül, hogy a továbbított levelek visszapattannának. Az önmagában álló '~all', DMARC-kényszerítés nélkül, az a gyenge konfiguráció, amelyet el kell kerülni.

Az SPF önmagában megakadályoz minden e-mail-hamisítást?

Nem – ez az alapvető első réteg, nem a teljes megoldás. Az SPF meghatározza, mely szerverek küldhetnek e-mailt a nevedben, de nem mondja meg a fogadóknak, mit tegyenek, ha az üzenet nem felel meg, és nem fedi le a felhasználók által látott 'from' nevet. A megszemélyesítés teljes megszüntetéséhez DKIM és DMARC is szükséges. Az SPF a leggyorsabb, legnagyobb hatású első lépés, ezért kezdj itt, majd add hozzá a másik kettőt.

Mennyi idő után lép életbe, és kerülhet pénzbe?

A DNS-módosítások általában perceken belül, néhány óra alatt hatályba lépnek. Maga a javítás mindig ingyenes – csupán a DNS-szolgáltatónál kell módosítani egy beállítást. Aki azt mondja, hogy fizetős termék szükséges egy SPF-rekord hozzáadásához, az téved.