A kapcsolatfelvételi űrlap e-mailei spambe kerülnek — A webszerver-küldő javítása (2026)

Közzétéve 2026-07-08

Adatok: 2026-06-29 · módszertan v7. Összesített adatok 261 millió értékelt domain felmérése alapján. Lásd: hogyan értékeltük az internetet.

A kapcsolatfelvételi és webhelyi e-mailek azért kerülnek spambe, mert a webszerver hitelesítés nélkül küldi őket — nincs SPF-engedélyezés, nincs DKIM-aláírás. A megbízható megoldás az, hogy ezt a levelezést hitelesített SMTP-n keresztül irányítja, nem a szerver fehérlistázásával. A Defaults.Exposed felmérésben értékelt 261,086,232 domain 46.4%-a (adatok: 2026-06-29) egyáltalán nem rendelkezik SPF-rekorddal.

A javítás sorrendje fontos, és a legtöbb útmutató fordítva csinálja. Futtasson ingyenes vizsgálatot, hogy megtudja, a doménje valójában milyen rekordokat tesz közzé; irányítsa a webhely levelezését hitelesített SMTP-n keresztül (levelezési szolgáltatóján vagy egy tranzakciós e-mail-szolgáltatáson át), hogy valódi DKIM-aláírást kapjon; javítsa az űrlap From-mezőjét; és csak végső esetként adja hozzá a szerver IP-jét az SPF-hez.

Miért kerülnek spambe a webhelyemről érkező e-mailek?

Azért, mert valójában ki küldi őket. Amikor egy látogató kitölti a kapcsolatfelvételi űrlapot, az e-mailt nem a levelezési szolgáltatója küldi — a webszerver maga állítja elő, általában a PHP mail() függvényén keresztül. A fogadó fél szemszögéből az üzenet:

olyan IP-ről érkezik, amelyet az SPF-rekordja nem engedélyez (az SPF a levelezési szolgáltatóját fedi le, nem a webtárhelyét);
nincs DKIM-aláírása, tehát semmi sem köti kriptográfiailag a doménjéhez;
gyakran egy megosztott tárhely IP-jéről indul, amelynek hírnevét több száz idegen webhely alakítja.

A hitelesítetlen levél vegyes hírnevű IP-ről pontosan az, amit a spamszűrők kiszűrnek — a Gmail és az Outlook egy véletlenszerű szervert lát, amely azt állítja, hogy Ön az. A tágabb kép lehangoló: a domének 46.4%-ának egyáltalán nincs SPF-rekordja, és csak 10.59% (27,640,987 a felmérés 261,086,232 értékelt doménjéből, adatok: 2026-06-29) érvényesít DMARC-házirendet.

Miért érinti ez különösen a WordPress-webhelyeket?

A WordPress az összes levelét — az űrlap-értesítőket, jelszó-visszaállításokat, rendelés-visszaigazolásokat — egyetlen függvényen, a wp_mail()-en keresztül küldi, amely alapértelmezés szerint a webszerver PHP mail() függvényét hívja. Minden olyan WordPress-webhely, amelyet nem konfiguráltak át szándékosan, eleve hitelesítetlen küldőként működik. Az űrlapbővítmények (Contact Form 7, WPForms, Gravity Forms) mind ugyanehhez a függvényhez adják a leveleket: úgy tűnik, mint egy bővítményprobléma, de valójában egy szállítási probléma.

A megoldás nem egy másik űrlapbővítmény, hanem egy SMTP-plugin (WP Mail SMTP és hasonlók), amely mindent, amit a wp_mail() küld, egy valódi, hitelesített e-mail-fiókon keresztül irányít — olyan infrastruktúrán, amelyet az SPF-rekordja már engedélyez, és amelyhez DKIM-aláírás is tartozik.

Milyen küldési módszert használjon a webhely?

