SMTP prievadai 2026-aisiais: kaip teisingai pasirinkti portą ir sutvarkyti WordPress el. laiškų pristatomumą

Jei valdai svetainę, tikiesi vieno paprasto dalyko: el. laiškai turi veikti. Kad užklausos iš kontaktų formos pasiektų tavo pašto dėžutę. Kad klientai gautų užsakymo patvirtinimą, o vartotojai – slaptažodžio atstatymo nuorodą. Kai taip neįvyksta, tai nėra smulkmena: prarandi lead’us, pardavimus ir pasitikėjimą.

Dažniausiai „tylusis kaltininkas“ yra numatytosios svetainės pašto nustatymai. Dauguma svetainių (ypač WordPress) pagal nutylėjimą siunčia laiškus taip, kad Gmail ar Outlook tai labai primena šlamštą. Išeitis – apeiti šį trapų mechanizmą ir siųsti laiškus per profesionalų, autentifikuotą kanalą, naudojant SMTP (Simple Mail Transfer Protocol). Tik tada atsiranda praktiškas, bet kritinis klausimas: kurį SMTP portą rinktis 2026 metais?

Svarbiausios išvados (jei reikia greito atsakymo)

• Trumpas atsakymas: naudok 587 portą su STARTTLS šifravimu. Tai modernus, saugus ir rekomenduojamas standartas laiškų siuntimui iš svetainės ar el. pašto kliento.
• Gera alternatyva: 465 portas su SMTPS (implicit SSL/TLS). Jį taip pat dažnai rekomenduoja tiekėjai; jei 587 neveikia, 465 paprastai yra geriausias kitas pasirinkimas.
• Portas, kurio reikia vengti: niekada nenaudok 25 porto el. laiškų submission (siuntimui iš svetainės). Jis nenaudoja šifravimo, istoriškai skirtas serveris–serveriui relay, ir dažniausiai yra blokuojamas hostingo/ISP dėl spamo prevencijos.
• Tikroji problema („kodėl“): numatytoji WordPress el. pašto funkcija (wp_mail()) siunčia neautentifikuotai – iš web serverio, kuris neturi el. pašto reputacijos. Modernūs filtrai tai vertina kaip įtartiną srautą.
• Tikrasis sprendimas („kaip“): naudok dedikuotą transactional SMTP paslaugą (pvz., SendGrid, Brevo ar Mailgun), kuri siunčia per patikimą, autentifikuotą serverį.
• „Easy button“ WordPress’e: paprasčiausias kelias – įskiepis, kuris tai sutvarko be rankinio porto/API konfigūravimo. Pavyzdys: Site Mailer by Elementor – „zero-configuration“ (be konfigūracijos) sprendimas, nukreipiantis transactional laiškus per didelio pristatomumo tiekėją.
• Transactional vs. marketing: SMTP kanalas yra skirtas transactional laiškams (formos, reset’ai, kvitai). Naujienlaiškiams ir masinėms kampanijoms būtina naudoti atskirą email marketing platformą (ESP), kad nesugadintum siuntėjo reputacijos.

Kas yra SMTP ir kodėl tai svarbu tavo svetainei?

SMTP (Simple Mail Transfer Protocol) gali įsivaizduoti kaip oficialų interneto paštą: bendrą taisyklių rinkinį, pagal kurį el. pašto klientai (Outlook, Apple Mail ir pan.) ir serveriai susitaria, kaip perduoti laiškus.

Kai siunčiama žinutė, ji nekeliauja tiesiai į gavėjo pašto dėžutę. Tipinis kelias atrodo taip:

1. El. pašto klientas (ar tavo svetainė) perduoda laišką į išeinantį pašto serverį (pvz., smtp.gmail.com) – tai vadinama submission.
2. Tada tavo pašto serveris suranda gavėjo serverį ir persiunčia laišką – tai relay.
3. Gavėjo serveris saugo laišką, kol gavėjas atsidarys inbox’ą.

SMTP protokolas naudojamas tiek submission, tiek relay etapams. O „SMTP port“ – tai tiesiog numeriu pažymėtos „durys“ serveryje, pro kurias vyksta šis procesas.

WordPress problema: kodėl wp_mail() dažnai nepatikimas?

Pagal nutylėjimą WordPress net nenaudoja SMTP. Jis remiasi PHP funkcija wp_mail(), kuri bando išsiųsti laišką tiesiai iš web serverio.

