SMTP portok 2026-ban: melyiket válaszd, hogy a WordPress leveleid tényleg megérkezzenek?

Weboldalt üzemeltetsz, és jogosan várod el, hogy az e-mailek egyszerűen működjenek: beérkezzenek a kapcsolatfelvételi űrlapok üzenetei, a vásárlók megkapják a rendelés-visszaigazolást, a felhasználók pedig a jelszó-visszaállító levelet. Amikor ez nem történik meg, az nem puszta kényelmetlenség: bizalmi probléma, ami leadekben, ügyfelekben és hitelességben mérhető.

A háttérben a „csendes tettes” tipikusan az, hogy a weboldal az alapértelmezett levélküldési beállításokra támaszkodik. Sok site – különösen WordPress-en – nincs úgy konfigurálva, hogy a mai Gmail/Outlook szintű szűrők szemében megbízhatóan és hitelesen küldjön. A modern megoldás az, hogy a weboldal levelezését professzionális, autentikált csatornára tereled: ez az SMTP (Simple Mail Transfer Protocol). Csakhogy a beállításnál van egy trükkös, de kulcsfontosságú kérdés: melyik SMTP portot érdemes használnod 2026-ban?

Gyors összefoglaló (Key takeaways)

• A gyors válasz: 587-es port + STARTTLS titkosítás. Ez a modern, biztonságos és általánosan ajánlott standard weboldalas (submission) levélküldéshez.
• Jó alternatíva: 465-ös port + SMTPS (implicit SSL/TLS). Sok szolgáltatónál ugyanúgy bevett és biztonságos; ha az 587 nem megy, ez a következő legjobb opció.
• Kerülendő: 25-ös portot ne használj email submissionre (tehát amikor a site küld). Titkosítatlan, alapvetően szerver–szerver relére készült, és a legtöbb ISP/hosting kimenő irányban blokkolja spam-megelőzés miatt.
• A valódi probléma (miért tűnnek el levelek): a WordPress alapértelmezett e-mail küldése (pl. wp_mail()) nem autentikált és a web szerverről megy, ami levelezési reputáció nélkül gyanús a spam szűrőknek.
• A valódi megoldás (hogyan lesz stabil): használj dedikált tranzakciós SMTP szolgáltatót (pl. SendGrid, Brevo, Mailgun), és azon keresztül küldd a weboldal leveleit.
• „Easy button” WordPress-hez: ha nem akarsz portokkal, DNS-sel, API key-ekkel foglalkozni, léteznek nulla-konfigos bővítmények is, például a Site Mailer by Elementor, ami a tranzakciós leveleket automatikusan nagy kézbesíthetőségű szolgáltatáson küldi át.
• Tranzakciós vs marketing: az SMTP-s megoldás a tranzakciós e-mailekre való (űrlap, jelszó reset, nyugta). Hírlevélhez/tömeges küldéshez külön e-mail marketing platformot (ESP) használj, hogy ne égesd le a küldői reputációdat.

Mi az SMTP, és miért számít ez egy weboldalnál?

Képzeld el az SMTP-t (Simple Mail Transfer Protocol) úgy, mint az internet hivatalos digitális postahivatalát: egy szabálykönyv, amit minden levelezőkliens (Outlook, Apple Mail) és levelezőszerver használ az üzenetek továbbítására.

Amikor elküldesz egy levelet, valójában nem közvetlenül a címzettnek „dobod át”:

1. A leveled először az kimenő levelezőszerveredhez megy (pl. smtp.gmail.com). Ez a submission lépés.
2. A kimenő szerver megkeresi a címzett levelezőszerverét, és továbbítja neki az üzenetet (relay).
3. A címzett szervere eltárolja a levelet, amíg a felhasználó meg nem nyitja a postaládáját.

Az SMTP az 1) submission és 2) relay lépésekhez tartozó protokoll. Az „SMTP port” pedig egyszerűen a szerver kijelölt, számozott „ajtaja”, amin ez a kommunikáció történik.

A WordPress wp_mail() gondja (és miért tűnik spamnek)

Alapból a WordPress nem SMTP-n keresztül küld. A beépített wp_mail() funkcióval próbál levelet küldeni a web szerverről. Ez kézbesíthetőség szempontból több okból is rossz kombó:

