Van egy hibabejelentés, ami minden webfejlesztő postaládájában megfordul: „a vásárlók nem kapják meg a visszaigazoló e-mailt”. Vagy: „az ajánlatom a spamben landolt az ügyfélnél”. Vagy a legkellemetlenebb: „valaki az én e-mail-címemről küldött ki egy hamis számlát”.
Mindhárom mögött ugyanaz az ok áll. A domained nem bizonyítja a fogadó szervereknek, hogy a levél tényleg tőled jött. Nem a szöveggel van baj, nem a tárhellyel, és nem is a WooCommerce-szel. A DNS-beállításokkal.
Ebben a cikkben végigmegyünk azon, hogyan rakod ezt rendbe: mit kell felmérni, milyen három rekord kell a domainedhez, milyen sorrendben, és hogyan ellenőrzöd, hogy tényleg működik-e.
Miért lett ez hirtelen ennyire fontos?
Az e-mail protokollját akkor tervezték, amikor a hálózaton mindenki ismert mindenkit. Ezért a „Feladó” mezőbe bármit be lehet írni. Ez a nyitott kapu tartja életben a mai napig az adathalászatot.
A nagy szolgáltatók erre válaszul megfordították a logikát: nem a rossz leveleket próbálják kiszűrni, hanem a jókat kérik igazolásra. 2024 februárjától a Gmail és a Yahoo kötelezővé tette a hitelesítést a nagy volumenű küldőknél, 2025-ben a Microsoft is követte őket. A szabály formálisan a napi több ezer levelet küldőkre vonatkozik, de a szűrők pontrendszere mindenkire hat. Egy hitelesítetlen domainről érkező, napi három levél ugyanúgy gyanús marad.
Magyarul: ami két éve „ajánlott jó gyakorlat” volt, az ma belépőszint.
1. lépés: írd össze, hány rendszer küld levelet a nevedben
Ez az a lépés, amit a legtöbben kihagynak, és emiatt bukik el a beállítás fele. Egy átlagos kisvállalkozás domainjéről nem egy, hanem négy-hat különböző rendszer küld levelet:
- A céges levelezés (Google Workspace, Microsoft 365, vagy a tárhelyszolgáltató levelezője)
- A weboldal — kapcsolati űrlapok értesítői (Contact Form 7, Fluent Forms, Elementor Forms)
- A webshop — rendelés-visszaigazolók, számlaértesítők, jelszó-emlékeztetők
- A hírlevélrendszer (Mailchimp, Sender, MailerLite, Brevo)
- A számlázóprogram (Számlázz.hu, Billingo), ha a te nevedben küldi ki a számlát
- A CRM vagy foglalási rendszer, ha van ilyened
Vegyél elő egy jegyzettömböt, és írd fel mindet. Erre a listára szükséged lesz a következő lépéseknél, és ha kihagysz egyet, annak a rendszernek a levelei fognak fennakadni. Jellemzően pont a legfontosabbak: a számla és a visszaigazoló.
2. lépés: WordPress esetén először az SMTP-t rendezd
Ez WordPress-specifikus, és megelőzi az összes DNS-beállítást. A WordPress alapból a szerver PHP mail() függvényével küld levelet.
Ez a legrosszabb megoldás, ami létezik:
- a levél a tárhelyszerverről indul, nem a levelezőszerveredről, tehát bukja az SPF-et,
- nincs rajta DKIM-aláírás,
- ha megosztott tárhelyen vagy, egy másik ügyfél spamküldése miatt is feketelistára kerülhetsz.
A megoldás: telepíts egy SMTP-bővítményt (pl: Fluent SMTP bővítmény jó választás és ingyenes), és állítsd be, hogy a WordPress a valódi levelezőszerveredre adja át a leveleket. Nagyobb webshopnál érdemes dedikált küldőszolgáltatót használni (Brevo, Postmark, Amazon SES) — ezek jobb kézbesíthetőséget adnak, és látod a küldési naplót is.
Amíg ez nincs meg, a DNS-beállításokkal nem érdemes bajlódni.
3. lépés: SPF — ki küldhet a domained nevében
Az SPF (Sender Policy Framework) egy nyilvános lista arról, mely szerverek jogosultak levelet küldeni a domained nevében. A fogadó szerver minden levélnél megnézi, hogy a küldő szerepel-e rajta.
Egyetlen TXT rekord a domained DNS-zónájában, ami körülbelül így néz ki:
v=spf1 include:_spf.google.com include:spf.brevo.com ~allAz include: részek jönnek a szolgáltatóktól — mindegyik megadja a sajátját a dokumentációjában. A te dolgod, hogy a 2. lépésben összeírt lista minden elemét belefűzd.
Amire figyelj
Egy domainen csak egy SPF rekord lehet. Ha egy új szolgáltatás azt kéri, hogy „vegyél fel egy SPF rekordot”, azt a meglévőbe kell befűzni, nem mellé tenni. Két SPF rekordtól mindkettő érvénytelen lesz.
Tíz DNS-lekérdezés a limit. Minden include: egy lekérdezést jelent, és a beágyazottak is számítanak. Tíz fölött az egész rekord hibára fut. Ha sok szolgáltatód van, SPF-tömörítő szolgáltatásra lesz szükséged.
A rekord végén álló jelölés dönti el a szigort. A ~all („kezeld gyanúsként”) a biztonságos alapbeállítás. A -all (teljes tiltás) csak akkor, ha már biztosan minden küldőd rajta van a listán.
4. lépés: DKIM — digitális pecsét a leveleiden
A DKIM (DomainKeys Identified Mail) minden kimenő levelet aláír egy titkos kulccsal. A fogadó szerver a DNS-ben közzétett nyilvános kulccsal ellenőrzi az aláírást, és ebből két dolgot tud meg: a levél a te rendszeredből indult, és útközben senki nem módosította.
Míg az SPF azt igazolja, honnan jött a levél, a DKIM azt, hogy sértetlen-e. A kettő együtt szükséges.
A beállítás két részből áll: a szolgáltatód oldalán bekapcsolod az aláírást, majd a kapott kulcsot felveszed a DNS-be. Ez általában egy CNAME vagy TXT rekord, ilyesmi névvel:
selector1._domainkey.tedomained.huA legfontosabb tudnivaló: minden küldő rendszerednek saját DKIM-kulcsa van. A céges levelezésé, a hírlevélrendszeré és a webshop küldőszolgáltatójáé külön-külön kapcsolandó be és külön-külön kerül a DNS-be.
5. lépés: DMARC — a szabálykönyv, ami összefogja az egészet
Az SPF és a DKIM önmagában csak ellenőrzést ad. Következményt nem rendel a bukáshoz, és a látható „Feladó” mezőt sem védi. Ez a DMARC dolga.
A DMARC két dolgot mond ki: mit tegyen a fogadó szerver a hitelesítésen elbukó, de a te nevedben érkező levelekkel, és hova küldje a jelentéseket arról, hogy ki próbál a domained nevében levelezni.
Ez utóbbi a legalulértékeltebb funkció. DMARC nélkül nemcsak hogy bárki küldhet a nevedben, de nem is tudsz róla, hogy megtörtént.
A DMARC bevezetése három lépcsőben
Ezt a részt semmiképp ne rövidítsd le. A rekord a _dmarc.tedomained.hu néven jön létre.
Első lépcső — megfigyelés. Minden levél megy tovább, de te jelentést kapsz róluk:
v=DMARC1; p=none; rua=mailto:dmarc@tedomained.huMásodik lépcső — karantén. Két-négy hét jelentésolvasás után, amikor már minden jogos küldőd hitelesítve megy, a megbukott levelek a spam mappába kerülnek:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@tedomained.huHarmadik lépcső — elutasítás. A megbukott levelek be sem jutnak:
v=DMARC1; p=reject; rua=mailto:dmarc@tedomained.huAki kihagyja a megfigyelési szakaszt és rögtön p=reject-tel indít, az a saját számláit és visszaigazolóit lövi ki. Ez a leggyakoribb hiba ezen a terepen.
A nyers XML-jelentések olvashatatlanok, de van rá ingyenes feldolgozó (Postmark DMARC Digest, dmarcian, EasyDMARC). Ezek e-mailben, emberi nyelven küldik el, mi történt a domaineden.
Hogyan ellenőrizd, hogy tényleg működik?
| Mit akarsz megtudni | Hogyan |
|---|---|
| Átmegy-e egy konkrét levél a hitelesítésen | Küldj egy próbalevelet Gmail-címre, majd a levélnél a három pont → „Eredeti megjelenítése”. Az SPF, DKIM és DMARC sorban PASS-t kell látnod. |
| Összesített pontszám és hibalista | mail-tester.com — küldesz egy levelet a kapott címre, és 10-es skálán értékeli. |
| A DNS-rekordok szintaktikai ellenőrzése | MXToolbox SPF/DKIM/DMARC ellenőrzői |
| A WordPress tényleg elküldte-e | WP Mail SMTP vagy Fluent SMTP küldési naplója |
Fontos: a próbalevelet mindegyik küldő rendszerből külön el kell küldeni. Attól, hogy a céges leveled átmegy, a webshop visszaigazolója még bukhat.
Tipikus hibák, amikkel magyar tárhelyeknél találkozom
- Nem ott van a DNS-zóna, ahol keresed. A domain regisztrátora és a tárhely gyakran különböző cég. A rekordokat oda kell felvenni, ahol a névszerverek ténylegesen mutatnak.
- A tárhelyszolgáltató alapból generál egy SPF rekordot, ami csak a saját szervereit tartalmazza. Ha Google Workspace-t vagy külső hírlevélrendszert használsz, ezt bővíteni kell.
- A domain végpontja bekerül a rekord nevébe kétszer. Néhány felületen a mezőbe csak a
_dmarcrészt kell írni, máshol a teljes_dmarc.tedomained.hunevet. Ha nem működik, ez az első, amit ellenőrizz. - Türelmetlenség. A DNS-módosítás terjedése órákig eltarthat. Ne állítsd át ötször.
- „Beállítottuk, kész.” Minden új küldőrendszer bekötésekor frissíteni kell az SPF-et és fel kell venni az új DKIM-kulcsot. Ez üzemeltetési feladat, nem egyszeri projekt.
És ha ez megvan: MTA-STS a bejövő oldalra
A fenti három rekord a kimenő leveleidet védi. Van egy negyedik réteg, az MTA-STS, ami a másik irányt: kikényszeríti, hogy a hozzád tartó leveleket a küldő szerverek titkosított csatornán, érvényes tanúsítvány mellett adják át.
Ez nem véd a nevedben küldött hamis levelek ellen — arra a hitelesítési hármas való. Cserébe megakadályozza, hogy valaki útközben lehallgassa vagy „lebutítsa” a kapcsolatot. Két összetevője van: egy DNS-rekord és egy szabályfájl, amit a domained egy aldomainjén, HTTPS-en teszel közzé.
Érzékeny levelezésnél (ügyvédi iroda, egészségügy, pénzügyi szolgáltatás) mindenképp érdemes. Kisvállalkozásnál a hármas rendbetétele után jöhet, nem előtte.
Gyakori kérdések
Igen. A szűrők nem a mennyiséget nézik, hanem a bizonyítékot. Kis volumennél éppen az a baj, hogy nincs kialakult küldési előéleted, amire a szolgáltató támaszkodhatna. A hitelesítés ezt pótolja.
A saját szerverei oldalát általában igen. A domained DNS-zónájában lévő rekordokat viszont csak te vagy a megbízottad tudja beállítani, és a külső küldőidről (számlázó, hírlevél, webshop) a tárhelyszolgáltató nem is tud.
Igen, ezért fokozatos a módszer. Először azt javasolnám, hogy minden alapbeállítást ments le egy külön dokumentumba, hogy hiba esetén visszaállíthasd a kiinduló állapotot.
A DMARC-nál megfigyeléssel indulsz, és csak akkor szigorítasz, amikor a jelentések szerint minden jogos küldőd rendben átmegy. Ha ezt betartod, nincs kockázat.
A rekordok felvétele egy-két óra. A DMARC teljes bevezetése viszont hetek kérdése, mert a megfigyelési szakaszt ki kell várni.
Mindegyiknek külön kell. Ez a nem használt, „parkoló” domainekre is igaz: azokra egy szigorú DMARC és egy üres SPF rekord való, hogy senki ne tudjon a nevükben levelezni.
Segítsek rendbe tenni?
A levelek kézbesíthetősége nem szerencse kérdése, hanem beállításoké — és ezek a beállítások egyszer, gondosan elvégezve évekig dolgoznak helyetted.
Ha nem szeretnél DNS-rekordokkal bajlódni, írd meg, milyen rendszerekből leveleztek (céges levelezés, webshop, számlázó, hírlevél), és átnézem, hol áll ma a domained. Kapcsolatfelvétel ⭢