Pristatomumo prasme tai yra rimtas minusas:

1. Tai nėra pašto serveris. Web serveris optimizuotas HTML/PHP aptarnavimui, o ne el. pašto siuntimui ir reputacijos valdymui.
2. Nėra autentifikacijos. Serveris tiesiog „pasiskelbia“, kad siuntėjas yra tavo-domenas.lt, bet neįrodo, kad turi teisę tai daryti.
3. Nėra reputacijos. Gmail/Microsoft kaupia reputacijos balus žinomiems pašto siuntėjams. Web serveris dažniausiai neturi el. pašto reputacijos, todėl laikomas „nauju/nežinomu“ ir įtartinu siuntėju.
4. „Blogas IP rajonas“. Shared hostinge gali dalintis IP su šimtais svetainių. Jei viena jų siuntinėja spamą, IP gali būti užblokuotas, o kartu nukentės ir tavo teisėti laiškai.

Rezultatas dažnai toks pats: laiškai nusėda į spam’ą arba yra tyliai atmetami be jokio pranešimo. Todėl praktiškai visada verta priversti WordPress apeiti wp_mail() kelią ir siųsti per profesionalų SMTP tiekėją. Tam reikia pasirinkti tinkamą portą.

Trumpa SMTP portų istorija: kodėl daug variantų šiandien praktiškai nebeaktualūs?

SMTP portų istorija iš esmės yra nuolatinė interneto kova su spamu. Supratus, kodėl atsirado skirtingi portai, lengviau suprasti, kodėl 2026-aisiais sprendimas iš esmės susiveda į 587 arba 465.

Portas 25: originalus kelias, virtęs „spamo magistrale“

Istoriškai (1982 m.) SMTP turėjo vieną portą – 25. Jis buvo skirtas serveris–serveriui laiškų persiuntimui (Mail Transfer Agents, MTA). Viskas buvo paprasta: autentifikacijos nereikia, bet kuris serveris gali prisijungti ir perduoti laišką.

Problema išryškėjo greitai: spammer’iai galėjo jungtis prie serverių per 25 portą ir stumti masinį šlamštą. Tai buvo atviras, nešifruotas, neautentifikuotas kanalas piktnaudžiavimui.

Šiandien dėl šios „istorinės skolos“ beveik visi ISP, cloud tiekėjai ir net gyvenamieji tinklai blokuoja outbound jungtis į 25 portą. Tikslas – stabdyti botnet’us ir kompromituotus serverius, kurie siunčia spamą.

Portas 465: pirmas saugus sprendimas (SMTPS / implicit TLS)

1990-ųjų pabaigoje tapo aišku, kad el. paštui reikia šifravimo. Taip atsirado 465 portas, įvedęs SMTPS (SMTP over SSL). Prisijungimas su šiuo portu nuo pat pradžių vyksta per SSL/TLS „tunelį“ – dar prieš siunčiant SMTP komandas. Tai vadinama Implicit SSL/TLS.

Įdomi detalė: 465 buvo plačiai naudojamas, bet ilgą laiką nebuvo laikomas „pilnai oficialiu“ IETF standartu ir net buvo trumpam „deprecated“ STARTTLS naudai. Visgi praktika nugalėjo: 465 padarė didelį sugrįžimą ir šiandien yra priimtas, saugus ir labai populiarus pasirinkimas. Jį rekomenduoja ir dideli tiekėjai, įskaitant Gmail.

Portas 587: modernus standartas (STARTTLS / explicit TLS)

Kad būtų sutvarkyta standartizacijos dalis, IETF oficialiai paskyrė 587 portą kaip pagrindinį email submission portą (kai klientas arba svetainė siunčia laišką į SMTP serverį). Šiame porte dažniausiai naudojamas STARTTLS metodas, dar vadinamas Explicit TLS.

Kaip atrodo STARTTLS derybos (aukšto lygio):

1. Svetainė prisijungia prie serverio per 587 portą plain text režimu.
2. Svetainė siunčia EHLO komandą (prisistatymas).
3. Serveris grąžina galimybių sąrašą, tarp jų – STARTTLS.
4. Svetainė siunčia STARTTLS komandą ir „pakelia“ ryšį iki šifruoto.
5. Sukuriamas TLS tunelis, o tik tada keliauja prisijungimo duomenys ir siunčiamas laiškas.

