Miért landol a WooCommerce visszaigazoló e-mailed a SPAM-ben? SPF, DKIM és DMARC kkv-knak

Ha WooCommerce webshopot üzemeltetsz, ezt a mondatot valószínűleg ismered: „Nem kaptam visszaigazolást a rendelésemről.” A vásárló fizetett, a rendelés bent van az adminban, a WordPress szerinte kiküldte a levelet, a másik oldalon mégsem érkezik meg semmi. Vagy megérkezik, csak épp a SPAM mappában, két nappal később.

Ez ritkán a vásárló hibája. A háttérben egy jól körülhatárolható technikai probléma áll: hiányzik vagy hibás a leveleid hitelesítése. A jó hír, hogy javítható, többnyire ingyen, néhány DNS-rekord helyes beállításával. A rossz hír, hogy 2024 óta a nagy levelezők (Gmail, Yahoo, majd 2025-től a Microsoft is) rendesen megszigorították a szabályokat: ami korábban ajánlott volt, az mostanra kötelező minimum.

Ebben a cikkben végigvezetünk a teljes láncon: mi történik a levéllel a „Megrendelés” gombtól a postaládáig, mit néznek a fogadó szerverek, és pontosan hogyan állítsd be az SPF, DKIM és DMARC hármast cPanel és külső DNS alatt. Az útmutató laikus WordPress-felhasználóknak is követhető, de a bemásolható DNS-rekordok miatt tapasztaltabb üzemeltetőknek is hasznos.

Röviden: mit kell tenned?

Ha a leveled spambe megy, három dolog hiányzik a domainedről, és egy a WordPressből:

1. SPF – egyetlen TXT-rekord, ami felsorolja, mely szerverek küldhetnek a nevedben.
2. DKIM – digitális aláírás, amivel a szervered „lepecsételi” a leveleket.
3. DMARC – szabály, ami megmondja a fogadónak, mi legyen a bukott levéllel.
4. Hitelesített SMTP a WordPressben (pl. FluentSMTP), a nyers php mail() helyett.

Ha ez a négy rendben van, és egy próbalevél 10/10-et kap a Mail-Testeren, a leveleid ott landolnak, ahol kell. A többi már csak a részletek.

Miért fájó egy elveszett visszaigazoló? A „csendes konverziógyilkos”

Képzeld el a vásárlói élményt a levél nélkül. Valaki kifizet nálad 45 000 forintot egy termékért, aztán csend. Nincs visszaigazolás, nincs számla, nincs szállítási értesítő. Mit gondol ilyenkor?

A jobbik eset, hogy csak ideges lesz, és ír vagy telefonál az ügyfélszolgálatnak. Ez neked plusz munka és idő. A rosszabb eset, hogy azt hiszi, a fizetés nem ment át, ezért újra megpróbálja (dupla rendelés, dupla terhelés), vagy épp azt hiszi, átverték, és letiltja a terhelést a bankjánál. Ez utóbbi a chargeback, a webshopok egyik legdrágább rémálma: nemcsak a pénzt veszíted el, hanem a fizetési szolgáltatód szemében is romlik a megítélésed, tartósan magas chargeback-arány mellett pedig akár a bankkártyás fizetést is elveszítheted.

Ezért „csendes konverziógyilkos” a kézbesíthetetlen tranzakciós levél: nem látszik a statisztikában, nem jelez hibát a WooCommerce, a rendelés sikeresnek tűnik. Közben a bizalom, ami a visszatérő vásárláshoz kellene, elpárolog.

A piac megváltozott: a 2024–2026-os szigorítási hullám

Régen a levelezés amolyan „küldd ki és reménykedj” műfaj volt. Ennek 2024 februárjában vége lett. A Google és a Yahoo közösen bevezette a bulk sender (tömeges feladó) követelményeket: aki napi 5000-nél több levelet küld Gmail-fiókokra, annak kötelezően be kell állítania az SPF-et, a DKIM-et és a DMARC-ot, egyszerűvé kell tennie a leiratkozást, és 0,3% alatt kell tartania a spam-panaszok arányát. Ezt maga a Google jelentette be a hivatalos Gmail-blogban, a Yahoo pedig a postmaster blogján.

2025 tavaszán a Microsoft is csatlakozott. A hivatalos Microsoft Tech Community bejelentés szerint 2025. május 5-től az Outlook.com, Hotmail.com és Live.com címekre napi 5000+ levelet küldő feladóknak szintén kötelező az SPF, DKIM és DMARC. A nem megfelelő levelek először a Junk mappába kerülnek, majd akár teljes elutasítás is jöhet, 550 5.7.15 Access denied hibakóddal.

Egy gyakori félreértést tisztázzunk. Az „5000 levél/nap” küszöb formálisan a tömeges feladókra vonatkozik. A mögötte lévő hitelesítési logikát (SPF+DKIM+DMARC igazítás) viszont a szűrők minden levélnél alkalmazzák. Egy kis webshop, aki naponta 30 visszaigazolót küld, ugyanúgy megbukhat a hitelesítésen, mint egy hírlevélgyár. Nála nem a küszöbátlépés a baj, hanem az, hogy a szűrő egy hitelesítetlen, gyanús levelet lát. A gyakorlatban tehát ez mindenkire vonatkozik, aki komolyan veszi a kézbesíthetőséget.