Küldési módszer	SPF	DKIM	Megmarad a tárhelyváltás után?	Értékelés
PHP `mail()` / alapértelmezett `wp_mail()` a webszerverről	megbukik	nincs	nem értelmezhető — mindenhol meghibásodik	ez a probléma, nem megoldás
Hitelesített SMTP a levelezési szolgáltatón keresztül (Google Workspace, Microsoft 365 stb.)	átmegy	aláírt	igen — független a tárhelytől	a legtöbb webhely esetén ez a megoldás
Tranzakciós e-mail-szolgáltatás (SES, Postmark, Brevo stb.) ellenőrzött domén mellett	átmegy	aláírt	igen	a megoldás nagyobb forgalomnál (e-kereskedelem, sok űrlap)
A webszerver IP-je hozzáadva az SPF-rekordhoz	átmegy (csak SPF)	nincs	nem — csendesen meghibásodik, ha az IP változik	csak végső esetként — lásd alább

Napi néhány értesítésnél az SMTP a már fizetett levelezésen keresztül a leggyorsabb út; valódi forgalomnál a tranzakciós szolgáltatás erre van tervezve. Mindkettő DKIM-et ad — az IP-fehérlistázó rövidút soha.

Hogyan javíthatom a kapcsolatfelvételi e-mailek kézbesíthetőségét?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt bármit megváltoztatna. Megmutatja, hogy az SPF, DKIM és DMARC milyen rekordokat tesz közzé — függetlenül attól, hogy az űrlap szállítását, egy hiányzó rekordot vagy mindkettőt javítja. Egyáltalán nincs SPF? Kezdje az SPF javításával.
Hozzon létre egy dedikált SMTP-identitást a webhelyhez — pl. [email protected] a levelezési szolgáltatójánál, vagy egy ellenőrzött küldési domént egy tranzakciós szolgáltatásban. Használjon visszavonható alkalmazásjelszót vagy API-kulcsot, ne egy személy postafiókjának jelszavát.
Irányítsa a webhely levelezését ezen keresztül. WordPress esetén telepítsen SMTP-plugint, és irányítsa arra a fiókra. Más platformokon a keretrendszer levelezőjét konfigurálja a helyi mail() helyett.
Javítsa a From-mezőt (lásd az anti-mintát alább): a From-nek a saját doménjét kell tartalmaznia; a látogató e-mail-címe a Reply-To-ba kerül.
Ha tranzakciós szolgáltatás küld az Ön nevében, adja hozzá annak DKIM-rekordjait (általában CNAME-páros), hogy a levelek a doménjével legyenek aláírva — a DNS-lépések tükrözik az SPF-beállítási útmutatókat.
Küldjön egy teszt-beküldést, és futtassa újra a vizsgálatot. A fejlécekben spf=pass és dkim=pass értéket kell látnia a saját doménjéhez; ezután javítsa a vizsgálat által jelzett egyéb hibákat az SPF javítása és a DKIM javítása útmutatók alapján.

Miért a látogató e-mail-címéről küldi az űrlap az értesítőt?

Ez az egyik leggyakoribb önhibás konfigurációs hiba, és sok bővítmény régebben alapértelmezetten így működött: az értesítő a látogató e-mail-címéről érkezik, hogy egyszerűen válaszolhasson. Praktikusnak tűnik, de hamisítás. A szervere nem jogosult [email protected] nevében levelet küldeni — ez megbuktatja a gmail.com SPF- és DKIM-ellenőrzését, a Gmail DMARC-házirendje pedig arra utasítja a fogadókat, hogy lomtáraztassák vagy utasítsák vissza. A javítás ingyenes:

From: a saját doménjéhez tartozó cím (a 2. lépésből az SMTP-identitás)
Reply-To: a látogató e-mail-címe — a válasz közvetlenül hozzá kerül

Minden elterjedt űrlapbővítmény támogatja ezt; az értesítési beállításokban két mező.

Miért ne adjam hozzá a szerver IP-jét az SPF-rekordhoz?

A legtöbb fórumtéma ez után nyúl először, és nem ok nélkül ez a végső mentsvár. Az ip4:<szerver> (vagy az a mechanizmus a webtárhelyhez) hozzáadása az SPF-hez valóban átengedi a nyers ellenőrzést — de:

Megosztott tárhelyen idegeneket is engedélyez. Az IP-cím a kiszolgálóé, nem az Öné; ugyanazon a szerveren lévő összes többi webhely mostantól SPF-átengedéssel tud leveleket küldeni a doménjéről.
Csendesen meghibásodik. A tárhelyszolgáltatók szervermigráció és IP-rotáció esetén nem értesítik; az SPF-rekordja továbbra is engedélyez egy olyan IP-t, amelyet hónapokkal ezelőtt elhagyott.
Nem ad DKIM-et. Az SPF önmagában meghibásodik továbbítás esetén, és nem viszi Önt a DMARC-érvényesítés felé úgy, ahogy egy aláírás tudna.