Teoriškai tai leidžia tam pačiam portui aptarnauti ir šifruotus, ir nešifruotus ryšius. Praktikoje 2026-aisiais serveris, kuris 587 porte nelemtų šifravimo, laikomas nesaugiu.

Būtent dėl to 587 yra rekomenduojamas, modernus ir dažniausias pasirinkimas email submission scenarijui – ir pirmas portas, kurį verta bandyti.

Portas 2525: ne standartas, bet naudinga atsarginė opcija

Kartais dokumentacijoje pamatysi 2525. Tai nėra oficialus SMTP portas – tai alternatyvus prievadas, kurį daugelis paslaugų palaiko kaip atsarginį variantą.

Kada jis praverčia: kai tavo hostingo aplinka blokuoja ir 587, ir 465. Tai reta, bet pasitaiko, ypač kai kurios cloud platformos riboja 587 siekdamos mažinti spamo riziką ir verčia naudoti relaying servisus, kurie klausosi 2525. Dažniausiai 2525 veikia su STARTTLS panašiai kaip 587.

2026 metų verdiktas: kurį SMTP portą rinktis?

Pagrindinis pasirinkimas: 587 (STARTTLS)

Tai turi būti tavo default’as. 587 yra oficialus, modernus submission standartas, jį palaiko praktiškai visi SMTP tiekėjai, ir jis skirtas būtent tam scenarijui, kurio reikia svetainei. Konfigūruojant SMTP įskiepį WordPress’e, pradėk nuo 587 ir STARTTLS/TLS.

Antras pasirinkimas: 465 (SMTPS / SSL)

Jei 587 dėl kokios nors priežasties neveikia arba jei tiekėjas (pvz., Gmail/Google Workspace) aiškiai rekomenduoja 465 – tai puiki ir labai saugi alternatyva. Čia šifravimas „implicit“, t. y. saugus tunelis užmezgamas iš karto.

Beveik niekada: 25

Svetainės el. laiškų siuntimui (submission) – ne. Jo šiuolaikinė paskirtis yra serveris–serveriui relay, o ne tai, ką daro WordPress kontaktų forma ar WooCommerce.

SMTP portų palyginimas (greita lentelė)

Portas | Protokolas | Saugumas                 | Dažnas panaudojimas                 | Rekomenduojamas svetainei?
------ | ---------- | ------------------------ | ----------------------------------- | -------------------------
25     | SMTP       | Nėra                     | Serveris–serveriui (relay)          | NE (dažnai blokuojamas)
465    | SMTPS      | Implicit SSL/TLS         | Klientas/svetainė → serveris        | Taip (saugus ir paplitęs)
587    | SMTP       | Explicit (STARTTLS)      | Klientas/svetainė → serveris        | TAIP (rekomenduojamas)
2525   | SMTP       | Explicit (STARTTLS)      | Atsarginis submission kanalas       | Tik jei 587/465 blokuojami

Portas | Protokolas | Saugumas                 | Dažnas panaudojimas                 | Rekomenduojamas svetainei?
------ | ---------- | ------------------------ | ----------------------------------- | -------------------------
25     | SMTP       | Nėra                     | Serveris–serveriui (relay)          | NE (dažnai blokuojamas)
465    | SMTPS      | Implicit SSL/TLS         | Klientas/svetainė → serveris        | Taip (saugus ir paplitęs)
587    | SMTP       | Explicit (STARTTLS)      | Klientas/svetainė → serveris        | TAIP (rekomenduojamas)
2525   | SMTP       | Explicit (STARTTLS)      | Atsarginis submission kanalas       | Tik jei 587/465 blokuojami

Kaip sutvarkyti WordPress el. paštą: žingsnis po žingsnio

Vien pasirinkti portą neužtenka – reikia pakeisti patį siuntimo kelią. Žemiau – praktinis procesas, kuris realiai ištraukia WordPress laiškus iš „email void“.

1 žingsnis: pasirink dedikuotą transactional SMTP tiekėją

Pirmiausia reikia nustoti siųsti laiškus iš web serverio ir užsiregistruoti pas transactional email tiekėją. Tai paslaugos, kurių verslas sukasi apie pristatomumą ir reputaciją.