Hogy mekkora a tét számokban? A Validity 2024-es kézbesíthetőségi benchmarkja szerint globálisan az e-mailek nagyjából hatoda soha nem jut el a postaládába, így az átlagos inbox-placement 84% körül mozog (Validity 2025 Benchmark Report, PDF). A GlockApps 2024 első negyedéves mérése hasonlót mutatott: 83,1%-os átlagos kézbesítés, amiből 10,5% egyenesen a spam mappában landolt (GlockApps-adatok, Uplers összefoglaló). Ezek marketinglevél-átlagok. A helyesen beállított tranzakciós levél ennél sokkal jobban teljesíthet, a hitelesítetlen viszont sokkal rosszabbul.

Miért nem elég a WordPress alapértelmezett megoldása?

A WordPress a wp_mail() függvénnyel küld levelet, ami alapból a PHP beépített mail() funkcióját használja, az pedig a szerver helyi levéltovábbítóján (általában sendmailen) keresztül dobja ki a levelet. Ezzel három strukturális baj van:

• Nincs hitelesítés. A php mail() nem ír alá DKIM-mel, és gyakran rossz Return-Path fejlécet állít be, ami elrontja az SPF-igazítást.
• Osztott (shared) tárhelyen közös IP-t használsz. Ha a szomszédod ugyanarról az IP-ről spamet küld, a te leveled is bűnhődik. Ez a „bad neighbor” hatás: a reputációd a szomszédaidon is múlik.
• Nincs visszajelzés. Ha a levél elveszik, a WooCommerce attól még elküldöttnek tekinti. Nem kapsz hibát, nem tudsz róla.

A megoldás mindig ugyanaz a két lépés. Először rendbe rakod a domain hitelesítését (SPF, DKIM, DMARC, PTR). Utána a WordPresst egy hitelesített, ellenőrzött küldési útra állítod. A cikk hátralévő része pontosan ezt tanítja meg.

Hogyan szűrik a leveleket a fogadó szerverek?

Ahhoz, hogy megjavítsd a kézbesíthetőséget, először értened kell, mi történik a levéllel, miután elhagyta a szervered. Sokan úgy képzelik, hogy a levél „elmegy” és „megérkezik”. Valójában egy több lépcsős ellenőrzésen megy át, ahol bármelyik ponton kiköthet a spam mappában.

A levél útja a checkouttól a postaládáig

1. WooCommerce esemény. A vásárló megnyomja a „Megrendelés” gombot, ez levélküldést vált ki (pl. new_order, customer_processing_order).
2. wp_mail(). A WordPress összeállítja a levelet (fejlécek, tárgy, HTML törzs) és átadja a levéltovábbítónak.
3. MTA (Mail Transfer Agent). Ez a tényleges levelezőszerver (pl. Exim cPanel alatt, vagy Postfix egy Mailcow rendszerben), ami kapcsolatba lép a címzett szerverével.
4. DNS-ellenőrzés a fogadó oldalon. A címzett szervere lekéri a domained rekordjait: stimmel az SPF? Van érvényes DKIM-aláírás? Mit mond a DMARC?
5. Spamszűrő. A levél átfut egy szűrőn. A világon leggyakoribbak a SpamAssassin és az Rspamd, a nagyoknál pedig a Google, a Microsoft és a Barracuda saját, gépi tanulással működő rendszerei. A szűrő pontszámot ad.
6. Döntés. A pontszám és a reputáció alapján a levél az Inbox vagy a Spam/Junk mappába kerül, vagy a szerver visszautasítja (reject), és el sem jut a címzetthez.

A tanulság: a szervered csak a lánc elejét irányítja. A 4–6. lépés a fogadó kezében van, és ott a domain-hitelesítés dönt.

Mit néz a szűrő? A három nagy tényező

1. Az IP és a domain reputációja. A fogadó megnézi, milyen IP-ről jött a levél, és annak van-e előélete. Kritikus eleme a reverse DNS (PTR) rekord: ez igazolja, hogy a küldő IP-cím tényleg ahhoz a hostnévhez tartozik, amit a szerver magáról állít. Ha nincs PTR, vagy nem egyezik (az úgynevezett FCrDNS hibája), az azonnal gyanús. A Gmail/Yahoo követelmények kifejezetten megkövetelik az érvényes forward és reverse DNS-t.

2. Fejléc-egyezőség (alignment). A szűrő összeveti a látható feladót (From: fejléc, amit a vásárló lát) a technikai borítékfeladóval (Return-Path, amit a szerverek használnak). Ha ezek különböző domainre mutatnak igazítás nélkül, a DMARC megbukhat. Ez a leggyakoribb rejtett hiba: a levél látszatra a webshop.hu-tól jön, technikailag viszont a tárhelyszolgáltató szerveréről, srv123.tarhely.hu boríték-feladóval, és a kettő nem áll össze.