Tartsa fenn ezt a megoldást az igazán korlátozott esetekre: egy statikus, Ön által irányított IP-jű dedikált szerver, amelyen futó alkalmazás nem tud SMTP-n kommunikálni — és ha lehetséges, párosítsa DKIM-aláírással a szerveren.

Az SPF az űrlap „From” mezőjében lévő e-mail-címet ellenőrzi?

Nem — és ez megzavarja az öndiagnózisok felét. A fogadók az SPF-et a Return-Path (RFC5321.MailFrom) domén alapján értékelik, nem a From fejléce alapján. A webszerverek często a saját gépnevüket írják a Return-Path-be, tehát az SPF-rekordját soha nem kérdezték le — a fogadó az srv0421.examplehost.com SPF-jét ellenőrizte. A hitelesített SMTP ezt is javítja: a Return-Path a doménjévé válik, így az SPF-átmenés végre az Önéért számít. Ez az oka annak is, hogy a DKIM miért fontos — a DMARC-igazításhoz szükség van a From-ban lévő doménhez kötött átmenésre, és a DKIM-aláírás az üzenettel együtt utazik.

Gyakran ismételt kérdések

Az SMTP-plugin a jelszó-visszaállítást és a WooCommerce-e-maileket is javítja? Igen. WordPress esetén minden a wp_mail()-en folyik át, így átirányítása egyszerre javítja az értesítőket, a jelszó-visszaállításokat és a rendelési e-maileket.

Szükségem van-e SPF- és DKIM-rekordra, ha SMTP-plugint használok? Igen — a plugin csak azt változtatja meg, melyik infrastruktúra küldi a leveleit; a rekordok engedélyezik azt. Ha a doménje azon 46.4% közé tartozik (a felmérés 261,086,232 értékelt doménjéből, adatok: 2026-06-29), amelynek nincs SPF-rekordja, a hitelesített SMTP önmagában nem ment meg. Az új domain e-mail-ellenőrzőlistája a teljes rekordkészletet lefedi.

Az e-maileim átmennek az SPF-en, de megbuknak a DMARC-on — miért? Szinte mindig a fent leírt From-hamisítási anti-minta, vagy az SPF a tárhelygazda Return-Path-domén miatt megy át, nem a sajátjáért. Először javítsa a From/Reply-To beállításokat; ha így is megbukik, a hiányzó elem egy igazított DKIM-aláírás — lásd: „DKIM signature not valid”. Ha SaaS-eszközök is megbuknak a webhelyen túl, az SPF-et SaaS-hoz javító útmutató ismerteti a javítás sorrendjét.

Megéri mindez egy kevés forgalmú kapcsolatfelvételi űrlaphoz? Az űrlap általában az, ahol a pénz beérkezik — egy kihagyott megkeresés egy ügyfél, akiről soha nem tudott. A javítás ingyenes; az akadály csupán annak felismerése, hogy a webszerver volt a hitelesítetlen küldő.

Küldje el a riportot a tulajdonosnak

Ha Ön a javítást végző fejlesztő vagy kivitelező: miután a tesztes beküldés átment, futtassa újra az ingyenes vizsgálatot, és továbbítsa az értékelt riportot a webhely tulajdonosának — ez egy dátummal ellátott, közérthető igazolás arról, hogy a domain megfelelően hitelesít, és az a dokumentum, amelyre a következő kiberbiztosítás-megújításkor vagy ügyfél-biztonsági kérdőívnél szükség lesz. Ha Ön a tulajdonos, aki azért olvassa ezt, mert a megkeresések eltűntek: küldje ezt az oldalt és a vizsgálati riportját annak, aki a webhelyét kezeli — egy délutánnyi munka egy előtte-utána eredménnyel, amelyet meg tud mutatni Önnek.

Ellenőrizze a doménjét → · SPF megbukik a SaaS-eszközöknél? → · SPF javítása → · Hogyan értékeltük → · Csak összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.