• Ką jie daro: suteikia aukštos reputacijos pašto serverį, per kurį gali siųsti svetainės laiškus per SMTP arba API (API – programinis sąsajos raktas, leidžiantis siųsti be SMTP prisijungimo duomenų).
• Populiarūs tiekėjai:
• – SendGrid (labai populiarus, dažnai minimas dėl stipraus nemokamo plano)
• – Brevo (anksčiau Sendinblue)
• – Mailgun
• – Postmark (žinomas dėl ypač gero pristatomumo)
• – Amazon SES (galingas, bet sudėtingesnis)
• – Google Workspace / Gmail (tinka mažiems kiekiams, bet verslui nerekomenduojama dėl limitų ir rizikų)

Daugeliui mažų ir vidutinių projektų nemokamų planų pilnai pakanka būtent transactional srautui.

2 žingsnis: susikonfigūruok domeno DNS įrašus (SPF ir DKIM)

Tai kritiškiausia techninė dalis. Kai turi SMTP tiekėją, turi „įrodyti“ pasauliui, kad jis turi teisę siųsti laiškus tavo vardu. Tai daroma domeno DNS įrašais (ten, kur valdai DNS: registratoriuje ar atskiroje DNS platformoje). Tiekėjas pateiks konkrečius įrašus, kuriuos nukopijuosi.

• SPF (Sender Policy Framework): TXT įrašas, veikiantis kaip „svečio sąrašas“. Jis nurodo, kad laiškai iš tavo-domenas.lt laikomi teisėtais tik jei ateina iš konkrečių šaltinių (pvz., tavo leidžiamų IP ir SendGrid/Brevo infrastruktūros). Tai mažina spoofing (siuntėjo adreso klastojimo) riziką.
• DKIM (DomainKeys Identified Mail): TXT įrašas su viešuoju raktu, leidžiantis gavėjui patikrinti skaitmeninį parašą. SMTP tiekėjas pasirašo kiekvieną laišką privačiu raktu, o gavėjo serveris patikrina parašą pagal tavo DNS. Taip įrodoma, kad laiškas nebuvo pakeistas kelyje.

3 žingsnis: įdiek ir sukonfigūruok SMTP įskiepį WordPress’e

Kad WordPress pradėtų naudoti tavo pasirinktą tiekėją, patogiausia naudoti įskiepį, kuris perima wp_mail() iškvietimus ir nukreipia srautą per SMTP/API.

Dažniausiai sutinkami SMTP įskiepiai:

• WP Mail SMTP
• FluentSMTP
• Post SMTP

Bendra konfigūravimo logika daugelyje jų panaši:

1. Įdiek ir aktyvuok pasirinktą SMTP įskiepį.
2. WordPress administracijoje atsidaryk įskiepio nustatymus.
3. Pasirink „Mailer“ (tiekėją): pvz., SendGrid.
4. Įvesk prisijungimo duomenis:
5. – Geriausias variantas (API): daug įskiepių rekomenduoja API key. Tai saugiau ir patikimiau nei laikyti SMTP slaptažodį WordPress’e.
6. – SMTP variantas („Other SMTP“): jei nenaudoji API, reikės suvesti SMTP parametrus ranka.
7. Jei konfigūruoji per SMTP (ne per API), suvesk:
8. – SMTP Host: tiekėjas nurodo (pvz., smtp.sendgrid.net, o Google atveju smtp.gmail.com).
9. – Encryption: rinkis TLS (tai reiškia STARTTLS). Jei tokios opcijos nėra, gali būti SMTPS (tai atitinka SSL).
10. – SMTP Port: 587 (kai naudoji TLS/STARTTLS) arba 465 (kai naudoji SMTPS/SSL).
11. – Authentication: įjunk (ON).
12. – SMTP Username: suteikia tiekėjas.
13. – SMTP Password: suteikia tiekėjas.
14. Sutvarkyk „From“ reikšmes:
15. – From Email: turi būti iš autentifikuoto domeno.
16. – From Name: dažniausiai svetainės ar prekės ženklo pavadinimas.

4 žingsnis: testuok ir stebėk logus

Dauguma SMTP įskiepių turi „Test Email“ skiltį. Siųsk testą į asmeninį Gmail ar Outlook.

• Jei laiškas atėjo į inbox – puiku, siuntimas tapo autentifikuotas ir stabilus.
• Jei pateko į spam – dar kartą patikrink SPF/DKIM (DNS propagacija gali užtrukti kelias valandas).
• Jei nepavyksta išsiųsti – greičiausiai neteisingas host/port/username/password arba hostingo apribojimas. Patikrink nustatymus ir pabandyk 465 vietoje 587 (su atitinkamu šifravimu) arba atvirkščiai.