3. Tartalmi pontszám. A törzs is számít. Pontlevonást okoznak a klasszikus spam-kiváltó szavak („INGYEN!!!”, „KATTINTS MOST”, csupa nagybetűs tárgy), a törött HTML, a képek túlsúlya szöveg nélkül, és amit sokan nem tudnak: a hiányzó plain text alternatíva. Egy jól felépített levél mindig tartalmaz text/plain és text/html verziót is. Ha csak HTML van, a szűrő gyanakszik.

Egy megbukott levél fejlécének elemzése

A leghasznosabb hibakeresési képesség, amit megtanulhatsz: a levélfejléc olvasása. Gmailben a megnyitott levélnél a jobb felső menüből az „Eredeti megjelenítése” opcióval éred el. Keresd az Authentication-Results sort. Egy problémás levél így nézhet ki:

Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of bounce@srv123.tarhely.hu
         does not designate 185.10.20.30 as permitted sender)
         smtp.mailfrom=bounce@srv123.tarhely.hu;
       dkim=neutral (no signature);
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=webshop.hu

Fordítsuk le, mit üzen ez:

• spf=softfail: az SPF nem sikerült rendesen, a küldő IP nincs egyértelműen felhatalmazva. A softfail a „gyenge” nem, amit a ~all beállítás okoz.
• dkim=neutral (no signature): egyáltalán nincs DKIM-aláírás. Ez a legárulkodóbb.
• dmarc=fail: mivel sem az SPF, sem a DKIM nem passzolt igazítva, a DMARC megbukik.

Így néz ki ugyanez a fejléc, miután mindent beállítottál. Ezt a képet célozzuk:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@webshop.hu
         designates 185.10.20.30 as permitted sender)
         smtp.mailfrom=bounce@webshop.hu;
       dkim=pass header.i=@webshop.hu header.s=default;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=webshop.hu

Figyeld a különbséget: mindhárom sor pass-re vált, a smtp.mailfrom és a header.from ugyanarra a domainre (webshop.hu) mutat (ez az igazítás), a DKIM-nél pedig megjelenik a szelektor (header.s=default). Ha a saját tesztleveled fejléce így néz ki, technikailag rendben vagy.

A technikai „szent háromság”: SPF, DKIM, DMARC

Most jön a lényeg. Ez a három rekord dönti el, hogy a leveled megbízhatónak számít-e. Egyenként vesszük őket, mindegyiknél egy hétköznapi hasonlattal, a pontos szintaxissal és a jellemző buktatókkal.

1. SPF – Sender Policy Framework

Mi ez, hétköznapian? Az SPF a domained vendéglistája. Megmondja a világnak: „Az én nevemben csak ezek a szerverek küldhetnek levelet.” Ha egy levél olyan IP-ről érkezik, ami nincs a listán, a fogadó tudja, hogy valami nem stimmel.

Technikailag az SPF egy TXT-rekord a domained DNS-zónájában. Egy tipikus rekord:

v=spf1 mx ip4:185.10.20.30 include:_spf.google.com ~all

Tagonként:

Az ~all vagy -all kérdés. A záró mechanizmus dönti el, mi legyen a listán nem szereplő küldőkkel. A ~all (softfail) azt jelenti: „valószínűleg nem jogos, de ne dobd el”. Biztonságos kezdéshez ez az ajánlott. A -all (hardfail) azt jelenti: „biztosan nem jogos, dobd el”. Erősebb védelem, de csak akkor váltsd erre, ha 100%-ig biztos vagy benne, hogy minden legitim küldőd szerepel a rekordban. Különben a saját leveleidet is kilövöd.

A legveszélyesebb buktató: a 10 DNS-lookup limit. Az SPF-szabvány (RFC 7208) kimondja, hogy egy SPF-kiértékelés legfeljebb 10 DNS-lekérdezést végezhet. Minden include, a, mx, ptr, exists és redirect mechanizmus lekérdezéseket generál. Ha túl sok szolgáltatót fűzöl össze (pl. Google + Microsoft + Mailchimp + Brevo + saját szerver), könnyen átléped a 10-et. Ilyenkor az SPF PermError-ral megbukik, onnantól pedig minden leveled megbukhat az SPF-en, akkor is, ha a rekord ránézésre jó. Megoldás: csökkentsd az include-ok számát, vagy használj SPF-lapítást (flattening).

Fontos korlát: önmagában az SPF nem elég. Ha a levelet valaki továbbküldi (forward), az SPF gyakran megbukik, mert megváltozik a küldő IP. Ezért kell mellé a DKIM.

2. DKIM – DomainKeys Identified Mail

Mi ez, hétköznapian? A DKIM egy pecsét a levélen. A szervered egy titkos (privát) kulccsal digitálisan aláírja a kimenő levelet. A fogadó a domained DNS-éből lekéri a hozzá tartozó nyilvános (publikus) kulcsot, és ellenőrzi az aláírást. Ha stimmel, két dolgot is bebizonyítottál: a levél tényleg a te domainedről jött, és a tartalma nem változott meg útközben.

Ez az aszimmetrikus kriptográfia klasszikus alkalmazása. A privát kulcs a szervereden marad (soha ne oszd meg), a publikus kulcs bárki számára elérhető a DNS-ből.

