SMTP-portit 2026: miten valitset oikean (ja miksi WordPressin wp_mail() pettää niin usein)

Verkkosivuston sähköpostin pitäisi olla tylsän luotettavaa: yhteydenottolomakkeen viestit tulevat perille, WooCommercen tilausvahvistukset osuvat inboxiin ja salasanan palautukset eivät jää limboon. Kun näin ei käy, kyse ei ole pelkästä harmista – se on suora luottamuksen menetys, joka näkyy liideissä, asiakkaissa ja uskottavuudessa.

Yllättävän usein syy löytyy “hiljaisesta oletuksesta”: sivusto lähettää postin web-palvelimen oletusasetuksilla tavalla, joka näyttää Gmailin tai Outlookin silmissä roskapostilta. Korjaus on ohittaa tämä rikkoutunut oletusreitti ja lähettää viestit ammattilaistason, todennetun kanavan kautta – käytännössä SMTP:n (Simple Mail Transfer Protocol) avulla. Mutta heti tulee se tekninen kysymys, joka ratkaisee paljon: mitä SMTP-porttia kannattaa käyttää vuonna 2026?

Pähkinänkuoressa: tärkeimmät huomiot (2026)

• Nopea vastaus: käytä porttia 587 ja STARTTLS-salausta. Tämä on moderni, turvallinen ja suositeltu standardi, kun sivusto tai sähköpostiohjelma lähettää postia (submission).
• Hyvä vaihtoehto: portti 465 ja SMTPS (implicit SSL/TLS). Moni palvelu tukee ja osa jopa suosii tätä. Jos 587 ei toimi, 465 on seuraava valinta.
• Vältä tätä: älä käytä porttia 25 sähköpostin lähetykseen sivustolta (submission). Se on salaamaton, tarkoitettu pääasiassa palvelinten väliseen relay-liikenteeseen ja lisäksi lähes aina estetty hosteissa/ISP:issä roskapostin torjumiseksi.
• Varsinainen ongelma (miksi viestit katoavat): WordPressin oletuslähetys (esim. wp_mail()) on käytännössä todentamaton ja lähtee web-palvelimelta, jolla ei ole sähköpostin lähetysreputaatiota.
• Varsinainen ratkaisu (miten tämä korjataan): käytä dedikoitua transactional email -palvelua (esim. SendGrid, Brevo tai Mailgun), jolloin viestit lähtevät luotetun ja todennetun palvelimen kautta.
• Helpoin nappi WordPressissä: jos haluat minimoida DNS-/portti-/API-säädön, “zero-configuration” -tyyppinen lisäosa kuten Site Mailer by Elementor voi reitittää sivuston transaktioviestit toimitusvarman palvelun kautta ilman porttivalintoja tai API-avaimia.
• Transactional vs. marketing: SMTP-reitti on tarkoitettu transaktioviesteille (lomakkeet, salasanat, kuitit). Uutiskirjeet ja massalähetykset pitää hoitaa erillisellä email marketing / ESP -alustalla (esim. Mailchimp, ConvertKit), jotta lähetysreputaatio ei romahda.

Mikä SMTP on – ja miksi sillä on väliä verkkosivustolle?

Ajattele SMTP:tä internetin virallisena digitaalisena postitoimistona. SMTP (Simple Mail Transfer Protocol) on sääntökirja, jota sähköpostiohjelmat (kuten Outlook tai Apple Mail) ja sähköpostipalvelimet käyttävät viestien lähettämiseen ja välittämiseen.

Kun lähetät sähköpostin, viesti ei “teleporttaa” suoraan vastaanottajalle:

1. Sähköpostiohjelma (tai sivusto) lähettää viestin lähtevän postin palvelimelle (esim. smtp.gmail.com). Tätä vaihetta kutsutaan submissioniksi.
2. Lähtevä palvelin etsii vastaanottajan postipalvelimen ja välittää (relay) viestin eteenpäin.
3. Vastaanottajan palvelin säilyttää viestin, kunnes käyttäjä avaa inboxin.

