Biztonságos e-mail beállítás: hogy a leveled célba érjen, és a nevedben ne küldhessen más

Az e-mail a legrégebbi eszköz az online eszköztáradban, a csalások gyakori célpontja. A fogadó szerverek naponta milliárdnyi hamis levelet szűrnek ki, és a világ úgy döntött: nem a rossz leveleket próbálja felismerni, hanem a jókat kéri bizonyításra. Ha a domained nem bizonyít, a leveled gyanús — akkor is, ha egy teljesen szabályos ajánlat, számla vagy webes űrlap visszaigazolása.

Ez a cikk végigvezet azon, mit kér tőled a rendszer és miért: mi a négy beállítás lényege, milyen sorrendben érdemes bevezetni őket, és hol vannak a tipikus buktatók. Nem rendszergazdáknak írom, hanem vállalkozóknak – de a végére pontosan tudni fogod, mit kérj számon a szolgáltatódon vagy a fejlesztődön. Fontos, hogy a helyes beállításhoz hozzáférés szükséges a domain neved DNS zónájához.

Miért landol spamben a szabályos céges levél?

A szabályos céges levél leggyakrabban azért landol spamben, mert a domain nem bizonyítja a feladó hitelességét — a fogadó szerver nem a levél tartalmát nézi először, hanem azt, hogy a küldő igazolja-e magát.

A logika mögött egy egyszerű aszimmetria áll: e-mailt küldeni bárki tud bárkinek a nevében — a protokoll, amin a levelezés fut, évtizedekkel a spam-ipar előtt született, és alapból nem ellenőrzi a feladót. A „Feladó” mezőbe technikailag azt ír a küldő, amit akar. Erre a nyitott kapura épült rá a hitelesítési rendszer: a domain tulajdonosa nyilvánosan közzéteszi, ki küldhet a nevében és hogyan ismerhető fel a valódi levele — a fogadó pedig ellenőriz. Aki nem tesz közzé semmit, arról a rendszer nem tudja eldönteni, hogy a levele valódi-e — és a kétes eseteket a szűrők egyre kevésbé engedik át. 2024 februárja óta a Google és a Yahoo a tömeges küldőknél kötelezővé tette a teljes hitelesítést, és a szigor a kisebb küldők szűrésén is érződik: ami régen „ajánlott jó gyakorlat” volt, ma a belépő szint.

A levelezésed két kockázata — és hogy melyik ellen mi véd

A levelezésedet két különböző irányból érheti baj: a kimenő oldalon a hitelesség a tét (elhiszik-e, hogy a levél tőled jött — és nem küld-e más a nevedben), a bejövő oldalon pedig a szállítás biztonsága (nem hallgatja-e le vagy módosítja-e valaki útközben a hozzád tartó leveleket). A két irányt más-más eszköz védi:

A gyakorlatban a kimenő oldal megfelelő beállíátsa a sürgősebb: ott dől el a kézbesíthetőséged és a domained jó híre. Ezért én is ezzel kezdem: a kimenő levelek biztonságát érintő hármassal, tagonként: mit csinál, miért kell, hogyan állítsd be.

SPF — ki küldhet levelet a nevedben?

Mit csinál pontosan?

Az SPF (Sender Policy Framework) egy nyilvános lista a domained beállításai között arról, hogy mely szerverek jogosultak levelet küldeni a nevedben — a fogadó szerver minden beérkező levélnél ellenőrzi, hogy a küldő szerver rajta van-e ezen a listán. Képzeld el úgy, mint egy portai beléptető-listát: te adod le, ki jöhet be a nevedben, a portás pedig mindenkit ellenőriz.

Hogyan állíthatod be?

Az SPF egyetlen szöveges bejegyzés (TXT rekord) a domained DNS-beállításai között — a pontos tartalmát a levelezés-szolgáltatód adja meg, neked a saját küldőidet kell hiánytalanul felsorolnod benne.

A tipikus tartalma: a levelezésed szolgáltatójának szerverei, plusz minden más rendszer, ami a nevedben levelezhet — és itt bukik el a legtöbb beállítás. A céges levelezésen kívül a nevedben küldhet a weboldalad (űrlap-értesítők), a számlázód, a webshopod (rendelés-visszaigazolók), a hírlevél-rendszered, a CRM-ed. Ha bármelyik kimarad a listáról, annak a levelei hitelesítés nélkül mennek – és pont a legfontosabbak (számla, visszaigazoló emailek) akadhatnak fenn.