A szelektor (selector). Egy domain többféle rendszerrel is küldhet levelet (saját szerver, Google, hírlevélszolgáltató), és mindegyiknek lehet saját DKIM-kulcsa. Hogy ne keveredjenek, mindegyikhez egy szelektor tartozik, ami egy egyszerű címke a kulcs elején. A DNS-ben így néz ki:

default._domainkey.webshop.hu

Itt a default a szelektor. A cPanel jellemzően a default szelektort használja, a Google a google-t, a Brevo a brevo1/brevo2-t. A DNS TXT-rekord tartalma pedig valahogy így fest (rövidítve):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...(hosszú publikus kulcs)...IDAQAB

A v=DKIM1 a verzió, a k=rsa a kulcs típusa, a p=... pedig maga a publikus kulcs. A gyakorlatban ezt a rekordot nem kézzel írod: a cPanel vagy a levelezőszolgáltatód generálja, te csak bemásolod a DNS-be. A lényeg, hogy értsd, mit másolsz.

A DKIM nagy előnye, hogy túléli a továbbítást. Mivel az aláírás a levél tartalmához kötődik (nem az IP-hez, mint az SPF), egy továbbküldött levél DKIM-je is érvényes maradhat. A DMARC-igazításban ezért a DKIM a robusztusabb láb.

3. DMARC – Domain-based Message Authentication, Reporting, and Conformance

Mi ez, hétköznapian? Ha az SPF a vendéglista és a DKIM a pecsét, akkor a DMARC a biztonsági szabályzat. Megmondja a fogadónak, mit tegyen, ha egy levél megbukik az SPF-en és a DKIM-en is. Enélkül a fogadó saját belátása szerint dönt, a DMARC-cal viszont te szabod meg a szabályt.

A DMARC két dolgot csinál egyszerre. Egyrészt igazítást (alignment) követel meg: a látható From: domainnek egyeznie kell az SPF vagy a DKIM domainjével. Másrészt házirendet ad, hogy mi legyen a bukott levéllel. A rekord a _dmarc aldomainen ül:

_dmarc.webshop.hu

Egy jól felépített példa:

v=DMARC1; p=none; rua=mailto:dmarc@webshop.hu; ruf=mailto:dmarc@webshop.hu; fo=1; adkim=r; aspf=r; pct=100

A három házirend, ezt kell jól időzíteni:

1. p=none (megfigyelő mód). A fogadó nem tesz semmit a bukott levéllel, viszont riportokat küld neked. Ez az adatgyűjtő fázis: megtudod, kik küldenek a nevedben, mi bukik meg, és miért. Mindig innen indulj.
2. p=quarantine (karantén). A bukott leveleket a fogadó a spam/junk mappába teszi. Ide akkor lépj, ha a riportokból már látod, hogy minden legitim küldőd rendben van.
3. p=reject (elutasítás). A bukott leveleket a fogadó eldobja, el sem jutnak a címzetthez. Ez a legerősebb védelem a domain-hamisítás (spoofing) ellen, de csak akkor kapcsold be, ha teljesen biztos vagy a beállításaidban.

Riportok olvasása. A rua címre naponta érkező XML-riportok elsőre ijesztőek, de ingyenes eszközök olvashatóvá teszik őket: a dmarcian, a Postmark ingyenes DMARC-eszköze vagy az EasyDMARC. Ezekből kiderül, hogy pl. a Google szerverei 100%-ban átmennek, de van egy ismeretlen IP, ami a nevedben próbál küldeni. Az lehet egy elfelejtett szolgáltatás, vagy egy tényleges spoofing-kísérlet.

Mennyire elterjedt a DMARC? Az EasyDMARC 2026-os adoptációs jelentése szerint a legnagyobb domainek körében a DMARC-lefedettség nagyjából 52%-ra nőtt, de a domainek több mint fele még mindig a p=none monitorozó szinten ragad, ami spoofing ellen valós védelmet nem nyújt (EasyDMARC-adatok, összefoglaló). A DMARC felvétele tehát már nem versenyelőny, hanem alapelvárás, a p=none-nál megállni viszont fél megoldás.

Miért kell mind a három együtt?

Röviden: egyik sem elég önmagában, de együtt lefedik egymás gyengéit. Az SPF megbukik továbbításnál, ott a DKIM ment meg. A DKIM önmagában nem mondja meg, mi legyen a bukott levéllel, azt a DMARC mondja meg. A DMARC-nak pedig legalább az egyik lábra (SPF vagy DKIM) igazítva passzolnia kell, ezért kell mindkettőt beállítani. A 2024-es Gmail/Yahoo és a 2025-ös Microsoft követelmények pont ezt írják elő.

Egy lépéssel tovább: BIMI (opcionális)

Ha már eljutottál a p=quarantine vagy p=reject házirendig, megnyílik előtted a BIMI (Brand Indicators for Message Identification). Ezzel a saját logód jelenhet meg a leveleid mellett a támogató postaládákban (Gmail, Apple Mail, Yahoo), egy kis kör alakú márkajelként a feladó neve mellett. Webshopnál ez felismerhetőséget és bizalmat ad.