SMTP on mukana erityisesti vaiheissa 1 ja 2. SMTP-portti taas on yksinkertaisesti se numeroitu “ovi” palvelimessa, jota pitkin tämä liikenne kulkee.

WordPressin wp_mail()-ongelma: miksi oletuslähetys näyttää roskapostilta

Moni WordPress-sivusto ei käytä SMTP:tä ollenkaan. Oletuksena se käyttää PHP:n ja WordPressin tarjoamaa funktiota wp_mail(), joka yrittää lähettää postin suoraan web-palvelimelta.

Toimitettavuuden (deliverability) näkökulmasta tämä on iso riski:

1. Web-palvelin ei ole postipalvelin. Se on optimoitu palvelemaan HTTP-pyyntöjä, ei rakentamaan luotettavaa sähköpostilähetyspolkua.
2. Lähetys on todentamaton. Palvelin käytännössä vain väittää lähettävänsä domainistasi (esim. your-domain.com), ilman kunnollista autentikointia.
3. Reputaatio puuttuu. Gmail/Microsoft ylläpitävät reputaatiota tunnetuille lähetyspalvelimille. Web-palvelimen sähköpostireputaatio on usein olematon, jolloin se näyttää “uudelta ja epäilyttävältä”.
4. Jaettu IP-ympäristö voi olla myrkkyä. Jaetussa hostauksessa sama IP voi palvella satoja sivustoja. Jos yksikin niistä spämmää, koko IP voi päätyä blokkilistoille – ja silloin myös täysin legitiimit viestisi alkavat tippua tai kadota.

Lopputulos: vastaanottava palvelu näkee todentamattoman viestin epämääräiseltä web-palvelimelta ja ohjaa sen roskapostiin tai blokkaa kokonaan – usein ilman mitään näkyvää virheilmoitusta sivuston omistajalle.

Siksi käytännön ratkaisu on pakottaa WordPress ohittamaan wp_mail()-oletusreitti ja lähettämään viestit ammattilaisen SMTP-/API-kanavan kautta. Ja siinä porttivalinta astuu kuvaan.

SMTP-porttien lyhyt historia: miksi suurin osa on käytännössä vanhentunut

Portit eivät ole syntyneet sattumalta. SMTP-porttien kehitys on pitkälti tarina siitä, miten internet on vuosikymmenten ajan yrittänyt pysyä roskapostin ja väärinkäytön edellä.

Portti 25: alkuperäinen “spam highway”

Alun perin (vuonna 1982) SMTP-liikenne kulki käytännössä vain portin 25 kautta. Se suunniteltiin sähköpostipalvelimien väliseen välitykseen (server-to-server relay; MTA-to-MTA). Kaikki oli avointa: ei autentikointia, ei salausta.

Ongelma oli ilmeinen heti kun roskaposti räjähti: kuka tahansa pystyi yhdistämään mihin tahansa postipalvelimeen portissa 25 ja syöttämään sinne massiivisia määriä spämmiä.

Nykytila: tämän historian takia lähes kaikki ISP:t, cloud-palvelut ja hostausympäristöt estävät ulospäin suuntautuvat portti 25 -yhteydet. Tarkoitus on pysäyttää bottiverkot ja kompromettoidut palvelimet, jotka yrittävät spämmätä.

Portti 465: ensimmäinen “turvallinen” ratkaisu (SMTPS)

1990-luvun lopulla tarvittiin salaus. Silloin syntyi portti 465, joka toteutti SMTPS:n (“SMTP over SSL”). Yhteys aloitetaan heti suojattuna: ensin SSL/TLS-kättely, ja vasta sen jälkeen SMTP-komennot. Tätä kutsutaan implicit SSL/TLS -malliksi.

Teknisesti portti 465 ei ollut pitkään virallinen IETF-standardi, ja se ehti olla hetkellisesti jopa “deprecated” STARTTLS-mallin tieltä. Käytännössä se kuitenkin jäi elämään – ja tuli takaisin vahvana.