1. Nem levelezőszerver: a web szerver weboldalak kiszolgálására van hangolva, nem e-mail küldésre; hiányoznak a levelezéshez tipikusan szükséges, finomhangolt beállítások.
2. Nincs autentikáció: a szerver sok esetben csak „állítja”, hogy a-te-domain.hu nevében küld, de nem tudja ezt korrektül igazolni a fogadó oldalon.
3. Nincs reputáció: a Gmail/Microsoft és más szolgáltatók reputációt vezetnek ismert küldő szerverekhez. A web szervered levelezési reputációja gyakorlatilag nulla, így „ismeretlen küldőként” gyanús.
4. Megosztott tárhelyes IP-kockázat: shared hostingnál ugyanazon a szerveren százak lehetnek. Ha közülük valaki spammel, az egész szerver IP-je feketelistára kerülhet, és a te legitim leveleid is elvéreznek.

A végeredmény: a fogadó szolgáltatók ezt a nem autentikált, reputáció nélküli forrást könnyen spamnek nézik, spam mappába teszik, vagy akár csendben el is dobják. A stabil megoldás az, hogy a WordPress e-mailjeit ráállítod egy profi, autentikált tranzakciós küldőre (SMTP szolgáltatóra), amihez portot is választanod kell.

SMTP portok rövid története: miért lett több, és miért avult el a legtöbb?

A portok története lényegében az internet és a spam közti folyamatos fegyverkezési verseny lenyomata. Ha érted, miért léteznek, sokkal könnyebb jó döntést hozni 2026-ban.

25-ös port: az eredeti „spam autópálya”

A kezdetekben (1982-ben) gyakorlatilag csak a 25-ös port volt. Ezt a portot a levelezőszerverek közötti továbbításra találták ki (Mail Transfer Agent, azaz MTA relé). Nyitott volt, egyszerű, autentikáció nélkül: bármelyik szerver tudott csatlakozni a másikhoz, és átadni egy levelet.

A gond hamar jött: a spammerek rájöttek, hogy port 25-ön bárkinek be lehet tolni tömegesen kéretlen leveleket, és a szerver majd kézbesíti helyettük. Titkosítatlan, autentikálatlan, könnyen abuzálható csatorna lett.

Mai helyzet: emiatt a legtöbb ISP, felhős szolgáltató és lakossági hálózat kimenő irányban blokkolja a 25-ös portot. A cél, hogy a fertőzött gépekről és kompromittált szerverekről ne lehessen spammelni.

465-ös port: az első „biztonságos” megoldás (SMTPS)

A ’90-es évek végére egyértelmű lett, hogy a levelezéshez titkosítás kell. Így jött a 465-ös port, ami az SMTPS-t (SMTP over SSL) használta. Itt a kliens/szoftver a csatlakozás pillanatában azonnal elindítja az SSL (ma inkább TLS) kézfogást, és a teljes kommunikáció egy titkosított alagútban fut. Ezt hívják implicit SSL/TLS-nek.

Technikailag sokáig az volt a csavar, hogy a 465 egy időszakban nem számított hivatalos IETF standardnak, sőt volt olyan időszak, amikor „deprecated” státuszt kapott a STARTTLS javára.

Mai helyzet: a 465 hatalmasat jött vissza, elfogadott és nagyon népszerű biztonságos megoldás. Több nagy szolgáltató (például a Gmail) is ajánlja. Weboldalakhoz is teljesen vállalható és biztonságos választás.

587-es port: a modern standard (STARTTLS)

A standardizálási vitákat lezárandó az IETF a 587-es portot jelölte ki hivatalosan e-mail submission célra (amikor a kliens vagy a weboldalad elküldi a levelet a kimenő szervernek). Ez jellemzően STARTTLS-t használ, amit gyakran explicit TLS-nek is hívnak.

A STARTTLS működése röviden:

1. A weboldalad csatlakozik az SMTP szerverhez 587-en, kezdetben sima (plain text) kapcsolaton.
2. Küld egy EHLO parancsot (köszönés / képességek lekérdezése).
3. A szerver visszaadja, milyen funkciókat támogat, köztük a STARTTLS-t.
4. A kliens elküldi a STARTTLS parancsot, amivel „felupgrade-eli” a kapcsolatot titkosítottra.
5. Felépül a TLS alagút, és csak ezután megy az autentikáció és maga a levélküldés.

