Miért mennek spambe a WordPress e-mailek – és mit tegyél?

Van az a klasszikus helyzet, amikor a WordPress rendben „elküldi” a levelet (kontakt form, WooCommerce rendelés-visszaigazolás, jelszó reset), te mégis csak annyit látsz: a felhasználó nem kapott semmit. Aztán kiderül, hogy ott van… a spam mappában. Na most jön a lényeg: a tranzakciós e-mailek (password reset, order confirmation) nem marketing levelek, mégis ugyanazokon a szűrőkön mennek át, és simán fennakadnak.

Ebben a cikkben végigmegyünk azon, hogy miért gyanús a WordPressből kiküldött levél sok szolgáltatónál, és mit érdemes beállítani, hogy stabilan inboxba érkezzen. Nem varázslat: IP reputáció, domain hitelesítés (SPF/DKIM/DMARC), SMTP, tartalmi „trigger” szavak, és a küldési volumen a kulcsszavak.

Miért jelölik spamnek a WordPressből küldött leveleket?

A spam-szűrés nem (csak) arról szól, hogy mit írsz a levélbe. A Gmail/Outlook és a többiek azt próbálják eldönteni: ki vagy, jogosult vagy-e a domain nevében küldeni, és úgy viselkedsz-e, mint egy normális küldő.

1) Szerver/IP reputáció: shared hosting = közös sors

Shared hostingnál több site osztozik ugyanazon az IP-n. Ha a „szomszéd” oldalon spamet küldenek, vagy egyszerűen rossz a küldési gyakorlat, az IP reputációja romlik – és vele együtt a te leveleid is gyanúsabbak lesznek. Ilyenkor tipikus tünet, hogy minden beállításod jónak tűnik, mégis spambe érkezik a levél.

A trükk: ellenőrizd, hogy az IP nincs-e tiltólistán. Ehhez az egyik legismertebb eszköz az MXToolbox.

2) Hiányzó domain hitelesítés (SPF, DKIM, DMARC)

Ha nincs rendben a DNS oldalon a hitelesítés, a leveleid „névtelennek” tűnnek. Három rekordot érdemes fejben tartani:

• SPF: megmondja, mely szerverek küldhetnek levelet a domain nevében.
• DKIM: kriptográfiai aláírást tesz a levelekre, így a fogadó oldal látja, hogy nem piszkálták meg útközben.
• DMARC: policy + riportolás; megmondja, mit csináljon a fogadó fél, ha SPF/DKIM nem oké.

Ha ezek hiányoznak (vagy rosszak), a Gmail/Outlook simán rányomja, hogy spam, mert nem tudja megbízhatóan összekötni a küldést a domaineddel.

3) Spoofing gyanú: a „From” nem stimmel a küldővel

Gyakori, hogy a WordPress kontakt form például info@teceged.hu feladóval küld, miközben valójában a hosting szerver (vagy a PHP mail() mögötti konfiguráció) nincs felhatalmazva erre SPF/DKIM szerint. Ezt a levelezők könnyen spoofingnak nézik: „mintha a domain nevében küldenél, de nem te vagy az”.

4) Tartalmi triggerek: nem csak a marketing levelek buknak el

A szűrők megnézik a subjectet és a body-t is. Tipikus piros zászlók: túl sok felkiáltójel, ALL CAPS, túl sok link a szöveghez képest, gyanús „sales” kifejezések, indokolatlan csatolmányok, vagy a túl generikus feladó (pl. „Admin”, „No-reply”).

5) Küldési mennyiség és hirtelen tüskék

Sok shared hosting csomagban van óránkénti limit (tipikusan 100–500 levél/óra). Ha ezt átléped, vagy hirtelen megugrik a küldés (például WooCommerce rendelés-értesítők, tömeges értesítések), az ISP-k szemében spam-szerű viselkedés. Ráadásul ha emiatt bounce-ok jönnek, az reputációt is rombol.

Hogyan állítsd meg, hogy spambe menjenek a WordPress levelek?

Itt jön a gyakorlati rész. Nem kell mindent egyszerre megcsinálni, de ha biztosra akarsz menni, a sorrend nagyjából: SMTP → DNS hitelesítés → form plugin + anti-spam → tartalom finomhangolás → volumen kontroll.

1) Küldj SMTP-n keresztül (ne a default PHP mail-lel)

A WordPress alapértelmezésben a PHP mail()-t használja, ami sok hostingnál nem „deliverability-barát”. Egy SMTP plugin lényege, hogy a leveleid egy hitelesített küldőn mennek ki, ami sokkal jobb jel a fogadó oldalon.

Az egyik kézenfekvő megoldás a MailPoet, ami tranzakciós e-mail küldéshez is ad SMTP-szerű küldési szolgáltatást. A WordPress adminban a szokásos útvonalon találod:

1. Menj a Plugins → Add Plugin menübe.
2. Keress rá: MailPoet.
3. Telepítsd, aktiváld, majd kösd össze a MailPoet accounttal.
4. A WordPressben: MailPoet → Settings → Send With, és válaszd a MailPoet Sending Service opciót.

2) Használj megbízható form plugint (és ne barkácsolt mail küldést)