„Paprastas“ kelias: kai modernios WordPress platformos tai už tave sutvarko

Realybėje keturių žingsnių procesas (tiekėjas → DNS → įskiepis → testai) verslo savininkui dažnai yra per daug: skirtingi panel’iai, API key’ai, DNS įrašai, portų apribojimai. Dėl to atsiranda integruoti sprendimai, kurie šią būtinybę supaprastina.

Sprendimas #1: integruotas transactional el. paštas („easy button“)

Jei pagrindinė bėda yra neautentifikuotas wp_mail(), logiškiausia – naudoti sprendimą, kuris jį apeina be sudėtingos konfigūracijos. Vienas iš tokių variantų: Site Mailer by Elementor, pozicionuojamas kaip „zero-configuration“ įskiepis.

• Kaip veikia: įdiegti ir aktyvuoti – ir tiek.
• Ką daro: automatiškai perroutina visus svetainės transactional laiškus (kontaktų formos, WooCommerce, slaptažodžio atstatymai ir pan.) per autentifikuotą, didelio pristatomumo servisą.
• Kodėl tai patogu: nereikia registruotis pas atskirą SMTP tiekėją, nereikia API key’ų, nereikia SPF/DKIM konfigūravimo ir nereikia spręsti, kurį portą pasirinkti.

Sprendimas #2: valdomas hostingas su tinkama SMTP infrastruktūra

Kita pasikartojanti problema – hostingo politika (užblokuoti portai, ribojimai). Aukštos kokybės valdomas WordPress hostingas paprastai supranta wp_mail() problemą ir sudaro sąlygas naudoti gerą praktiką.

Pavyzdžiui, Elementor Hosting aprašomas kaip cloud infrastruktūra, orientuota į našumą, kur taip pat turėtų būti sudarytos prielaidos naudoti pašto servisus (pvz., kad 587 būtų atviras ir pasiekiamas su pasirinktu SMTP įskiepiu). Esmė čia ne „magija“, o patikimas pagrindas, kad galėtum įgyvendinti standardinę konfigūraciją nekovodamas su serverio apribojimais.

Už SMTP ribų: esminis atskyrimas (transactional vs. marketing)

Sutvarkius SMTP, svarbiausia taisyklė skamba taip: naujienlaiškių nesiųsk per transactional SMTP kanalą.

Tavo SendGrid/Site Mailer (ar kito transactional) kanalas yra skirtas tik transactional laiškams – tiems, kurių vartotojas tikisi čia ir dabar.

• Transactional el. paštas (siųsti per SMTP): vienas–vienam laiškai, suaktyvinami vartotojo veiksmo.
• – Slaptažodžio atstatymai
• – Užsakymo patvirtinimai
• – Formų pranešimai
• – Naujo vartotojo registracija
• – „Welcome“ laiškai
• Marketing el. paštas (siųsti per ESP): vienas–daugeliui siuntimai.
• – Savaitiniai naujienlaiškiai
• – Šventinės akcijos
• – Naujų produktų anonsai

Jei per transactional kanalą išsiųsi 10 000 gavėjų naujienlaiškį, natūraliai gausi daugiau unsubscribe ir spam complaint’ų. Tai smogs domeno reputacijai, o po to net slaptažodžio reset’ai pradės keliauti į spam’ą. Marketingui naudok atskirą ESP platformą (pvz., Mailchimp ar ConvertKit), kuri skirta masinei siuntai, atskirai tvarko atsisakymus ir reputaciją.

Praktinė rekomendacija el. pašto strategijai 2026-aisiais

Jei sudėčiau į vieną aiškią schemą, 2026 metų el. pašto strategija svetainei turi būti trijų dalių:

1. Stabilus pagrindas: kokybiškas, saugus hostingas, kuris netrukdo diegti geros praktikos (pvz., neatjungia 587/465 ir leidžia naudoti SMTP paslaugą).
2. Patikimas transactional kanalas: arba „zero-config“ sprendimas, pvz., Site Mailer by Elementor, arba klasikinė konfigūracija su SMTP įskiepiu (pvz., WP Mail SMTP) ir tiekėju (pvz., SendGrid) per 587 portą.
3. Atskiras marketing kanalas: naujienlaiškiams ir kampanijoms naudok ESP, kad transactional reputacija išliktų švari.