A BIMI feltétele a szigorú DMARC-házirend, egy speciális SVG-formátumú logó, és a legtöbb szolgáltatónál egy fizetős VMC-tanúsítvány. Emiatt inkább a komolyabb, márkatudatos webshopoknak éri meg. Kkv-ként nyugodtan tekintsd későbbi bónusznak: előbb a hármas legyen tökéletes, a BIMI ráér utána.

Mit kezdj a DMARC-riportokkal? Gyakorlati példa

A DMARC beállítása után pár napon belül elkezdenek érkezni az összesítő riportok a rua címre. Ezek nyers XML-fájlok, amiket a Google, a Microsoft és a többi nagy fogadó küld arról, hogy a te domainedről érkező levelek átmentek-e a hitelesítésen. Ránézésre riasztóak, de a lényeg pár sorban összefoglalható. Egy riport-részlet így néz ki:

<record>
  <row>
    <source_ip>185.10.20.30</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Ezt így olvasd: a 185.10.20.30 IP-ről 42 levél ment ki a jelentési időszakban, és mindegyik átment a DKIM-en és az SPF-en is. Ez a saját szervered, minden rendben. A gond akkor kezdődik, ha egy ismeretlen IP-t látsz sok levéllel és fail értékekkel. Két eset lehet: vagy egy legitim, de elfelejtett küldőd (pl. a számlázó rendszer, egy hírlevélszolgáltató, amit fel kell venned az SPF-be), vagy egy tényleges spoofing-kísérlet, ahol valaki a te domained nevében küld. Az első esetben javítod a beállítást, a másodikban épp ez a jel az, ami miatt érdemes később p=quarantine, majd p=reject felé lépned.

A gyakorlatban ezt nem kézzel bogarászod. A dmarcian, az EasyDMARC vagy a Postmark eszköze beolvassa a riportokat, és grafikonon mutatja, mely IP-k küldenek a nevedben, és mekkora hányaduk megy át a hitelesítésen. Az ingyenes szintek egy kis webshopnak bőven elegek. A cél az, hogy a riportban 100% közeli legyen a pass-arány minden legitim forrásnál, mielőtt szigorítasz a házirenden.

IP-reputáció: amikor a 10/10 sem elég

Előfordul, hogy technikailag minden rendben van (10/10 a Mail-Testeren), a levelek mégis akadoznak. Ilyenkor szinte mindig az IP- vagy domain-reputáció a ludas. Ez egy „bizalmi pontszám”, amit a nagy szolgáltatók a küldési múltad alapján tartanak nyilván, és nem lehet egyik napról a másikra megvenni, csak felépíteni.

Néhány gyakorlati tipp a reputáció építéséhez és védelméhez. Új szervernél vagy új dedikált IP-nél melegíts be: az első hetekben fokozatosan növeld a napi levélszámot, ne zúdíts ki azonnal több ezer levelet egy nulla előéletű IP-ről. Tartsd tisztán a listát: a tranzakciós levél mindig valós vásárlóhoz megy, itt ez ritkán gond, de ha hírlevelet is küldesz ugyanarról a domainről, a döglött címek és a magas visszapattanási arány a tranzakciós leveleidet is húzzák lefelé. Kérd meg a vásárlókat, hogy vegyék fel a feladót a címjegyzékbe, mert a „nem spam” jelölés és a válaszok pozitív jelek. Végül monitorozz: a Google Postmaster Tools ingyenes, és megmutatja a domained hírnevét a Gmail szemével.

Ha ezek megvannak, és a hitelesítés is rendben, akkor a maradék probléma jellemzően már csak a tartalomban vagy egy konkrét feketelistán keresendő, amit az MXToolbox Blacklist Check funkciójával néhány másodperc alatt ellenőrizhetsz.

Lépésről lépésre: beállítás cPanel és DNS alatt

Elég az elméletből, állítsuk be. Két fő forgatókönyvet nézünk. Az egyikben a domain DNS-e a tárhelyen, cPanel alatt van, a másikban külső szolgáltató kezeli. A legtöbb kkv-webshop valamelyikbe beleesik.

1. cPanel felületen: az Email Deliverability varázsló

A cPanel az elmúlt években nagyon barátságossá tette ezt. Keresd meg az „Email Deliverability” (magyarul „Levelek kézbesíthetősége”) menüpontot, általában az „Email” szekcióban.

Itt a cPanel felsorolja a domainjeidet, és mindegyiknél jelzi, hogy az SPF, a DKIM és a PTR rendben van-e (zöld pipa) vagy sem (piros felkiáltójel). Ha problémát lát, a „Repair” (Javítás) gombbal a legtöbb esetben automatikusan beállítja a helyes SPF-et és legenerálja a DKIM-kulcsot.

1. Kattints a domain melletti „Manage” (Kezelés) gombra.
2. Ha piros a DKIM vagy az SPF: nyomd meg a „Install the Suggested Record” vagy „Repair” gombot.
3. Ha a DNS a tárhelyen van, a cPanel magától felírja a rekordokat, kész is vagy.
4. Ha a DNS külső szolgáltatónál van, a cPanel nem tud oda írni. Helyette kiírja neked a rekordokat, amiket kézzel kell átmásolnod (erről a következő pontban).