Két technikai szabály, amit érdemes tudni: egy domainen csak egy SPF-bejegyzés lehet (ha egy új szolgáltatás „kér egy SPF-rekordot”, azt a meglévőbe kell befűzni, nem mellé tenni), és a lista végén álló jelölés dönti el a szigort — a gyakorlatban a „gyanúsként kezelje” fokozat a biztonságos alap, a teljes tiltás csak gondos ellenőrzés után.

A webshopod rendelés visszaigazoló levelei is csak akkor érnek majd célba, ha a domained hitelesítése rendben van — a WooCommerce webáruház készítés során ezt is beállítom, hogy az első rendeléstől kezdve minden levél kézbesíthető legyen.

DKIM — a digitális pecsét a leveleiden

Mit csinál pontosan?

A DKIM (DomainKeys Identified Mail) minden kimenő leveledre digitális aláírást tesz: a fogadó szerver ebből ellenőrizni tudja, hogy a levél tényleg a te rendszeredből indult, és útközben senki nem nyúlt bele — se a tárgyába, se a tartalmába.

Míg az SPF azt igazolja, honnan jött a levél, a DKIM azt, hogy az-e, aminek indult. A kettő együtt erős: a küldő helye ÉS a levél sértetlensége is bizonyított. Az aláírás a címzettnek láthatatlan — a gépek dolga, nem az embereké.

Hogyan állíthatod be?

A DKIM két részből áll: a levelezés-szolgáltatód a saját oldalán bekapcsolja az aláírást, te pedig a domained DNS-ébe felveszed a hozzá tartozó nyilvános kulcsot — egy TXT bejegyzést, amit a szolgáltató készen ad.

A gyakorlatban ez a legegyszerűbb tag a háromból: a szolgáltatód admin felületén jellemzően egy „DKIM engedélyezése” opció + egy kimásolandó bejegyzés. Egy dologra figyelj: minden küldő rendszerednek saját aláírása lehet – a levelezésé, a hírlevél-rendszeré, a webshopé külön-külön kapcsolandó be. Az ellenőrzés egyszerű: küldj egy próbalevelet egy Gmail-címre, és a levél részleteinél nézd meg, hogy a DKIM „PASS” jelzést kap-e.

DMARC — a szabálykönyv, ami az egészet összefogja

Mit csinál pontosan?

A DMARC (Domain-based Message Authentication, Reporting and Conformance) a szabálykönyv a hármas tetején: kimondja a fogadó szervereknek, mit tegyenek a nevedben érkező, de a hitelesítésen elbukó levelekkel — engedjék, karanténozzák vagy utasítsák el —, és jelentéseket kér, amelyekből te is látod, ki próbál a domained nevében levelezni.

És itt a kulcsmondat, amiért a DMARC a hamisítás-védelem szíve: az SPF és a DKIM önmagában csak ellenőrzést ad — a DMARC az, ami következményt rendel a bukáshoz, és ami a látható „Feladó” mezőt védi. DMARC nélkül bárki küldhet leveleket a domained nevében: az ügyfeleid felé a te neveddel adja el magát, és a domained jó hírét égeti — te pedig nem is tudsz róla, mert jelentés sincs.

Hogyan állíthatod be?

A DMARC szintén egy DNS-bejegyzés — a beállítás művészete viszont a fokozatosság: megfigyelő módban indítod (minden levél megy, de jelentést kapsz), a jelentések alapján befoltozod a hiányokat, és csak utána szigorítasz karanténra, majd elutasításra.

Ez a három lépcső nem túlzó óvatoskodás, hanem a módszer lényege. A megfigyelő mód (a jelentés-gyűjtés) megmutatja, mi levelez ma a domained nevében — és itt szoktak előkerülni az elfelejtett küldők: a régi hírlevél-rendszer, a számlázó, amit más állított be. Amikor a jelentésekben már minden jogos küldőd hitelesítve megy, jöhet a szigorítás — előbb a karantén (a megbukott levelek a spam-mappába), végül az elutasítás (be sem engedik őket). Aki ezt a lépcsőt kihagyja és azonnal tiltásra állít, az jellemzően a saját számláit és visszaigazolóit lövi ki — ez a leggyakoribb önláb-lövés ezen a terepen.