2026-ban bármely szerver, ami 587-en nem kényszeríti ki a titkosítást, gyakorlatilag nem tekinthető biztonságosnak. A lényeg viszont: 587 a leginkább ajánlott, legelterjedtebb submission port, és szinte minden SMTP szolgáltató támogatja.

2525-ös port: nem standard, de hasznos menekülőút

A 2525 nem hivatalos SMTP port, inkább egy elterjedt „alternatív” port, amit több SMTP szolgáltató és hosting is felkínál tartaléknak.

Mikor van rá szükség? Akkor, ha a tárhelyszolgáltatód blokkolja az 587-et és a 465-öt is. Ez ritkább, de előfordulhat, például egyes felhős környezetekben, ahol a szolgáltató a spam kockázat miatt szigorít. A 2525 tipikusan ugyanúgy STARTTLS-szel megy, mint az 587.

2026-os verdikt: melyik SMTP portot válaszd?

Első választás: 587 (STARTTLS)

Ha WordPress-ből (vagy bármilyen webalkalmazásból) akarsz megbízhatóan levelet küldeni, 587 + STARTTLS legyen az alapbeállítás. Ez a submissionra kijelölt modern standard, széles körben támogatott, és erre optimalizálnak a szolgáltatók.

Második választás: 465 (SMTPS)

Ha az 587 valamiért nem működik, vagy a szolgáltatód kifejezetten ezt preferálja (például Gmail/Google Workspace esetén gyakori), akkor 465 + SMTPS tökéletesen jó, biztonságos alternatíva. Itt a titkosítás „implicit”, tehát azonnal a TLS alagútban indulsz.

Majdnem soha: 25

Weboldalról történő küldéshez ne. A 25 modern környezetben jellemzően blokkolt, és alapvetően nem erre a felhasználási esetre való.

SMTP port gyors összehasonlítás

• 25 – Protokoll: SMTP; Biztonság: nincs; Használat: szerver–szerver relay; Weboldalhoz: nem (hostingok blokkolják)
• 465 – Protokoll: SMTPS; Biztonság: implicit SSL/TLS; Használat: kliens/weboldal → szerver submission; Weboldalhoz: igen (biztonságos és gyakori)
• 587 – Protokoll: SMTP; Biztonság: explicit (STARTTLS); Használat: kliens/weboldal → szerver submission; Weboldalhoz: igen (ajánlott standard)
• 2525 – Protokoll: SMTP; Biztonság: explicit (STARTTLS); Használat: tartalék submission; Weboldalhoz: csak ha 587/465 blokkolva van

WordPress e-mail kézbesíthetőség javítása: lépésről lépésre

Ha már tudod, melyik port a jó, jöhet a gyakorlati rész: hogyan állítsd át a WordPress-t, hogy ne a wp_mail() „szerverről kikiáltok a világba” módszerével küldjön, hanem egy hitelesített tranzakciós csatornán.

1. lépés: válassz dedikált tranzakciós SMTP szolgáltatót

Az első és legfontosabb: állj le azzal, hogy a web szerver küldje az e-mailt. Regisztrálj egy tranzakciós e-mail szolgáltatóhoz, akiknek a teljes üzlete a kézbesíthetőség köré épül.

Mit adnak? Magas reputációjú levelezőszervert, amin keresztül SMTP-vel vagy API-val tudsz küldeni.

Gyakori opciók a piacon:

• SendGrid (nagyon elterjedt, erős ingyenes csomaggal)
• Brevo (korábban Sendinblue)
• Mailgun
• Postmark (kifejezetten magas kézbesíthetőségről ismert)
• Amazon SES (erős, de összetettebb)
• Google Workspace / Gmail (alacsony volumenű site-oknál működhet, de üzletileg nem ideális a küldési limitek miatt)

A kisebb-közepes üzleti oldalak tranzakciós forgalmára a free tier-ek sokszor bőven elegendők.

2. lépés: DNS rekordok beállítása (SPF és DKIM)