Nykytila: portti 465 on nykyään laajasti hyväksytty ja erittäin yleinen. Useat isot toimijat (mukaan lukien Google/Gmail) suosittelevat sitä edelleen. Verkkosivuston näkökulmasta se on täysin validi ja turvallinen valinta.

Portti 587: moderni standardi (STARTTLS)

Standardeihin haluttiin selkeyttä, ja IETF määritteli portin 587 viralliseksi portiksi nimenomaan email submission -käyttöön (eli kun asiakas tai sivusto lähettää viestejä).

Portti 587 käyttää tyypillisesti STARTTLS-salausta, jota kutsutaan myös explicit TLS -malliksi. Yhteys aloitetaan periaatteessa selväkielisenä ja “nostetaan” TLS:ään komennolla.

1. Sivusto muodostaa yhteyden postipalvelimeen portissa 587.
2. Sivusto lähettää EHLO-komennon.
3. Palvelin vastaa tuetuilla ominaisuuksilla, mukana yleensä STARTTLS.
4. Sivusto lähettää STARTTLS-komennon ja päivittää yhteyden salatuksi.
5. TLS-tunnelin sisällä lähetetään kirjautuminen ja itse sähköposti.

Vuonna 2026 käytännön oletus on, että porttia 587 käyttävä palvelin pakottaa salauksen. Jos joku sallii aidosti salaamattoman submissionin portissa 587, sitä pidetään nykykriteereillä turvattomana.

Nykytila: portti 587 on suositeltu, yleisin ja käytännössä kaikkialla tuettu submission-standardi. Tämä on ensimmäinen portti, jota kannattaa kokeilla.

Portti 2525: ei-standardi varatie

Välillä törmää myös porttiin 2525. Se ei ole virallinen SMTP-portti, vaan monien hostien ja SMTP-palveluiden tarjoama vaihtoehtoinen “fallback”-ovi.

Milloin sitä käytetään? Silloin kun hostausympäristö blokkaa sekä 587:n että 465:n. Tämä on harvinaista, mutta mahdollista – esimerkiksi joissakin cloud-ympäristöissä rajoitetaan oletusportteja väärinkäytön estämiseksi ja ohjataan käyttäjät erilliseen relay-palveluun, joka kuuntelee 2525:ssä.

Käytännössä 2525 käyttää yleensä samaa STARTTLS-mallia kuin 587.

Vuoden 2026 tuomio: mitä SMTP-porttia sinun kannattaa käyttää?

Kun riisutaan historia ja poikkeukset pois, vuoden 2026 valinta on käytännössä kahden portin peli.

Ensisijainen valinta: portti 587 + STARTTLS

Tämä on oletusvalintasi. Portti 587 on virallinen submission-standardi, lähes universaalisti tuettu ja tarkoitettu juuri tähän käyttötapaukseen. Kun konfiguroit WordPressin SMTP-lisäosaa, aloita tästä: 587 + TLS/STARTTLS.

Toissijainen valinta: portti 465 + SMTPS

Jos 587 ei syystä tai toisesta toimi (tai palveluntarjoaja nimenomaan suosittelee 465:tä), 465 + SSL/TLS (SMTPS) on erinomainen ja erittäin turvallinen vaihtoehto.

Lähes ei koskaan: portti 25

Portti 25 kuuluu palvelinten väliseen relay-liikenteeseen, ei WordPress-sivuston sähköpostien submissioniin. Lisäksi se on käytännössä usein estetty. Sivuston lähetyskäyttöön: älä käytä.

Vertailutaulukko: 25 vs 465 vs 587 vs 2525