A helyes sorrend — és a tipikus hibák

Mit csinál pontosan?

A biztonságos e-mail beállításának helyes sorrendje: SPF és DKIM → DMARC megfigyelő módban → a jelentések alapján hiánypótlás → fokozatos szigorítás — és csak a rendezett hármas után az MTA-STS.

A tipikus hibák, amikkel a gyakorlatban találkozom:

• Elfelejtett küldők. A weboldalon lévő űrlap, a számlázó, a webshop, a hírlevél-rendszer kimarad a hitelesítésből – pont az üzletileg legfontosabb levelek mennek „papírok nélkül”.
• Két SPF-bejegyzés. Egy új szolgáltatás bekötésekor a meglévő mellé kerül egy második SPF – ettől mindkettő érvénytelen. Egy domain, egy bejegyzés: a újat a régibe kell fűzni.
• Azonnali szigor. A DMARC rögtön elutasításra állítva, megfigyelés nélkül – a nem hitelesített saját levelek eltűnnek, és nem tudod, hogy miért.
• Beállítva és elfelejtve. A hitelesítés nem egyszeri varázslat: minden új küldő rendszer bekötésekor frissítendő, és a jelentésekre időnként rá kell nézni – nálam ez a weboldal karbantartás és üzemeltetés részeként kérhető szolgáltatás.

MTA-STS — a ráadás-réteg: titkosított út a hozzád tartó leveleknek

Mit csinál pontosan?

Az MTA-STS (Mail Transfer Agent Strict Transport Security) a bejövő irányt védi: kikényszeríti, hogy a hozzád tartó leveleket a küldő szerverek titkosított csatornán, ellenőrzött tanúsítvány mellett adják át — így a leveleidet útközben nem lehet lehallgatni, és nem lehet a kapcsolatot titkosítatlan módra „lebutítani”.

A levelek szerverek közti útja alapból nem feltétlenül titkosított — a titkosítás felajánlható, de egy közbeékelődő támadó le tudja beszélni róla a feleket. Az MTA-STS ezt a kiskaput zárja be: a domained nyilvánosan kijelenti, hogy hozzá csak titkosítva lehet levelet hozni, és a protokollt támogató küldők (köztük a legnagyobb szolgáltatók) ezt be is tartják és ki is kényszerítik. Két összetevője van: egy DNS-bejegyzés (a jelzés, hogy a domain kéri a szigort) és egy szabályfájl, amit a domained egy aloldalán, biztonságos kapcsolaton teszel közzé. Fontos következménye, hogy érvényes TLS-tanúsítványt követel a levelezőszervereden — szigorú módban lejárt tanúsítvány mellett a kézbesítés megáll; ez nem hiba, hanem a lényeg: a protokoll rendet követel, a kiegészítő TLS-jelentések (TLS-RPT) pedig azonnal jelzik, ha valahol elakad a titkosított kapcsolat.

Fontos megjegyzés

A nevedben küldött hamis levelek ellen nem az MTA-STS véd — az a fenti hitelesítési hármas dolga. Az MTA-STS a másik irányt zárja: a hozzád tartó levelek útját. Ezért áll a cikk végén, és ezért az utolsó lépés a sorban: a legfontosabb, hogy előbb legyen rendben a kimenő hitelesség — az hozza a kézbesíthetőséget és a hamisítás-védelmet —, és amikor az áll, az MTA-STS teszi teljessé a kört a bejövő oldalon. Kis cégnek is elérhető, nagyobb szervezetnek és érzékeny levelezésnél pedig kifejezetten ajánlott réteg.

Szeretnéd, hogy rendbe tegyem a levelezésedet?

A leveleid kézbesíthetősége nem szerencse kérdése, hanem a beállításoké. Ha most építenél weboldalt, ezek nálam az átadás részei: a weboldal készítés oldalon ismerheted meg, hogyan dolgozom. Ha viszont a meglévő levelezésed állapota érdekel, írd meg, hogy milyen rendszerekből levelezel (pl. kapcsolati űrlap, számlázó, webshop, hírlevél, CRM). 2 munkanapon belül személyesen válaszolok, majd megnézzük, hol áll ma a domained — a hitelesítéstől a titkosításig.