Ez a legkritikusabb technikai pont. Miután megvan a szolgáltató, bizonyítanod kell a világnak, hogy engedélyt adtál neki a domain nevében történő küldésre. Ezt DNS rekordokkal teszed meg ott, ahol a domain DNS-e lakik (domain regisztrátor vagy külön DNS szolgáltató). A szolgáltató pontosan megadja, mit kell bemásolni.

A két alapfogalom:

• SPF (Sender Policy Framework): TXT rekord, ami olyan, mint a domain „vendéglistája”. A fogadó szervereknek azt mondja: csak akkor fogadj el a-te-domain.hu feladótól levelet, ha az az engedélyezett IP-kről/szolgáltatóktól jön. Segít a feladó cím hamisítása (spoofing) ellen.
• DKIM (DomainKeys Identified Mail): TXT rekord, ami egyfajta „digitális viaszpecsét”. A szolgáltató privát kulccsal aláírja a leveleket, a fogadó szerver pedig a DNS-ben lévő publikus kulccsal ellenőrzi, hogy az aláírás érvényes, és a levél nem lett módosítva.

3. lépés: SMTP bővítmény telepítése és konfigurálása WordPress-ben

Most rá kell venned a WordPress-t, hogy a kiválasztott szolgáltatót használja. Erre a legegyszerűbb egy SMTP bővítmény, ami „elkapja” a wp_mail() hívásokat, és átirányítja a küldést.

Gyakori bővítmények:

• WP Mail SMTP
• FluentSMTP
• Post SMTP

Általános beállítási lépések (a legtöbb bővítménynél hasonló):

1. Telepítsd és aktiváld a választott SMTP bővítményt.
2. A WordPress adminban nyisd meg a bővítmény beállításait.
3. Válaszd ki a Mailer típust (pl. „SendGrid”), ha van dedikált integráció.
4. Add meg a hitelesítést (credential). Két tipikus út van: – Ajánlott (API): sok bővítmény API key használatát javasolja. Biztonságosabb és megbízhatóbb. – SMTP (kézi adatok): ha „Other SMTP” módban vagy, kézzel kell mindent megadni.
5. Ha SMTP kézi módot használsz, állítsd be az SMTP paramétereket: – SMTP Host: a szolgáltató szerver címe (pl. smtp.sendgrid.net). – Encryption: válaszd a TLS-t (ez jellemzően STARTTLS-t jelent). Ha ilyen nincs, előfordulhat SMTPS/SSL opció. – SMTP Port: 587 (TLS/STARTTLS mellé) vagy 465 (SMTPS/SSL mellé). – Authentication: legyen ON. – SMTP Username: a szolgáltató adja. – SMTP Password: a szolgáltató adja.
6. Állítsd be a feladót: – From Email: az autentikált domainből legyen. – From Name: a weboldal vagy a márka neve.

4. lépés: tesztküldés és naplózás ellenőrzése

A normális SMTP bővítményekben van „Test Email” funkció. Küldj próba levelet a saját Gmail/Outlook címedre.

• Ha a beérkező levelek a bejövőben landolnak: jó vagy, a weboldal hitelesen küld.
• Ha spambe megy: ellenőrizd az SPF/DKIM rekordokat. A DNS terjedése (propagation) órákat is igénybe vehet.
• Ha el sem megy: tipikusan port vagy credential hiba. Ellenőrizd a host/port/username/password értékeket. Próbáld meg a 465-öt, ha az 587 nem megy (vagy fordítva).

„Egyszerű gomb”: amikor a platform oldja meg helyetted

A fenti négy lépés fejlesztőként vállalható, de üzleti oldalaknál gyakran a tulajdonosnak túl sok: domain DNS, külön SMTP szolgáltató, WordPress bővítmény, portok, kulcsok. Emiatt terjednek az integrált megoldások.

1) Integrált tranzakciós e-mail, nulla konfigurációval

A WordPress e-mail problémájának gyökere az autentikáció hiánya. Ha ezt úgy tudod megkerülni, hogy nem kell kézzel szolgáltatót választani, API key-t beállítani, SPF/DKIM-mel bíbelődni és portot dönteni, az rengeteg hibalehetőséget kivesz a képletből.

Erre példa a Site Mailer by Elementor, amit kifejezetten „zero-configuration” (nulla-konfigos) bővítményként pozicionálnak:

• Telepíted és aktiválod, és kész.
• Automatikusan átirányítja a weboldal tranzakciós leveleit (kapcsolatfelvételi űrlapok, WooCommerce értesítők, jelszó reset, stb.) egy magas kézbesíthetőségű, autentikált e-mail szolgáltatáson keresztül.
• Nem kell külön SendGrid-fiók, nem kell API key, nem kell SPF/DKIM beállítás, és portot sem kell választanod – elvileg dobozból működik.

2) Menedzselt hosting, ami nem akadályoz a best practice-ben

A másik klasszikus buktató a tárhely környezet: ha a hosting túl szigorúan blokkol portokat, akkor hiába mindent jól állítasz be. A menedzselt WordPress hostingok tipikusan tisztában vannak a wp_mail() problémával, és igyekeznek olyan alapot adni, ahol az SMTP integráció nem harc.

A forrásban említett példa az Elementor Hosting, amit felhős infrastruktúrára épített, teljesítményre optimalizált környezetként írnak le, és ennek részeként az olyan portok elérhetősége is fontos, mint az 587, hogy SMTP bővítménnyel tudj best practice szerint küldeni.

SMTP-n túl: a legfontosabb különbség (tranzakciós vs marketing e-mail)

Ha már rendben a weboldal levelezése, jön a szabály, amit sokan elrontanak: ne küldj hírlevelet a tranzakciós SMTP csatornán.

A tranzakciós SMTP (vagy egy weboldalas mailer szolgáltatás) célja a kritikus, egyedi levelek kézbesítése:

• Tranzakciós e-mail (SMTP-vel küldd): egy felhasználói esemény által kiváltott 1:1 üzenetek. Példák: jelszó-visszaállítás, rendelés-visszaigazolás, űrlap-visszajelzés, üdvözlő e-mail. Ezeknek elvártan a bejövőbe kell érkezniük.
• Marketing e-mail (ESP-vel küldd): 1:many tömeges küldés. Példák: heti hírlevél, akciók, termékbejelentések. Ezeknél több leiratkozás és spam-jelentés várható, ami reputációt ront.

Ha a 10 000 fős hírleveledet ugyanarról a tranzakciós csatornáról küldöd, amiről a jelszó resetek mennek, akkor a panaszok és leiratkozások simán lerombolják a küldői reputációdat, és egy idő után a jelszó-visszaállítás is spambe fog esni.

Marketingre külön Email Service Provider (ESP) való – a forrás példaként Mailchimp-et és ConvertKit-et említ –, mert ezek a platformok kifejezetten tömeges küldésre, leiratkozás-kezelésre és reputáció menedzsmentre vannak kitalálva.

E-mail stratégia 2026-ra: egy praktikus, háromrészes modell

A forrás szerzőjének gondolatát fejlesztői szemmel könnyű összefoglalni: a weboldal e-mailje a kommunikációs csatornád. Ha az alapértelmezett WordPress levélküldést használod, az sokszor annyit ér, mintha viharban suttognál. Hitelesített SMTP-vel és SPF/DKIM-mel viszont olyan, mintha rendes hangosbemondót kapna a rendszer – a fogadó szolgáltatók is sokkal szívesebben „hisznek” neked.

A 2026-os, stabil modell a forrás szerint három pillérre épül:

1. Stabil alap: olyan minőségi, biztonságos hosting környezet, ami nem akadályoz a best practice-ben (példaként: Elementor Hosting).
2. Megbízható tranzakciós csatorna: vagy egy null-konfigos megoldás (példaként: Site Mailer by Elementor), vagy egy klasszikus SMTP bővítmény (pl. WP Mail SMTP) egy dedikált szolgáltatóval, első körben 587-es porton.
3. Professzionális marketing csatorna: külön ESP a hírlevelekhez és promóciókhoz, hogy a domain reputációja és a tranzakciós levelek kézbesíthetősége védve maradjon.

Zárás: a portválasztás csak a kezdet – a cél a bizalom

Az, hogy melyik SMTP portot használd, fontos kérdés, és 2026-ban a legegyszerűbb válasz: 587. De a nagy kép az, hogy a weboldaladnak szakítania kell az alapértelmezett, nem hitelesített levélküldéssel, és át kell állnia egy professzionális, autentikált tranzakciós e-mail csatornára.

