Levelek a weboldaláról és az űrlapokról

Modul 7: Hírlevelek és levelek a weboldaláról · Olvasási idő: 11 perc

Tanulási cél: E lecke után be tudja úgy állítani a weboldali levelezést (kapcsolatfelvételi űrlapok, rendelés visszaigazolások, WordPress értesítések), hogy az megérkezzen, ne okozzon DMARC-problémát, és ne lehessen visszaélni a csomagjával.

Kulcsfogalmak: PHP mail(), SMTP bejelentkezéssel, boríték szerinti küldő (envelope-sender), From és Reply-To különbsége, a látogató címe soha ne legyen From, SMTP-bővítmény, tranzakciós levél, űrlapspam, captcha, honeypot, küldési korlát, helyi kézbesítés, ha az MX máshol van

A weboldala is egy levelezőprogram

A weboldala több levelet küld, mint gondolná. Egy kapcsolatfelvételi űrlap minden beküldött üzenetet elküld Önnek. Egy webáruház rendelés visszaigazolásokat, számlákat és szállítási értesítéseket küld. A WordPress levelet küld új hozzászólásnál, frissítésnél vagy jelszó-visszaállításnál. A címzett számára ez egyszerűen a domenjéről érkező levél, és ugyanolyan szigorúan ellenőrzik, mint a postafiókjából küldött levelet: SPF, DKIM, DMARC, reputáció.

A weboldali levelek mégis gyakrabban hibáznak, mint a szokásos levelek. Ennek rendszerint három ok egyike az oka: a küldés módja, a feladó címe vagy az űrlap félrehasználása.

1. mód: PHP mail()

A weboldal számára a legegyszerűbb módja a levélküldésnek a PHP mail() függvénye. A weboldal ekkor közvetlenül a webszerver levelezőprogramjának adja át a levelet, bejelentkezés nélkül. Ez többnyire működik, de vannak hátrányai:

• A boríték szerinti küldő (Return-Path) gyakran a csomagjának rendszerfiókja lesz, például gebruiker@server.hosting.example, nem pedig az Ön saját címe. Az SPF-et ekkor a szerver domenjére ellenőrzik, tehát nem lesz összhangban az Ön From domenjével (1.7. lecke).
• Hogy kerül-e rá az Ön domenjéről származó DKIM-aláírás, a szervertől függ. Egyes szervereken igen, másokon nem.
• Semmi visszajelzést nem lát. Ha a levél nem érkezik meg, vagy visszapattanást (bounce) kap, az a rendszerfiókba kerül, amit senki nem néz.
• Nincs korlát űrlaponként. Ha visszaélnek az űrlappal, a szerver az Ön nevében küld leveleket a csomagja korlátjának eléréséig.

2. mód: SMTP bejelentkezéssel (jobb megoldás)

Állítsa be, hogy a weboldala ugyanúgy küldjön, mint a levelezőprogramja: jelentkezzen be a kimenő levelezőszerverre egy valódi postafiókkal, a 587-es (STARTTLS) vagy a 465-ös (SSL/TLS) porton, a teljes e-mail-címmel mint felhasználónévvel (1.4. és 2.1. lecke). Ekkor:

• a boríték szerinti küldő az Ön saját címe, és a levelet ugyanúgy aláírják, mint a domenjéről küldött szokásos leveleket;
• a visszapattanások egy olyan postafiókba kerülnek, amelyet el tud olvasni;
• a kiküldött levél, ha kívánja, a Küldés mappában is megjelenik;
• postafiókonként saját küldési korlátot állíthat be.

WordPressben ezt egy SMTP-bővítménnyel teheti meg. Ez a WordPress alapértelmezett levélküldő funkcióját lecseréli SMTP-n keresztüli küldésre. Ugyanazokat az adatokat kell megadnia, mint egy levelezőprogramban: szerver, port, titkosítás, felhasználónév és jelszó. Ehhez lehetőleg hozzon létre egy külön postafiókot, például website@example.com címmel. Ha a jelszó valaha kiszivárog, az Ön saját postafiókja akkor is biztonságban marad, és egy pillantással látja, melyik levél érkezik a weboldalról.

Saját PHP-alapú oldalhoz vannak könyvtárak, amelyek SMTP-n keresztül küldenek leveleket, például a PHPMailer. A jelszót egy, a weboldali mappán kívül elhelyezett konfigurációs fájlba tegye, ne egy oldal kódjába.