Kontakt formnál sokszor a plugin dönt arról, hogyan épül fel a levél (headers, From/Reply-To), és mennyire „szabályos” a küldés. Egy stabilan karbantartott megoldás, ami jól együttműködik SMTP-vel, tipikusan jobb deliverabilityt ad.

A Jetpack Forms például natívan illeszkedik a block editorba (Form block), és jól használható SMTP mellett is.

3) Rakj anti-spam védelmet a formokra (igen, ez deliverability téma is)

Elsőre furán hangzik, de logikus: ha a formodat botok teleszórják spam üzenetekkel, az e-mail szolgáltatók azt látják, hogy a domainedről tömegével mennek „spam jellegű” levelek. Ez reputációromboló.

Jetpack Forms esetén kézenfekvő az Akismet integráció, ami a spam beküldéseket már a beérkezés előtt szűri. Ezzel nem csak a postafiókodat véded, hanem a küldői reputációd is tisztább marad.

4) DNS-ben legyen rendben az SPF/DKIM/DMARC

A domain hitelesítés nem plugin-kattintgatás, hanem DNS-munka: a domain regisztrátorodnál vagy a DNS szolgáltatódnál kell felvenni rekordokat. A pontos értékeket az adja, amin keresztül küldesz (MailPoet / SendGrid / SES / a saját mail szervered).

Ellenőrzéshez használhatsz olyan eszközöket, mint az MXToolbox, és érdemes DMARC riportolást is bekapcsolni, hogy lásd, próbál-e valaki a domaineddel visszaélni.

5) Nézd át az e-mail tartalmát (subject, linkek, feladó)

Ha a technikai rész rendben van, még mindig el lehet csúszni a tartalmon. A gyakorlatban ezek szoktak gondot okozni:

• Túl agresszív subject: sok !, ALL CAPS.
• Túl sok link a szöveghez képest (főleg rövid levelekben).
• Fura kifejezések, amik tipikusan spamben fordulnak elő (pl. „Get Rich Quick” jellegű ígéretek).
• Indokolatlan csatolmányok.
• Bizalmatlan feladó név: „Admin”, „No-reply” (inkább márkanév + valódi cím).

Ami sokat dob: legyen konkrét subject (pl. Rendelés visszaigazolás #12345), és legyen benne személyre szabott rész (név, rendelés adatok). Ettől „valódi” tranzakciós levélnek tűnik.

Ha tesztelni akarsz, jó szolgálatot tesz a Mail Tester vagy a GlockApps. Emellett érdemes több szolgáltató felé próbát küldeni (Gmail, Outlook), mert máshol máshogy szűrnek.

6) Fogd meg a volument: limit, queue, ütemezés

Ha a hosting limitjeit rendszeresen elérted, vagy kampányszerűen sok levél megy ki, akkor kell a queue/ütemezés. Sok SMTP plugin és küldő szolgáltatás tud sorba állítást, időzítést. A cél az, hogy ne legyen „hirtelen tüske”, amit a szolgáltatók spam-küldésnek néznek.

Hogyan előzd meg, hogy újra előjöjjön?

Az e-mail deliverability nem egyszeri beállítás, mert idő közben változik a hosting, a DNS, a plugin, vagy épp a levelezők szabályai. Pár rutinnal sok hibát el lehet kapni még azelőtt, hogy ügyfél panaszkodik.

Kontakt form teszt – rendszeresen

Hetente (vagy nagyobb frissítés után) küldj egy teszt üzenetet a kapcsolatfelvételi űrlapon. Ha van csatolmány, dropdown, egyedi mezők, azokat is próbáld ki. Érdemes több címre is tesztelni (Gmail + Outlook), mert eltérő lehet a szűrés.

WordPress/WooCommerce tranzakciós levelek tesztje

WooCommerce-nél a minimum: csinálj időnként egy kis teszt rendelést, és nézd meg, megjön-e a visszaigazolás, számla, shipping update. Ha tömeges értesítéseket is küldesz, figyeld a bounce-okat és a megnyitási/kattintási arányokat (amit a szolgáltatód ad). A magas bounce gyakran SPF/DKIM/DMARC vagy lista-minőség probléma.

DNS és SMTP beállítások időszakos ellenőrzése

Költözés, csomagváltás, új regisztrátor, IP csere – bármelyik boríthatja a képet. Negyedévente nézd át, hogy az SPF/DKIM/DMARC rekordok tényleg ott vannak-e, és az SMTP plugin hitelesítése (API key / app password) nem járt-e le.

WordPress core + plugin frissítések

Az elavult plugin nem csak security kockázat: ha kompromittálódik, simán elkezdhet spamet küldeni a domainedről, és onnantól hetekig-hónapokig szenvedsz a reputációval. Frissítések után érdemes rögtön futtatni egy form tesztet és egy tranzakciós e-mail tesztet is.

Gyors ellenőrzőlista (ha most épp baj van)

1. IP reputáció / blocklist check (MXToolbox).
2. SMTP bekötve? Nem a PHP mail() küld?
3. SPF/DKIM/DMARC rendben van a DNS-ben?
4. A form plugin nem spoofol? (From/Reply-To logika rendben?)
5. A levél subject/body nem triggereli a szűrőket?
6. Nincs hirtelen küldési tüske vagy limit-átlépés?