Ha ezt jól csinálod (szolgáltató + SPF/DKIM + WordPress integráció, vagy egy integrált „egy kattintásos” megoldás), akkor nem csak portot választasz. Valójában egy megbízható kommunikációs rendszert építesz: a vevő megkapja a nyugtát, a lead beérkezik, a jelszó reset nem vész el. És ez az a minimum, amire egy üzleti weboldalnak szüksége van.

GYIK (FAQ)

1. Mi a legegyszerűbb válasz: melyik SMTP portot használjam?

587-es portot használj STARTTLS titkosítással. Ha ez nem működik, a következő legjobb opció a 465-ös port SMTPS (SSL/TLS) titkosítással.

2. Miért ne használjam a 25-ös portot?

A 25-ös port az eredeti, titkosítatlan SMTP port (1982-ből), amit tömegesen abuzáltak spammerek. Emiatt a legtöbb lakossági ISP és felhős hosting szolgáltató kimenő irányban blokkolja, így weboldalas küldésre jellemzően nem fog működni.

3. Mi a különbség az 587 (STARTTLS) és a 465 (SMTPS) között?

Mindkettő biztonságos. A 465 implicit TLS-t használ, vagyis a titkosított kapcsolat azonnal indul. Az 587 explicit TLS-t használ a STARTTLS paranccsal: először plain-text kapcsolódás, majd „felupgrade-elés” TLS-re. Az 587 a modern, ajánlott standard, de mindkettő működőképes.

4. Mi az a tranzakciós e-mail?

Olyan 1:1 e-mail, amit egy felhasználói művelet indít a weboldalon. Példák: kapcsolatfelvételi űrlap üzenetei, jelszó-visszaállítás, új regisztráció, e-kereskedelmi rendelés-visszaigazolás. Ezeket dedikált tranzakciós SMTP szolgáltatón keresztül érdemes küldeni.

5. Miben más a tranzakciós e-mail a marketing e-mailhez képest?

A marketing e-mail 1:many tömeges küldés (hírlevél, promóció). Ehhez külön ESP való, mert a leiratkozások és spam-jelentések reputációt rontanak. Ha ezt a tranzakciós csatornával kevered, a kritikus leveleid (pl. jelszó reset) is spambe eshetnek.

6. Mik az SPF és DKIM rekordok, és tényleg kellenek?

Igen, kellenek. DNS rekordok, amik igazolják, hogy a leveleid legitim forrásból jönnek. Az SPF megmondja, mely szerverek küldhetnek a domain nevében. A DKIM digitális aláírást ad, amivel ellenőrizhető, hogy a levél nem lett módosítva. Nélkülük a leveleid könnyen spamnek tűnnek.

7. Az SMTP bővítmény „Host”-ot kér. Mi ez?

A „Host” az SMTP szolgáltatód levelezőszerverének címe. Például SendGrid esetén smtp.sendgrid.net, Google-nél smtp.gmail.com. A pontos értéket a szolgáltató dokumentációja/adatlapja adja meg.

8. Használhatom a sima Gmail fiókomat weboldal e-mail küldésre?

Technikailag igen, de nem ideális. A WordPress adminba személyes belépési adatok kerülhetnek (biztonsági kockázat), és a Google szigorú küldési limiteket alkalmaz. Ha a forgalmad megugrik, átmenetileg le is tilthatják a küldést. Üzleti célra jobb dedikált szolgáltatóval menni.

9. Mi a legegyszerűbb módja a WordPress e-mail problémák megoldásának?

A legegyszerűbb egy „zero-configuration” bővítmény használata, például a Site Mailer by Elementor, ami egy kattintással megoldja a tranzakciós levelek útvonalát és kézbesíthetőségét anélkül, hogy külön szolgáltatót, portot vagy API key-t kellene konfigurálnod.

10. Hogyan teszteljem, hogy működik az SMTP beállításom?

A jobb SMTP bővítmények (például a WP Mail SMTP) beállításain belül van „Test Email” fül. Küldj egy teszt üzenetet a WordPress adminból a saját címedre. Ha a bejövő mappába érkezik, rendben vagy.