Portti | Protokolla | Turva                 | Yleinen käyttö                 | Suositus sivustolle?
------ | --------- | --------------------- | ------------------------------ | -------------------
25     | SMTP      | Ei salausta           | Server-to-server relay         | EI (usein blokattu)
465    | SMTPS     | Implicit SSL/TLS      | Client-to-server submission    | Kyllä (yleinen ja turvallinen)
587    | SMTP      | Explicit TLS (STARTTLS)| Client-to-server submission   | KYLLÄ (suositeltu standardi)
2525   | SMTP      | Explicit TLS (STARTTLS)| Client-to-server (fallback)   | Vain jos 587/465 blokattu

Portti | Protokolla | Turva                 | Yleinen käyttö                 | Suositus sivustolle?
------ | --------- | --------------------- | ------------------------------ | -------------------
25     | SMTP      | Ei salausta           | Server-to-server relay         | EI (usein blokattu)
465    | SMTPS     | Implicit SSL/TLS      | Client-to-server submission    | Kyllä (yleinen ja turvallinen)
587    | SMTP      | Explicit TLS (STARTTLS)| Client-to-server submission   | KYLLÄ (suositeltu standardi)
2525   | SMTP      | Explicit TLS (STARTTLS)| Client-to-server (fallback)   | Vain jos 587/465 blokattu

WordPress-sähköpostin korjaus: vaiheittainen tekeminen

Kun porttivalinta on selvä, itse korjaus on yllättävän suoraviivainen – kunhan teet sen oikeassa järjestyksessä. Tässä malli, joka toimii käytännössä lähes aina.

Vaihe 1: valitse dedikoitu transactional email -palvelu

Ensimmäinen askel on lopettaa web-palvelimen käyttäminen sähköpostiin. Tarvitset transactional email -palvelun, jonka bisnes on nimenomaan toimitettavuus.

• Mitä ne tarjoavat: luotetun, hyvämaineisen lähetyspalvelimen, jota käytät API:n tai SMTP:n kautta sivuston viesteihin.
• Esimerkkejä yleisistä palveluista: SendGrid, Brevo (entinen Sendinblue), Mailgun, Postmark (tunnettu erittäin korkeasta deliverabilitystä), Amazon SES (tehokas, mutta monimutkaisempi), Google Workspace / Gmail (mahdollinen pienen volyymin sivustoille, mutta liiketoiminnassa tulee helposti lähetysrajoja vastaan).

Monen palvelun ilmaiset tasot riittävät pienen tai keskisuuren yrityssivuston transaktioviesteihin (lomakkeet, tilausvahvistukset, salasanat).

Vaihe 2: määritä DNS: SPF ja DKIM

Tämä on se kriittisin tekninen kohta. Kun käytät ulkoista lähetyspalvelua, sinun pitää todistaa vastaanottajille, että olet antanut tälle palvelulle luvan lähettää domainisi nimissä. Tämä tehdään DNS-tietueilla.

SMTP-palvelu antaa sinulle valmiit tietueet kopioitavaksi sinne missä DNS:ää hallitaan (domain-rekisteröijä tai erillinen DNS-palvelu).

• SPF (Sender Policy Framework): TXT-tietue, joka toimii domainin “vieraslistana”. Se kertoo vastaanottajille, että vain tietyt palvelimet/IP-osoitteet saavat lähettää sähköpostia domainisi nimissä. Tämä torjuu spoofingia (lähettäjän väärentämistä).
• DKIM (DomainKeys Identified Mail): TXT-tietue, joka mahdollistaa viestien digitaalisen allekirjoituksen. Lähetyspalvelu allekirjoittaa viestit yksityisavaimella, ja vastaanottaja tarkistaa allekirjoituksen DNS:ssä julkaistulla julkisavaimella. Tämä todistaa, ettei viestiä ole muutettu matkalla.

Vaihe 3: asenna ja konfiguroi SMTP-lisäosa WordPressiin

Seuraavaksi WordPress pitää ohjata käyttämään uutta reittiä. Käytännössä helpoin tapa on SMTP-lisäosa, joka “kaappaa” wp_mail()-kutsut ja reitittää ne oikealle palvelulle.