A cPanel ~all-lal (softfail) állítja be az SPF-et, ami biztonságos kezdés, a DKIM-et pedig a default szelektorral generálja.

2. Külső DNS-kezelők: Cloudflare, magyar szolgáltatók, névregisztrátor

Ha a domained DNS-ét külső szolgáltató kezeli (a Cloudflare a leggyakoribb, de sok magyar cég a névregisztrátoránál, például a DotRollnál, a Rackhostnál vagy a Tárhely.eu-nál tartja a zónát), a rekordokat oda kell felvenned. A lépések platformtól függetlenül hasonlók.

SPF felvétele (TXT):

Figyelem: egy domainre csak egy SPF-rekord lehet. Ha kettő van, az SPF PermError-ral bukik. Több szolgáltató esetén egyetlen SPF-be fűzd össze őket include-okkal.

DKIM felvétele (TXT):

Figyelem: a DKIM-kulcs hosszú, és néhány DNS-felület a 255 karakteres TXT-korlát miatt idézőjelekkel darabolja ("rész1" "rész2"). A legtöbb modern felület (Cloudflare) ezt automatikusan kezeli, csak illeszd be egyben. Ha kézzel darabolsz, ügyelj rá, hogy a részek közé ne kerüljön felesleges szóköz vagy sortörés, különben a kulcs érvénytelen lesz.

DMARC felvétele (TXT):

PTR (reverse DNS). Ez a leggyakrabban kifelejtett elem, és nem a saját DNS-zónádban állítod. A PTR az IP-cím tulajdonosának hatáskörébe tartozik, vagyis a tárhely- vagy szerverszolgáltatódnál kell kérned (VPS vagy dedikált szervernél gyakran a szolgáltató paneljén magad is beállíthatod). A PTR-nek arra a hostnévre kell mutatnia, amit a leveleződ magáról állít (pl. mail.webshop.hu), és ennek a hostnévnek vissza kell mutatnia ugyanarra az IP-re. Osztott tárhelyen ezt a szolgáltató kezeli, ott ezzel általában nincs dolgod, de érdemes ellenőrizni.

3. Tesztelés és validáció

Beállítottad? Ne hidd el, ellenőrizd. A DNS-változások terjedése néhány perctől akár órákig tarthat. A legjobb ingyenes eszközök:

• Mail-Tester.com – a legegyszerűbb. Ad egy egyedi e-mail címet, arra küldesz egy valódi tesztlevelet a rendszeredből (pl. leadsz egy próbarendelést), majd megnyomod a „Then check your score” gombot. A 10/10-es pontszám azt jelenti, hogy technikailag rendben vagy: SPF pass, DKIM pass, DMARC pass, PTR rendben, tartalom tiszta.
• MXToolbox – itt egyesével ellenőrizheted a rekordokat (SPF Record Lookup, DKIM Lookup, DMARC Lookup), és megnézheted, hogy a szerver IP-je szerepel-e valamelyik feketelistán (Blacklist Check).
• dmarcian vagy Postmark DMARC – ide állítsd be a rua riportcímet, hogy a nyers XML helyett olvasható grafikonokat kapj.
• learndmarc.com – ha vizuálisan is látni akarod, hogyan zajlik egy SPF/DKIM/DMARC-ellenőrzés lépésről lépésre.

A cél: küldj egy valódi WooCommerce visszaigazolót a Mail-Testerre, és érd el a 10/10-et. Ha 10 alatt vagy, a Mail-Tester pontosan megmondja, melyik elem hibás, és onnan visszakövetheted a hibát.

4. WooCommerce-specifikus buktató: a feladó cím és a levéltípusok

Van egy tipikus WooCommerce-hiba, ami minden más beállítás mellett is elronthatja a DMARC-igazítást: a rossz feladó (From) cím.

A WordPress adminban a WooCommerce → Beállítások → E-mailek fülön beállítasz egy „Feladó neve” és „Feladó címe” értéket. Ha ide egy olyan címet írsz, ami nem a saját domainedhez tartozik (például egy sajatnev@gmail.com vagy info@masikdomain.hu címet), akkor a levél látható feladója nem egyezik azzal a domainnel, amit az SPF/DKIM hitelesít. Az eredmény DMARC fail, hiába állítottál be mindent tökéletesen.

A szabály egyszerű: a WooCommerce feladó címe mindig a saját, hitelesített domainedről szóljon, pl. rendeles@webshop.hu. Így a From: domain egyezik az SPF/DKIM domainnel, és az igazítás rendben lesz.

Érdemes tudni, hogy a WooCommerce nem egyféle levelet küld, hanem többet, és mind ugyanezen az úton megy ki. A hitelesítés rendbetételével tehát ezek egyszerre javulnak, nincs külön teendő levéltípusonként:

Infrastruktúra-döntés: külső SMTP vagy saját Mailcow/Rspamd?

Eddig feltételeztük, hogy a saját szervereden keresztül küldesz. Van azonban egy fontos stratégiai döntés: honnan menjen ki a leveled? Három út van, és mindegyiknek megvan a helye.

Alapfeltétel: a WordPress oldali integráció

