Küldtél már fontos ajánlatot ügyfélnek, aztán két nap múlva kiderült, hogy a levél végig a spam mappában landolt? Ez nem véletlen, és nem is a Gmail hangulatán múlik. Nagy eséllyelaz SPF, DKIM vagy DMARC rekordod hiányzik, vagy rosszul van beállítva, és emiatt a levelező szolgáltatók egyszerűen nem bíznak benned.
2024 februárja óta a Gmail és a Yahoo hivatalosan is megköveteli mindhárom rekordot minden olyan feladótól, aki napi 5000-nél több levelet küld feléjük, de a gyakorlatban a kisebb cégek leveleit is egyre szigorúbban szűrik ugyanezek a rendszerek. Ha még nem foglalkoztál ezzel, most van itt az ideje.
Ebben a cikkben végigmegyünk azon, mi micsoda, hogyan derítsd ki, hol kezelik a domained DNS-ét, és lépésről lépésre megmutatjuk, hogyan állítsd be mindhárom rekordot, akár nálunk van a domained, akár máshol.
Mi az az SPF, DKIM és DMARC, és miért nem működik nélkülük a céges email?
- Az SPF megmondja, mely szerverek küldhetnek levelet a domained nevében.
- A DKIM egy digitális aláírással igazolja, hogy a levél tartalma nem módosult útközben.
- A DMARC pedig kimondja, mit tegyen a fogadó szerver, ha az előző kettő közül valamelyik nem stimmel.
Együtt alkotják azt a hármast, ami nélkül a leveleid simán landolhatnak a spamben, vagy akár vissza is pattanhatnak.
SPF, DKIM és DMARC: mi a különbség a három rekord között?
A három rekord egymásra épül, de más-más kérdésre válaszol. Íme a lényeg egy táblázatban:
| Rekord | Mit ellenőriz | Hol nézed meg | Mi történik, ha hiányzik |
|---|---|---|---|
| SPF | Melyik szerver küldhet levelet a domained nevében | DNS TXT rekord, a domain gyökerén | Bárki küldhet hamisított levelet a domained nevében |
| DKIM | Módosult-e a levél tartalma útközben | DNS TXT rekord, egy selector alnéven | A fogadó nem tudja igazolni a levél eredetiségét |
| DMARC | Mit tegyen a fogadó, ha az SPF vagy DKIM nem stimmel | DNS TXT rekord,_dmarc alnéven | A fogadó saját belátása szerint dönt, ami legtöbbször a spam mappát jelenti |
Gondolj rá úgy, mint egy céges recepcióra:
- Az SPF a vendéglista (ki jöhet be a nevedben),
- a DKIM az aláírásod hitelesítése (tényleg te írtad-e alá),
- a DMARC pedig a szabályzat, ami megmondja, mi legyen azzal, aki nincs a listán vagy hamis aláírással érkezik.
Mi történik, ha egyik sincs beállítva
Rövid válasz: a leveleid egyre nagyobb eséllyel landolnak a spamben, és bárki küldhet hamisított levelet a domained nevében anélkül, hogy te erről tudnál.
Ez nem elmélet. Azadathalász kampányok nagy része pontosan azért működik, mert a támadó egy hiteles kinézetű domainről (a te domainedről) küld levelet, és a fogadó szerver nincs felkészítve arra, hogy ezt kiszűrje. Ha nincs DMARC rekordod, elméletileg bárki írhat „szamlazas@cegedneve.hu” feladóval, és a Gmail simán átengedi.
Miért szigorúbb ez 2026-ban, mint korábban (Google és Yahoo szabályai)
2024 elején a Google és a Yahoo közösen jelentette be, hogy szigorítanak: az 5000 levél feletti napi küldők számára kötelezővé tették az SPF-et, a DKIM-et és egy érvényes DMARC rekordot. Kisebb küldők esetén ez formálisan nem kötelező, de a spamszűrők ugyanazokat a jeleket nézik nálad is.
A gyakorlatban ez azt jelenti, hogy egy 2026-ban induló cég, amelyik ezt kihagyja, jó eséllyel eleve rosszabb pozícióból indul a beérkező levelek versenyében, mint egy olyan cég, amelyik ezt már az első naptól rendben tartja.
Hol van a domained DNS-e, és miért ez dönti el a teendőidet?
Mielőtt bármihez hozzákezdenél, egy dolgot muszáj tisztázni: ki kezeli a domained DNS beállításait.Ha a domained és a tárhelyed is nálunk van, a beállítás pár kattintás. Ha a domain regisztrátora vagy a DNS-e (példáulCloudflare) egy másik szolgáltatónál van, neked kell manuálisan felvenned a rekordokat.
Így derítsd ki 30 másodperc alatt, ki kezeli a DNS-edet
Nyiss egyMXToolbox DNS lekérdezést a domainedre, és nézd meg, hova mutatnak a névszerverek (NS rekordok). Hans1.tarhely.eu vagy hasonló szerepel ott, nálunk van a DNS. Ha mást látsz (cloudflare.com, egy másik regisztrátor neve), akkor ott kell majd rekordot felvenned.
Ha korábbantudatosan választottál domain nevet és emlékszel, hol regisztráltad, ez az egész kérdés egy perc alatt lezárható.
Tárhely.Eu-s domain vagy külső szolgáltatónál lévő domain: mi a gyakorlati különbség
Ha nálunk van a domained, a rendszerünk a cPanelben automatikusan felajánlja az SPF, DKIM és DMARC rekordok létrehozását, méghozzá helyes szintaxissal. Ha külső szolgáltatónál van, a felelősség a tiéd: neked kell a megfelelő TXT rekordokat felvinned, és neked kell vigyáznod, hogy ne legyen benne elgépelés.
Ez utóbbi egyáltalán nem ördöngösség, csak több odafigyelést igényel. Lentebb pontosan végigmegyünk rajta.
Hogyan állítsd be SPF, DKIM, DMARC rekordokat a Tárhely.Eu-nál
Ha nálunk van a domained és a tárhelyed, a beállítás jellemzően 2 kattintás a cPanelben, mert a rendszer automatikusan legenerálja és felviszi a szükséges rekordokat.
Automatikus beállítás a cPanelben, lépésről lépésre
- Lépj be a cPanel felületedre, és keresd meg az „Email Deliverability” (vagy „Levelezés kézbesíthetősége”) menüpontot.
- Válaszd ki a domained a listából. A rendszer megmutatja, hogy az SPF, DKIM, DMARC rekordok jelenleg érvényesek-e.
- Ha valamelyik hiányzik vagy hibás, kattints a „Rekord javítása” vagy „Repair” gombra. A cPanel automatikusan felviszi a helyes TXT rekordot.
- Várj néhány percet, majd frissítsd az oldalt: zöld pipa jelzi, ha minden rendben.
A pontos menüpontok és a részletes lépések aTárhely.Eu tudásbázisában is megtalálhatók, screenshotokkal.
Mit csinál a rendszer a háttérben
A cPanel valójában ugyanazokat a TXT rekordokat viszi fel a DNS zónádba, amiket manuálisan is felvihetnél, csak automatizáltan és helyes szintaxissal. DKIM esetén ráadásul saját 2048 bites kulcspárt generál a domainedhez, amit neked kézzel jóval nehezebb lenne hiba nélkül összerakni.
Mikor van szükség kézi finomhangolásra
Hakülső levélküldő szolgáltatást is használsz (például Mailchimp vagy egyCRM hírlevélküldő funkciója), az automatikus SPF rekord alapból nem fogja tartalmazni azok szervereit. Ilyenkor neked kell hozzáadnod egy sort a szolgáltató dokumentációja alapján, különben az általuk küldött levelek buknak az SPF ellenőrzésen.
Mit csinálj, ha a domain DNS-ét külső szolgáltató kezeli
Ha a domained DNS-ét nem mi kezeljük (mondjuk Cloudflare-en vagy a regisztrátorodnál van), akkor neked kell manuálisan felvenned három TXT rekordot. Nem bonyolult, de elgépelés esetén az egész hitelesítés érvénytelen lesz.
SPF rekord szintaxisa és példa
Az SPF rekord egy TXT bejegyzés a domain gyökerén (@). Egy tipikus rekord így néz ki:
v=spf1 include:_spf.tarhely.eu ~all
Ez azt mondja: „a tárhely.eu szerverei küldhetnek levelet a nevemben, minden más forrás gyanús, de ne dobd el keményen (~all), csak jelöld meg”. A-all már keményebb tiltást jelent.
Egy nagyon fontos szabály, amit sokan elrontanak:egy domainhez csak egy SPF rekord tartozhat. Ha véletlenül két külön SPF TXT rekordot hagysz a DNS-ben (mert korábban is volt egy, és most hozzáadtál egy másikat felülírás helyett), az egész SPF ellenőrzés érvénytelenné válik, méghozzá az RFC szabvány szerint kőkeményen, nem csak „valószínűleg gyanús” módon.
DKIM kulcs generálása és publikálása
A DKIM egy nyilvános-privát kulcspáron alapul. A privát kulcs a küldő szerveren marad, a nyilvános kulcsot pedig egy TXT rekordban teszed közzé, jellemzően ilyen formában:
selector._domainkey.cegedneve.hu
A „selector” nevet a leveleket küldő szolgáltatás adja meg (nálunk ezt a cPanel automatikusan generálja). A rekord tartalma egy hosszú,p= kezdetű karakterlánc, ami maga a nyilvános kulcs. Ma már gyakorlatilag mindenhol 2048 bites kulcsot érdemes használni, az 1024 bites verzió biztonsági szempontból elavultnak számít.
DMARC rekord és a policy fokozatok (none, quarantine, reject)
A DMARC rekord a_dmarc.cegedneve.hu alnéven él, és nagyjából így néz ki:
v=DMARC1; p=quarantine; rua=mailto:dmarc-report@cegedneve.hu; pct=100
Ap= tag a lényeg, ez mondja meg a fogadó szervernek, mit tegyen egy sikertelen ellenőrzés esetén:
- none: csak figyel és riportot küld, nem avatkozik be. Ezzel érdemes indulni, hogy lásd, mi történik.
- quarantine: a gyanús levelet a spam mappába teszi.
- reject: a gyanús levelet egyszerűen eldobja, el sem jut a címzetthez.
Itt jön a csavar, amit kevesen mondanak ki: ha rögtönreject-tel indulsz anélkül, hogy előtte legalább pár hétignone policyval figyelted volna a riportokat, könnyen előfordulhat, hogy a saját, legitim leveleid (például a könyvelődnek küldött számlák egy külső rendszerből) is elvesznek. Fokozatosan érdemes szigorítani, nem egyből a legkeményebb beállítással kezdeni.
Hogyan ellenőrizd a beállítást, és milyen hibák miatt landolsz mégis a spamben
Miután beállítottad a rekordokat, mindenképp ellenőrizd is le őket, méghozzá nem csak azzal, hogy „úgy néz ki, jó”. Egy ingyenes teszt levél és pár perc elég hozzá.
Ingyenes ellenőrző eszközök
- Mail Tester: küldj egy tesztlevelet a megadott címre, és pontszámot kapsz 0-tól 10-ig, részletes indoklással.
- MXToolbox: lekérdezheted külön az SPF, DKIM és DMARC rekordokat, és megmondja, ha hibás a szintaxis.
- Google Admin Toolbox (Check MX): hasonló funkció, ha kifejezetten a Gmail szemszögéből akarod nézni a beállítást.
A leggyakoribb hibák, amik miatt mégis a spamben landolsz
| Hiba | Tünet | Megoldás |
|---|---|---|
| Két SPF rekord egy domainen | Az SPF ellenőrzés teljesen érvénytelenné válik | Csak egy SPF TXT rekord lehet, a többit töröld, és egyet szerkessz |
| Túl sok DNS lookup az SPF-ben | Az SPFpermerror-ral bukik | Az SPF szabvány maximum 10 DNS lookupot enged (include, a, mx, ptr, exists), ennél többet ne halmozz |
| DMARCp=none-on ragad örökre | Semmilyen védelmet nem ad, csak riportot küld | Pár hét megfigyelés után lépj továbbquarantine, majdreject felé |
| Elfelejtett DKIM selector új szolgáltatónál | Az új rendszerből küldött levelek nem hitelesek | Minden új levélküldő szolgáltatáshoz vegyél fel külön DKIM selectort |
| SPF-ből kimaradt egy harmadik fél szolgáltatás | A hírlevélküldő vagy CRM levelei buknak | Vedd fel az adott szolgáltatóinclude: sorát az SPF rekordba |
Mennyi ideig tart a DNS propagáció
A legtöbb esetben 15-30 perc alatt látszik a változás, de a DNS rendszer sajátossága miatt akár 24-48 óráig is eltarthat, mire minden szerver a világon frissíti a gyorsítótárát.Ha közvetlenül a rekord felvitele után teszteled és még nem jó az eredmény, ne pánikolj, várj egy fél órát, és próbáld újra.
Gyakori kérdések az SPF, DKIM és DMARC beállításáról
Kötelező-e mindhárom rekordot beállítani?
Nem kötelező jogilag, de gyakorlatilag igen: SPF és DKIM nélkül a leveleid sokkal nagyobb eséllyel landolnak spamben, DMARC nélkül pedig senki nem védi a domainedet a hamisítás ellen.
Mennyi idő alatt lép életbe egy DNS módosítás?
Jellemzően 15-30 perc alatt, de teljes globális propagációra akár 24-48 órát is érdemes rászánni, mielőtt véglegesnek tekinted az eredményt.
Használhatok külső hírlevélküldő szolgáltatást (Mailchimp, MailerLite) az SPF és DKIM mellett?
Igen, de az adott szolgáltató sajátinclude: sorát hozzá kell adnod az SPF rekordodhoz, és jellemzően saját DKIM selectort is be kell állítanod a fiókjukban.
Mi a különbség a DMARC none, quarantine és reject policy között?
A none csak megfigyel és riportot küld, a quarantine a gyanús leveleket spambe teszi, a reject pedig teljesen eldobja őket, mielőtt eljutnának a címzetthez.
Kell fizetni ezekért a rekordokért?
Nem, az SPF, DKIM és DMARC beállítása maga ingyenes, hiszen ez csak DNS bejegyzésekről szól. Amiért esetleg fizetsz, az a tárhely vagy a domain szolgáltatás, ami a DNS-t hosztolja.
Mi történik, ha rossz SPF rekordot állítok be?
A legrosszabb esetben a saját, legitim leveleid is bukhatnak az ellenőrzésen, és spambe kerülhetnek, vagy vissza is pattanhatnak. Ezért érdemes minden módosítás után egy Mail Tester teszttel ellenőrizni az eredményt.
Összefoglalás
Az SPF, DKIM és DMARC nem valami extra, amit csak a nagyvállalatoknak kell megoldaniuk. Ez ma már az alapja annak, hogy a céges leveleid egyáltalán célba érjenek, nem pedig a spam mappában landoljanak. A jó hír, hogy ha nálunk van a domained, ez a gyakorlatban két kattintás, ha máshol, akkor is csak három TXT rekordot kell felvenned, amihez ez a cikk pontos mintát adott.
Ha még nem is tisztázott, kinél van a domained, vagy most választanál egyet,olvasd el, mire figyelj domain névválasztásnál. Ha pedig Cloudflare-t vagy más külső DNS szolgáltatót használsz,ez a cikk az alapoktól magyarázza el, mire jó és hogyan működik.