A WebOkénál az SMTP-adatok a DirectAdmin 8.1. kézikönyvben találhatók, a csomagjához tartozó szervernévvel; más szolgáltatóknál ezek a kézikönyvben vagy az üdvözlő levélben szerepelnek, és ugyanúgy működnek.

Sok tranzakciós levelet küld? Használjon erre szolgáló szolgáltatást

Ha naponta több száz rendelés visszaigazolást küld, megéri egy tranzakciós szolgáltatás használata: egy küldőszolgáltatás automatikus levelekhez. Ennek jó a reputációja, és megmutatja, mi történt az egyes levelekkel. A domenjét ugyanúgy kapcsolja össze, mint egy hírlevélszolgáltatásnál (DKIM CNAME-en keresztül, 7.1. lecke). Tartsa külön a tranzakciós leveleket és a hírleveleket: egy sikertelen kampány ne érintse a rendelései visszaigazoló levelét.

Az aranyszabály: a látogató címe soha ne legyen a feladó

Egy kapcsolatfelvételi űrlapnál csábító, hogy a levelet a látogató "nevében" küldje el. Így a levelezőprogramjában rögtön a Válasz gombra kattinthat. Ez így nézne ki:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Az Ön szervere azonban egyáltalán nem küldhet levelet a example.net nevében. Tegyük fel, hogy a example.net domainnek p=reject DMARC-szabályzata van. A fogadó szerver (akár az Öné, akár a Gmailé, ha a levelet átirányítja) egy olyan From example.net levelet lát, amely nem a example.net SPF-jén vagy DKIM-jén keresztül érkezett, és elutasítja. Sok nagy levelezési domainnek szigorú szabályzata van: egy 2026. november 8-i ellenőrzés során többek között a yahoo.com, aol.com, ziggo.nl és kpnmail.nl domainnek p=reject DMARC-szabályzata volt, a icloud.com, gmx.de és web.de domainnek pedig p=quarantine. Egy ilyen címmel rendelkező látogató kitölti az űrlapot, Ön pedig soha nem kapja meg az üzenetet, vagy az a levélszemét mappájába kerül. Azok a domainek, amelyeknek p=none a szabályzatuk (mint akkor a gmail.com és a hotmail.com), bármikor szigoríthatják a szabályzatukat, a Google pedig az irányelveiben kifejezetten leírja, hogy nem szabad Gmail-címeket From mezőben utánozni. Soha ne számítson tehát arra, hogy ez jól fog működni.

A helyes megoldás:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

A feladó az Ön saját címe, így az SPF, a DKIM és a DMARC is rendben lesz. A látogató címe a Reply-To mezőben szerepel. Ha a Válasz gombra kattint, a válasza Pieterhez kerül. A legtöbb űrlap-bővítményben ezt a levél beállításainál találja: a Feladó (From) mezőbe állítson be egy állandó, saját domenjéről származó címet, a Reply-To mezőbe pedig azt a mezőt, amelybe a látogató a saját címét írja be.

Az űrlapok védelme a visszaélésekkel szemben

A védelem nélküli űrlapot előbb-utóbb megtalálják a botok. Legjobb esetben Ön kap spamet. Legrosszabb esetben arra használják, hogy spamet küldjenek másoknak: ha az űrlapja egy visszaigazolást küld "a látogató által megadott címre", egy bot oda a világ bármely címét beírhatja, saját szöveggel az üzenetben. Ekkor az Ön domenje küld spamet, a reputációjára nézve minden következménnyel (5.2. lecke).

Többrétegű védelem:

• Captcha vagy egy láthatatlan ellenőrzés (mint a reCAPTCHA vagy a Turnstile) a botok nagy részét feltartja.
• Honeypot: egy rejtett mező, amelyet az emberek nem látnak, a botok viszont kitöltenek. Ha kitöltik, az üzenetet nem küldi el a rendszer.
• Ne legyen szabad szöveg a látogatónak küldött visszaigazolásban, vagy egyáltalán ne legyen visszaigazolás a megadott címre. Egy egyszerű, az oldalon megjelenő "Köszönjük, megkaptuk az üzenetét" üzenet elegendő.
• Postafiókonkénti küldési korlát a weboldali postafiókhoz, alacsonyabban, mint a csomagjáé.
• A szoftver frissítése. A régi bővítmények ismert belépési pontot jelentenek a visszaélésekhez.