Yleisiä lisäosia ovat esimerkiksi:

• WP Mail SMTP
• FluentSMTP
• Post SMTP

Konfigurointi menee useimmissa samalla kaavalla:

1. Asenna ja aktivoi valitsemasi SMTP-lisäosa.
2. Avaa lisäosan asetukset WordPress-hallinnassa.
3. Valitse “Mailer” eli lähetysmekanismi: usein suoraan palveluntarjoaja (esim. “SendGrid”), tai vaihtoehtoisesti “Other SMTP”.
4. Syötä tunnisteet (credentials): – Suositus (API): moni lisäosa suosii API key -avainta, koska se on yleensä turvallisempi ja luotettavampi kuin perinteinen SMTP-käyttäjä/salasana. – SMTP-tunnukset: jos käytät “Other SMTP” -vaihtoehtoa, syötät hostin, portin ja kirjautumisen käsin.
5. Jos käytät SMTP:tä (ei API:ta), määritä SMTP-asetukset: – SMTP Host: palveluntarjoajan antama osoite (esim. smtp.sendgrid.net). – Encryption: valitse TLS (joka käytännössä tarkoittaa STARTTLS:ää). Jos vaihtoehtona on SMTPS/SSL, se vastaa usein porttia 465. – SMTP Port: 587 (TLS/STARTTLS) tai 465 (SMTPS/SSL). – Authentication: päälle. – SMTP Username: palveluntarjoajalta. – SMTP Password: palveluntarjoajalta.
6. Aseta “From”-tiedot: From Email (mieluiten todennetusta domainista) ja From Name (sivuston/yrityksen nimi).

Vaihe 4: testaa ja seuraa lokia

Useimmissa lisäosissa on “Test Email” -toiminto. Lähetä testiviesti omaan Gmail- tai Outlook-osoitteeseen ja arvioi tulos:

• Jos viesti tulee inboxiin: hyvä – toimitus on nyt todennettu ja huomattavasti luotettavampi.
• Jos viesti menee roskapostiin: tarkista SPF ja DKIM. DNS-muutosten levittäytyminen (propagation) voi myös kestää tunteja.
• Jos lähetys epäonnistuu kokonaan: kyse on usein portti- tai tunnusvirheestä. Tarkista host/portti/username/password ja kokeile tarvittaessa 465↔587 (muista vaihtaa samalla salausasetus TLS↔SSL/SMTPS).

“Helppo ratkaisu” käytännössä: mitä integroidut alustat tarjoavat

Nelivaiheinen malli on web-kehittäjälle peruskauraa, mutta monelle sivuston omistajalle se on paljon: domainin DNS, erillinen SMTP-palvelu ja lisäosan asetukset – plus portit ja avaimet. Tästä syystä markkinoille on tullut integroidumpia ratkaisuja, joissa osa tästä ketjusta piilotetaan.

Ratkaisu 1: integroidut transaktioviestit (“easy button”)

Jos ongelman ydin on todentamattomuus, kaikkein helpoin polku on ratkaisu, joka ohittaa WordPressin oletuslähetyksen ilman monimutkaista konfigurointia.

Tähän tarkoitukseen on tehty esimerkiksi Site Mailer by Elementor, joka on “zero-configuration” -tyyppinen lisäosa.

• Miten se toimii: asennat ja aktivoit lisäosan.
• Mitä se tekee: reitittää automaattisesti sivuston transactional email -viestit (yhteydenottolomakkeet, WooCommerce-viestit, salasanan palautukset jne.) toimitusvarman ja todennetun palvelun kautta.
• Miksi se on eri: et välttämättä tarvitse erillistä SendGrid-tiliä, et API key -avaimia, et SPF/DKIM-asetuksia, etkä porttivalintaa – idea on, että se toimii heti käyttöönottamalla.

Ratkaisu 2: hallittu hosting + SMTP-yhteensopiva ympäristö