Išvada: nustok praradinėti laiškus ir atkurk pasitikėjimą

Klausimas „kurį SMTP portą naudoti?“ yra gera pradžia. 2026-aisiais trumpas atsakymas – 587. Tačiau pilnas atsakymas yra apie tai, kad turi pakeisti WordPress siuntimo mechanizmą: atsisakyti pliko wp_mail() ir pereiti prie autentifikuoto, profesionalaus siuntimo per SMTP/API.

Kai pasirenki tiekėją, susitvarkai SPF/DKIM, sukonfigūruoji įskiepį ir pasitestuoji, tu ne tik „pasirenki portą“. Tu susikuri patikimą komunikacijos kanalą: klientai gauna kvitus, lead’ai ateina į inbox, o verslas veikia taip, kaip turėtų.

DUK (FAQ)

1. Koks paprastas atsakymas: kurį SMTP portą naudoti?

Naudok 587 portą su STARTTLS šifravimu. Jei neveikia – kitas geriausias pasirinkimas yra 465 portas su SMTPS (SSL/TLS).

2. Kodėl nereikėtų naudoti 25 porto?

25 portas yra originalus, nešifruotas SMTP portas (nuo 1982 m.). Jis buvo masiškai piktnaudžiaujamas spamer’ių, todėl dabar beveik visi gyvenamieji ISP ir daug cloud hostingo tiekėjų blokuoja outbound srautą į 25. Praktikoje jis neveiks submission scenarijui.

3. Kuo skiriasi 587 (STARTTLS) ir 465 (SMTPS)?

Abu yra saugūs. 465 naudoja Implicit TLS – saugus ryšys užmezgamas iš karto. 587 naudoja Explicit TLS per STARTTLS komandą – ryšys pradžioje plain-text, tada „upgradinamas“ iki TLS. 587 laikomas moderniu rekomenduojamu standartu, bet abu variantai realiai veikia.

4. Kas yra „transactional email“?

Tai vienas–vienam laiškai, kuriuos inicijuoja vartotojo veiksmas svetainėje: kontaktų formos užklausa, slaptažodžio atstatymas, nauja registracija, e. komercijos užsakymo patvirtinimas ir pan. Tokius laiškus reikia siųsti per dedikuotą SMTP paslaugą.

5. Kuo transactional skiriasi nuo marketing el. pašto?

Marketing el. paštas yra vienas–daugeliui (naujienlaiškiai, akcijos, anonsai). Jam reikia atskiros platformos (ESP), kad masiniai siuntimai ir skundai nesugadintų domeno reputacijos ir nepakenktų transactional laiškams.

6. Kas yra SPF ir DKIM, ir ar tikrai jų reikia?

Taip, jų reikia. Tai DNS įrašai, kurie įrodo, kad laiškai teisėti. SPF nurodo, kurie serveriai gali siųsti laiškus tavo domeno vardu. DKIM prideda skaitmeninį parašą, leidžiantį patikrinti, kad laiškas nebuvo pakeistas. Be jų laiškai dažnai atrodo kaip spam.

7. SMTP įskiepis prašo „Host“. Kas tai?

„Host“ yra SMTP tiekėjo serverio adresas. Pvz., SendGrid naudoja smtp.sendgrid.net, Google – smtp.gmail.com. Tikslų host’ą visada pateikia pasirinktas tiekėjas.

8. Ar galiu svetainės laiškus siųsti per savo įprastą Gmail paskyrą?

Techniškai gali, bet nereikėtų. WordPress’e tektų laikyti asmeninį prisijungimą (saugumo rizika), be to, Google taiko griežtus siuntimo limitus. Jei srautas šoktels, paskyra gali būti laikinai apribota. Patikimiau naudoti dedikuotą transactional tiekėją.

9. Koks lengviausias būdas sutvarkyti WordPress el. pašto problemas?

Lengviausias kelias – „zero-configuration“ sprendimas, pvz., Site Mailer by Elementor, kuris vienu įdiegimu perroutina transactional laiškus per autentifikuotą didelio pristatomumo servisą be portų, API key ar DNS konfigūravimo.

10. Kaip patikrinti, ar SMTP nustatymai veikia?

Geri SMTP įskiepiai (pvz., WP Mail SMTP) turi „Test Email“ funkciją nustatymuose. Išsiųsk testinį laišką iš WordPress į savo asmeninį adresą. Jei jis ateina į inbox – konfigūracija veikia.