Bármelyik utat választod, a WordPresst rá kell venned, hogy hitelesített SMTP-n küldjön, ne a nyers php mail()-en. Erre két megközelítés van.

Az egyik egy megbízható SMTP-plugin, ez ajánlott a legtöbbeknek. A leggyakoribb ingyenes választás a FluentSMTP, ami natívan támogatja a legtöbb szolgáltatót (Google, Brevo, Mailgun, Amazon SES, Postmark), és nem hagy hátra fizetős falat. Alternatívák: WP Mail SMTP, Post SMTP. Ezek átveszik a wp_mail()-t, és a beállított SMTP-fiókon keresztül, hitelesítve küldenek.

A másik a kódos felülbírálás. Haladóknak: a phpmailer_init hookon keresztül közvetlenül állíthatod az SMTP-paramétereket egy mu-pluginben. Ez tisztább (nincs plugin-függőség), viszont nincs UI, nincs naplózás, és karbantartást igényel. A legtöbb kkv-nak a FluentSMTP a jobb kompromisszum.

A számok is a beállítás mellett szólnak: a Mailgun kézbesíthetőségi felmérése szerint a szolgáltatók mindössze nagyjából 13%-a végez egyáltalán inbox-placement tesztelést, vagyis a többség nem is tudja, hova jutnak a levelei (Mailgun State of Deliverability összefoglaló). Egy plugin és egy Mail-Tester teszt már az élmezőnybe emel.

1. Külső tranzakciós SMTP-szolgáltatók

Ezek dedikált cégek, akiknek egyetlen dolguk, hogy a leveleid megérkezzenek: Mailgun, Brevo (korábban Sendinblue), Postmark, Amazon SES, SendGrid.

Előnyök. Gyors a beállítás: regisztrálsz, hitelesíted a domained (felveszel pár DKIM/SPF-rekordot, amit ők adnak), és mész. Az IP-reputációjukat profik gondozzák, te a jó hírnevükön utazol. Ráadásul naplózol és látod, mi ment ki, mi bukott, mit nyitottak meg.

Hátrányok. A költség skálázódik: kis forgalomnál olcsó vagy ingyenes, több tízezer levél/hó felett viszont érezhetően drágul. Az olcsóbb csomagokban megosztott IP-ket kapsz, ahol ugyanaz a „bad neighbor” kockázat, mint a shared tárhelynél. És egy külső féltől függ a levélküldésed.

Kinek ajánlott? A legtöbb kkv-webshopnak. Ha havi néhány ezertől tízezer tranzakciós levelet küldesz, egy külső SMTP a leggyorsabb és legkevesebb karbantartást igénylő megoldás.

2. Saját levelezőszerver: Mailcow + Rspamd, dedikált IP-n

A másik véglet, amikor saját kézbe veszed a teljes levelezést. A Mailcow egy Docker-alapú, komplett levelezőszerver-csomag: tartalmazza a Postfixet (MTA), a Dovecotot (IMAP), és a spamszűréshez, valamint az aláíráshoz az Rspamd-ot. Egy dedikált, tiszta IP-vel ez egy teljes értékű, professzionális levelezőrendszer.

Az Rspamd beépített DKIM-aláírást ad (automatikusan aláírja a kimenő leveleket, kulcskezeléssel), rugalmas szabályrendszert a be- és kimenő levelek pontozásához, valamint reputáció- és statisztikai modulokat, greylistinget és tanuló Bayes-szűrőt.

Előnyök. Teljes kontroll és adatkezelés, semmi nem megy át harmadik félen, ami GDPR- és bizalmi szempontból is előny. Nincs levélenkénti díj: a fix szerverköltségen felül a mennyiség nem drágít. A dedikált IP-reputációt te építed és birtokolod.

Hátrányok. Komoly szakértelmet és karbantartást igényel: MTA-konfiguráció, IP-warmup (bemelegítés), feketelisták monitorozása, biztonsági frissítések. Egy friss IP-nek ráadásul nulla a reputációja, hetekig „be kell melegíteni” fokozatosan növekvő forgalommal, különben a nagy szolgáltatók gyanakodva fogadják.

Mikor éri meg? Ha több webshopot üzemeltetsz, nagy a levélforgalom, fontos a teljes adatkezelési kontroll, és van hozzá szerverüzemeltetési kompetenciád (vagy megfizetsz valakit, akinek van). Egyetlen kis webshopnak ez jellemzően túllövés, ott a külső SMTP a racionális választás.

Döntési segédlet

A 7 leggyakoribb hiba, és hogyan kerüld el

A gyakorlatban ugyanaz a néhány hiba bukkan fel újra és újra. Ha ezeket előre elkerülöd, a legtöbb kézbesíthetőségi probléma meg sem történik.