Toinen käytännön este on liian rajoittava hosting-ympäristö: portit blokataan tai ulospäin lähtevä SMTP-liikenne on lukittu.

Esimerkiksi Elementor Hosting on rakennettu pilvi-infrastruktuurille, jota kuvataan suorituskykyyn optimoiduksi. Ajatus on myös se, että ympäristö on valmiimpi toimimaan mail-palveluiden kanssa – eli portit kuten 587 ovat käytettävissä SMTP-lisäosan kanssa ilman, että joudut taistelemaan omia rajoituksia vastaan.

SMTP ei ole koko tarina: transactional vs. marketing (tärkeä rajanveto)

Kun sivuston viestit viimein kulkevat perille, tulee se sääntö, joka kannattaa sisäistää heti: älä lähetä uutiskirjeitä ja massapostituksia transactional SMTP -kanavalla.

SMTP-/transactional-palvelu (SendGrid, Site Mailer jne.) on tarkoitettu ensisijaisesti transaktioviesteihin:

• Salasanan palautukset
• Tilausvahvistukset
• Lomakeviestit ja automaattiset kuittaukset
• Uusien käyttäjien rekisteröinnit ja tervetuloviestit

Nämä ovat 1:1-viestejä, jotka käyttäjä odottaa saavansa – ja joiden on pakko osua inboxiin.

Marketing email taas on 1:many-lähetys (uutiskirjeet, kampanjat, tuotejulkistukset). Jos ajat 10 000 vastaanottajan uutiskirjeen transactional-kanavan läpi, saat tyypillisesti enemmän unsubscribeja ja spam complaint -merkintöjä. Se heikentää domainin lähetysreputaatiota, ja pian myös kriittiset transaktioviestit alkavat tippua roskapostiin.

Massalähetyksiin kuuluu käyttää erillistä Email Service Provider (ESP) -alustaa, kuten Mailchimp tai ConvertKit, jotka on tehty nimenomaan bulk-lähetyksiin ja reputaation hallintaan (unsubscribe, analytiikka, listahygienia) erillään sivuston kriittisestä postista.

Käytännön sähköpostistrategia 2026: kolme palikkaa

Kun tätä katsoo web-kehittäjän silmin, toimiva malli tiivistyy kolmeen osaan:

1. Vakaa perusta: hostausympäristö, joka ei estä hyviä käytäntöjä (esim. ei lukitse ulospäin meneviä 587/465-yhteyksiä ilman vaihtoehtoa).
2. Luotettava transaktiokanava: joko helppo “zero-config”-ratkaisu kuten Site Mailer by Elementor, tai manuaalinen SMTP/API-konfigurointi lisäosalla (esim. WP Mail SMTP) ja lähetyspalvelulla (esim. SendGrid) – ensisijaisesti portti 587 + STARTTLS, vaihtoehtona 465 + SMTPS.
3. Ammattilainen marketing-kanava: uutiskirjeet ja kampanjat ESP-alustalla (ei transactional SMTP:n kautta), jotta domainin reputaatio pysyy puhtaana kriittisiä viestejä varten.

Yhteenveto: lopeta katoavat viestit ja rakenna luotettava toimitusketju

Kysymys “mitä SMTP-porttia käytän?” on hyvä aloitus, ja vuonna 2026 vastaus on selkeä: portti 587 (STARTTLS). Jos se ei toimi, portti 465 (SMTPS) on erinomainen vaihtoehto. Portti 25 kuuluu käytännössä toiseen maailmaan, eikä sitä pidä käyttää sivuston submission-lähetyksiin.

Mutta portti on vain yksi osa kokonaisuutta. Todellinen muutos tapahtuu, kun siirrät WordPressin pois wp_mail()-oletuksesta, otat käyttöön dedikoidun lähetyspalvelun ja varmistat DNS-todennukset (SPF + DKIM). Silloin tilausvahvistukset, liidit ja salasanaviestit lakkaavat olemasta arpapeliä.