Azt veszi észre, hogy a csomagja hirtelen sok levelet küld, vagy értesítést kap arról, hogy elérte a napi korlátot, miközben Ön maga keveset levelez? Akkor azonnal módosítsa a jelszavakat, és nézze meg, melyik űrlap vagy szkript küldi a leveleket (3.4. lecke).

A levelezés máshol van, a weboldal itt

Gyakori buktató: a weboldala az egyik szolgáltatónál van, a levelezése egy másiknál (például a Microsoft 365 vagy a Google Workspace szolgáltatásban). Az MX rekordja arra a másik szolgáltatóra mutat. A webszerver azonban még mindig azt hiszi, hogy ő kezeli a domenje levelezését, mert a domain a saját csomagján is szerepel. Az űrlapról a info@example.com címre küldött levelet ekkor helyben kézbesíti, egy olyan postafiókba a webszerveren, amelyet senki nem néz, vagy olyan hibát ad, mint a 550 ... mailbox unavailable.

A megoldás az, hogy a webszerver vezérlőpultján jelzi, hogy a levelezést máshol kezelik. A WebOké DirectAdmin felületén ez az MX Records résznél a "Használja ezt a szervert az e-mailjeim kezelésére" jelölőnégyzet (kikapcsolva). Más vezérlőpultokon hasonló beállítás található, például a cPanelben az "e-mail routing: külső". Még jobb megoldás: a weboldal SMTP-n keresztül küldjön, annak a szolgáltatónak a postafiókjával, ahol a levelezése valójában van.

Összefoglalás

• A weboldali levelezést ugyanolyan szigorúan ellenőrzik, mint a szokásos levelezést. Küldje a weboldal leveleit SMTP-n keresztül, bejelentkezéssel, ne a mail() függvénnyel.
• Használjon külön postafiókot a weboldalhoz, saját küldési korláttal.
• A látogató címének a Reply-To mezőben van a helye, soha nem a From mezőben. Egyébként a DMARC megbukik, és a p=reject szabályzatú domainek (mint a yahoo.com, ziggo.nl, kpnmail.nl) esetén a levelet elutasítják.
• Védje az űrlapokat captchával, honeypottal, és ne küldjön szabad szöveges visszaigazolást a megadott címekre.
• Ha a levelezése egy másik szolgáltatónál van, kapcsolja ki a helyi kézbesítést a webszerveren, vagy küldjön SMTP-n keresztül azon a szolgáltatón.

Kvíz

Feladat

O7.3 feladat: A weboldali levelezés ellenőrzése. Töltsön ki egy űrlapot a saját weboldalán egy Gmail- vagy Outlook.com-cím feladóként való megadásával, és nézze meg az Önhöz beérkező üzenet fejléceit. Válaszolja meg az ellenőrzőlistát: melyik cím szerepel a From mezőben, a látogató címe a Reply-To mezőben van-e, mit mutat az spf=, dkim= és dmarc= érték az Authentication-Results fejlécben, a weboldala SMTP-n keresztül vagy a mail() függvénnyel küld-e, és van-e az űrlapon captcha vagy honeypot? Ha nincs saját weboldala, válaszolja meg a kérdéseket a leckében szereplő példa alapján. Ezután megkapja a mintaválaszt.

További olvasmányok

Az ezekben a cikkekben szereplő lépések a WebOké vezérlőpultjaira vonatkoznak; más szolgáltatóknál hasonlóan működik.

• Kapcsolatfelvételi űrlap a weboldalon: a mezők e-mailben történő elküldése és a spam megelőzése
• Hogyan állíthatom be a helyes feladót PHP-ben a mail() függvénnyel? SMTP
• PHP-ből nem sikerül levelet küldeni, az MX-rekordok máshová mutatnak
• Levélküldési korlát
• Elérte a napi e-mail-korlátot
• DirectAdmin útmutató 8.1: Minden beállítás egy helyen: szerverek, portok és biztonság
• DirectAdmin útmutató 5.10: E-mail Microsoft 365 vagy Google Workspace szolgáltatásnál, weboldal a WebOkénál