1. Két SPF-rekord egy domainen. Migráláskor könnyen marad egy régi SPF is. Két SPF = PermError = minden levél megbukhat SPF-en. Mindig egyetlen, egyesített SPF legyen.
2. A 10 DNS-lookup limit átlépése. Túl sok include egymásba fűzve. Ellenőrizd MXToolboxszal, az megmutatja a lookup-számot.
3. Hiányzó DKIM. Sokan beállítják az SPF-et és a DMARC-ot, de a DKIM-et kihagyják. Anélkül a DMARC csak akkor pass, ha épp az SPF igazítva passzol, továbbításnál viszont azonnal buksz.
4. Rossz WooCommerce feladó cím. Idegen domainről (pl. Gmail-cím) szóló From cím elrontja a DMARC-igazítást. Mindig a saját, hitelesített domainedről küldj.
5. Hiányzó vagy hibás PTR. Elfelejtett, mert nem a saját DNS-zónádban van. Kérdezd meg a szerverszolgáltatódat, és ellenőrizd MXToolboxszal.
6. Elhamarkodott p=reject. Riportok elemzése nélkül azonnal p=reject-re állítani olyan, mint bekötött szemmel vezetni. Először p=none, gyűjts adatot, majd fokozatosan szigoríts.
7. A php mail() megtartása. Hitelesített SMTP nélkül a WordPress a nyers php mail()-en küld, ami se DKIM-et nem ad, se megbízható Return-Path-t. Ez az egyik leggyakoribb rejtett ok.

Összefoglaló ellenőrzőlista

• ☐ SPF – pontosan egy TXT-rekord, az összes legitim küldővel, ~all záróval, 10 DNS-lookup alatt.
• ☐ DKIM – generált és DNS-be felvett publikus kulcs, default._domainkey néven. A privát kulcs a szerveren, biztonságban.
• ☐ DMARC – _dmarc TXT-rekord legalább p=none-nal és rua riportcímmel.
• ☐ PTR – a küldő IP visszamutat a hostnévre, a hostnév vissza az IP-re. A szerverszolgáltatódnál állítod.
• ☐ WordPress SMTP – FluentSMTP (vagy hasonló) beállítva, a php mail() kikapcsolva.
• ☐ Teszt – egy valódi WooCommerce visszaigazoló 10/10 a Mail-Testeren.
• ☐ Feketelista – az MXToolbox szerint a küldő IP egyetlen fontos feketelistán sincs rajta.
• ☐ Monitorozás – a DMARC-riportokat rendszeresen nézed.

Gyakori kérdések

Csak napi 20-30 levelet küldök, rám is vonatkozik ez?

A formális 5000/nap küszöb rád nem vonatkozik, de a hitelesítési logika igen: a szűrők minden levélnél nézik az SPF/DKIM/DMARC-ot. Egy hitelesítetlen kis feladó ugyanúgy spamre gyanús lehet. A beállítás mindenkinek megéri.

Beállítottam mindent, mégis spambe megy. Miért?

A hitelesítés szükséges, de nem elégséges feltétel. A tartalom (spam-szavak, törött HTML, hiányzó plain text), a küldő IP reputációja és a korábbi panaszok is számítanak. Nézd meg a Mail-Tester részletes pontozását, és ellenőrizd, nincs-e feketelistán az IP-d. Friss IP-nél az is lehet, hogy még nincs kellő reputációja.

Mi az a spam-panaszarány, és miért fontos?

Ha a címzettek a „Spam” gombbal jelölik a leveleidet, az a legerősebb negatív jel a szolgáltatónak. A Google/Yahoo követelmények szerint tartsd 0,1% alatt; a 0,3% fölötti arány büntetést (throttling, blokkolás) von maga után. Tranzakciós leveleknél ez ritkán probléma, tömeges kiküldésnél viszont kritikus.

Muszáj p=reject-re állítanom a DMARC-ot?

Nem azonnal. Kezdj p=none-nal, gyűjts riportokat, győződj meg róla, hogy minden legitim küldőd rendben átmegy, és csak utána lépj p=quarantine, majd p=reject felé. A p=reject a legerősebb spoofing-védelem, de elhamarkodva a saját leveleidet is kilőheted.

A Cloudflare-en nem tudom felvenni a hosszú DKIM-kulcsot.

A Cloudflare egyben elfogadja a hosszú TXT-értéket, automatikusan kezeli a 255 karakteres darabolást. Illeszd be a teljes v=DKIM1; k=rsa; p=... értéket egy sorban, a kulcson belül szóköz és sortörés nélkül.

Felhasznált források

• Google – Gmail biztonsági és hitelesítési követelmények: blog.google
• Yahoo Postmaster – „More secure, less spam”: blog.postmaster.yahooinc.com
• Microsoft Tech Community – Outlook új követelményei nagy feladóknak (2025. május 5.): techcommunity.microsoft.com
• Validity – 2025 Email Deliverability Benchmark Report (2024-es adatokkal): validity.com (PDF)
• GlockApps 2024 Q1 kézbesíthetőségi adatok (Uplers összefoglaló): email.uplers.com
• EasyDMARC 2026 DMARC-adoptáció és Mailgun State of Deliverability (összefoglaló): warmforge.ai
• SPF szabvány (10 DNS-lookup limit) – RFC 7208: rfc-editor.org

A statisztikai értékek a jelzett iparági jelentésekből származnak, és a mérési módszertantól függően szolgáltatónként eltérhetnek. A konkrét beállítás előtt mindig érdemes a saját domainedet a fenti eszközökkel letesztelni.