FAQ: SMTP-portit ja WordPress-sähköposti

1. Mikä on yksinkertainen vastaus: mitä SMTP-porttia käytän?

Käytä porttia 587 ja STARTTLS-salausta. Jos se ei toimi, seuraava paras valinta on portti 465 ja SMTPS (SSL/TLS).

2. Miksi en saisi käyttää porttia 25?

Portti 25 on alkuperäinen, salaamaton SMTP-portti vuodelta 1982. Sitä väärinkäytettiin laajasti roskapostiin, minkä takia lähes kaikki kuluttaja-ISP:t ja monet cloud hosting -ympäristöt blokkaavat sen. Se ei käytännössä toimi sivuston lähetykseen.

3. Mitä eroa on portilla 587 (STARTTLS) ja portilla 465 (SMTPS)?

Molemmat ovat turvallisia. Portti 465 käyttää implicit TLS:ää, eli suojattu yhteys alkaa heti. Portti 587 käyttää explicit TLS:ää (STARTTLS-komento), eli yhteys aloitetaan ja sitten “päivitetään” TLS:ään. Portti 587 on moderni suositusstandardi, mutta kumpikin on toimiva.

4. Mitä tarkoittaa transactional email?

Se on 1:1-viesti, joka laukeaa käyttäjän toiminnasta sivustolla: yhteydenottolomakkeen lähetys, salasanan palautus, uuden käyttäjän rekisteröinti tai verkkokaupan tilausvahvistus. Nämä kannattaa lähettää dedikoidun SMTP-/API-palvelun kautta.

5. Miten transactional email eroaa marketing emailista?

Marketing email on 1:many-lähetys, kuten uutiskirje tai kampanjailmoitus. Näihin kuuluu käyttää erillistä ESP-alustaa, jotta et vahingoita domainin lähetysreputaatiota – muuten myös transaktioviestit alkavat mennä roskapostiin.

6. Mitä SPF ja DKIM ovat, ja tarvitsenko niitä oikeasti?

Kyllä – käytännössä ehdottomasti. Ne ovat DNS-tietueita, joilla todistat viestien olevan aitoja. SPF on lista palvelimista, joilla on lupa lähettää domainisi nimissä. DKIM on digitaalinen allekirjoitus, jolla vastaanottaja varmistaa, ettei viestiä ole muutettu matkalla. Ilman näitä viestit näyttävät herkästi roskapostilta.

7. SMTP-lisäosa kysyy “Host”-kenttää – mikä se on?

“Host” on SMTP-palveluntarjoajan postipalvelimen osoite. Esimerkiksi SendGridillä se on smtp.sendgrid.net ja Googlella smtp.gmail.com. Palveluntarjoaja antaa tarkan arvon dokumentaatiossa/ohjeissa.

8. Voinko käyttää tavallista Gmail-tiliä sivuston sähköpostien lähetykseen?

Teknisesti kyllä, mutta se ei ole suositeltavaa. Joudut tuomaan henkilökohtaisia tunnuksia WordPress-hallintaan (tietoturvariski), ja Googlella on tiukat lähetysrajat. Liikennepiikki voi aiheuttaa sen, että Google estää lähetykset väliaikaisesti. Dedikoitu transactional-palvelu on yleensä parempi valinta.

9. Mikä on helpoin tapa korjata kaikki WordPress-sähköpostiongelmat?

Helpoin tapa on käyttää “zero-configuration” -lisäosaa kuten Site Mailer by Elementor, joka reitittää transaktioviestit toimitusvarman palvelun kautta ilman porttien, API-avainten tai kolmannen osapuolen tilien säätöä.

10. Miten testaan, toimiiko SMTP-asetus?

Hyvissä SMTP-lisäosissa (esim. WP Mail SMTP) on “Test Email” -välilehti. Lähetä testiviesti WordPress-hallinnasta omaan sähköpostiin. Jos viesti tulee inboxiin, perusasiat ovat kunnossa.