WordPress ja sähköpostiongelmat on tuttu homma melkolailla jokaiselle joka on jaettuun webhotelliin sivunsa joskus perustanut. Postit joko hukkuu matkalla, tai menee määränpäässään kaikessa hiljaisuudessa suoraan spämmikansioon, eikä vastaanottaja saa ehkä ikinä tietää, ellei satu kaivelemalla kaivelemaan.
Huonot uutiset on että tätä ei oikein voi välttää - WordPress ei tule olemaan luotettava sähköpostin kanssa suoraan asennuksesta koskaan. Hyvät uutiset? Asia on ratkaistavissa ja vieläpä nykyään todella helposti.
Tässä artikkelissa käsittelemme aihetta WordPress ja Transactional mail. Transactional mail tarkoittaa toiminnallisia sähköposteja, kuten tilausvahvistuksia, salasanapalautuksia, ja sen sellaisia. Se ei tarkoita esim. massaposteja ja markkinointia. Niistä on tulossa toinen artikkeli hieman myöhemmin.
HUOM! Jos sinua ei varsinaisesti kiinnosta mistä kaikki johtuu, ja haluat skipata suoraan ratkaisuun, klikkaa tästä.
Lähettäjämaine ja jaetut webhotellit
Roskapostiongelman takia sähköpostimaailma on muuttunut huomattavasti internetin alkumetreiltä. Nykyään meillä on (onneksemme) melkoinen määrä erilaisia suojakerroksia roskapostia vastaan. Emme ole enää pelkän sähköpostin sisäisen suodattimen varassa, vaan sen lisäksi vaakakupissa painaa esimerkiksi lähettävän palvelimen lähettäjämaine. Tämä tarkoittaa että roskapostin lähettäjä tunnistetaan roskapostin lähettäjäksi, maine kärsii ja postit lakkaa kulkemasta. Jaetuissa palvelimissa, eli webhotelleissa, kaikki palvelimelta postia lähettämään kykenevät jakavat saman lähettäjämaineen, eli kun yksi temppuilee niin kaikki kärsii. Hostingspellin artikkelin mukaan 19% kaikesta suostumusperusteisesta sähköpostista jää toimittamatta. Siitä noin 7% jää spämmikansioon, ja 12% katoaa matkalla kokonaan bittiavaruuteen.
Edellä mainitusta syystä moni palveluntarjoaja onkin kieltänyt webhotellin sähköpostien käytön esimerkiksi uutiskirje- tai markkinointitarkoituksissa kokonaan, ja saattaa sulkea koko asiakkuuden mikäli niin silti tapahtuu. Samalla palvelut joissa tuota ei ole kielletty tai erikseen seurata todennäköisesti on jo lähettäjämaineeltaan sellaisia ettei tarvitse elätellä toivoa postin perille kulkemisesta. Hyvä nyrkkisääntö onkin että verkkosivun palvelin ei ole mikään sähköpostipalvelin, vaan ne on syytä pitää erillään. Samasta syystä yrityksen pääsähköpostin tulisi olla toiminta- ja kuljetusvarma yrityspaketti kuten Google Workspace tai Microsoft 365 / Outlook eikä jaetun webhotellin mukana tuleva laatikko. Liian monet aloittavat pienyritykset säästävät tässä tajuamatta että se on sama kuin ei käyttäisi sähköpostia lähettämiseen lainkaan, ja ihmettelevät sitten kun kukaan ei vastaa.
Jaetun vastuun malli, case Amazon
Lähettäjämaine ja siitä huolehtiminen korostuu jos päättää tutustua aiheeseen, ja joko yrittää ylläpitää omaa sähköpostipalvelinta ja sen mainetta, tai avaa tilin jaetun vastuun mallia käyttävään palveluun, kuten Amazonin SES (Simple Email Service) palveluun. Amazon on tunnettu edullisista webpalveluistaan (sen ison verkkokaupan lisäksi) ja Amazonin edullisuus perustuukin siihen että käyttäjien oletetaan tietävän mitä tekevät. Ihanneasiakas ei Amazonilla asiakaspalvelua kuormita, vaan korjaa itse jos ongelmia tulee.
Amazon SES-palvelun kojelaudasta näkee palvelimen maineen, ja Amazon kertoo selvästi että jos yli 5% lähetetyistä sähköposteista "pomppaa takaisin" (bounce) eli ei tavoita vastaanottajaa, on lähettäjätili vaarassa joutua hyllytetyksi kokonaan. Tämän takia palvelun käyttäjä joutuu itse askartelemaan itselleen automaatiot palveluun huolehtimaan että esim. väärin kirjoitetut osoitteet saadaan nopeasti karsittua pois lähetyslistoilta, ja ylipäätään pitämään huolta että niitä ei sinne liikaaa ilmesty alunperinkään esim. tarkistamalla osoitteet automaatiolla tai käsin ennen listalle päätymistä. Samoin laadun on syytä olla kunnossa, sillä valitusten odotetaan pysyvän 0.1% alapuolella, ja 0.5% valitusten kohdalla uhkaa jälleen koko tilin hyllytys.
Olen itse käyttänyt Amazon SES-palvelua vuosia, ja ollut siihen erittäin tyytyväinen. Askartelua ja huolehtimista siinä kuitenkin on sen verran että se ei ole ihan ensimmäinen valinta pienen budjetin asiakastöihin, vaan alkaa lähinnä "maksaa itseään takaisin" vasta isoilla volyymeilla, sillä Amazonin lähetyskohtainen hinta pysyy todella maltillisena vielä miljoonissakin päivittäisissä lähetyksissä.
Jos yrityksellä ei ole Amazonin palveluita ymmärtävää henkilöstöä talossa, tai ylläpitoa ulkoistettuna, on huomattavasti fiksumpi ratkaisu ottaa käyttöön täysin ylläpidetty palvelu, kuten Sendinblue tai Mailchimpin Mandrill. Wildcard Group Oy tietysti Sendinblue Partnerina suosittelee Sendinblueta.
WordPress PHPMailer ja SMTP
WordPress käyttää oletuksena sähköpostin lähettämiseen PHPMaileria. PHPMailer on koodikirjasto joka mahdollistaa sähköpostin lähettämisen suoraan palvelimelta ilman varsinaista sähköpostiosoitetta. Kuten aiemmin todettu, tämä on harvoin hyvä idea, ja pääsääntöisesti tarkoittaa että posti ei kulje, tai jos kulkee niin roskapostikansioon.
WordPressissä kannattaa ehdottomasti ottaa käyttöön kunnollinen SMTP-posti.
Simple Mail Transfer Protocol, tuttavallisemmin SMTP
SMTP-postin käyttö on jo huomattava askel eteenpäin, mutta ei itsessään vielä takaa esteetöntä postin kulkua. SMTP-postiksi lukeutuu esimerkiksi webhotellien postit, mutta myös samaa protokollaa käyttävät välityspalvelut kuten Amazon SES, Sendinblue, Sendgrid, Mandrill.
Mikäli verkkosivun ei tarvitse lähettää tuntemattomiin osoitteisiin minkäänlaista postia (esim. tilausvahvistuksia, kirjeitä, mitään) vaan riittää että omaan postiin tulee mahdolliset asiakkaan täyttämät lomakevastaukset ja omat salasanaresetoinnit niin tähän tarkoitukseen riittää hyvin webhotellin oma SMTP-posti, mutta kun verkkosivun pitäisi pystyä kommunikoimaan asiakkaidesi kanssa, esimerkiksi lähettämällä tilausvahvistuksia, on syytä ottaa käyttöön kunnollinen sähköpostipalvelu. Teknisesti tähän olisi mahdollista valjastaa myös Gmail tai Outlook, mutta niitä ei ole siihen tarkoitettu eikä niitä siihen suositella.
DNS / Varmennetietueet
Sähköpostin kulkemiseen liittyy olennaisesti myös liuta erilaisia DNS-tietueita (Domain Name System) joilla on jokaisella oma paikkansa sujuvassa postinkulussa. Eri sähköpostipalveluilla voi olla hieman toisistaan poikkeavia tapoja hyödyntää näitä tietueita, tai olla hyödyntämättä, joten jos valitsemasi sähköpostipalvelun ohjeista puuttuu osa, tai on jotain mitä ei tässä mainita, ei siitä kannata hämmentyä sen enempää.
MX, SPF, DKIM, DMARC
MX-tietue (Mail Exchanger record) on eräänlainen resurssitietue DNS-järjestelmässä (Domain Name System). Se määrittää sähköpostin toimitusprotokollan verkkotunnuksellesi. MX-tietue kuvaa verkkotunnuksen nimen yhdelle tai useammalle sähköpostipalvelimelle, jotka käsittelevät kyseisen verkkotunnuksen saapuvat sähköpostit.
SPF-tietue taas (Sender Policy Framework) on eräänlainen turvallisuustietue DNS-järjestelmässä. Se määrittää, mitkä palvelimet ovat sallittuja lähettimiksi verkkotunnukselle.
DKIM-tietue (DomainKeys Identified Mail) on eräänlainen turvallisuustietue DNS-järjestelmässä. Se määrittää, mitkä palvelimet ovat sallittuja lukemaan ja vahvistamaan verkkotunnuksen saapuvat sähköpostit
DMARC-tietue (Domain-based Message Authentication, Reporting and Conformance) on eräänlainen suojaustietue DNS-järjestelmässä. Siinä määritetään, miten saapuvat sähköpostiviestit on todennettava ja mitä tehdään sähköpostiviesteille, joiden todennus ei onnistu.
Eli koko artikkeli tähän asti tiivistettynä:
WordPress käyttää oletusarvoisesti PHPMaileria sähköpostien lähettämiseen, mutta on suositeltavaa käyttää SMTP-postia luotettavuuden parantamiseksi. Asianmukaisen sähköpostivirran varmistamiseksi kannattaa myös asettaa tarvittavat DNS-tietueet, kuten MX, SPF, DKIM ja DMARC.
Ratkaisu(t) (aloita lukeminen tästä jos vain nopea ratkaisu kiinnostaa)
1) SMTP-postin käyttöönotto Sendinblue-ekspertin avulla (se parempi ja helpompi ratkaisu)
A) Ota yhteyttä wildcard.fi-lomakkeella, sähköpostitse tai vaikka LinkedIn-viestillä ja kerro että haluat saada WordPressisi sähköpostit kulkemaan.
B) Avaa Sendinblue-tili täältä ja sen jälkeen lisää näillä yksinkertaisilla ohjeilla [email protected] Sendiblue-partneriksesi.
C) Tarvitsemme tämän lisäksi pääsyn DNS-tietueisiisi jotta saamme lisättyä palvelun vaatimat tietueet, luotua varmennetun sähköpostilähettäjän, ja kytkettyä sen WordPress-asennukseesi.
Valmis. Posti kulkee.
2) Tee-se-itse-malli (jos opiskelu ja kokeilu kiinnostaa)
A) Avaa Sendinblue-tili täällä.
B) Lisää Domainisi Sendinblue-palveluun.
C) Luo Sendinbluessa DNS-tietueet (domain verification, DKIM, SPF)
D) Lisää tietueet oman domainisi DNS-hallintaan, mutta varovasti, sillä esim. SPF-tietueita voi olla vain yksi, johon tulee sisällyttää kaikki tarvittavat. Jos domainilla on muita SPF-tietuetta vaativia palveluita, kuten Outlookia, Google Workspacea, muita SMTP-postilaatikoita tai vastaavia, ei vanhaa tietuetta korvata uudella, vaan sitä muokataan sisältämään uusi muiden mukana.
E) Luo Sendinbluessa lähettäjä (Sender) verkkosivua varten.
F) Asenna WordPressiin FluentSMTP (muitakin SMTP-lisäosia on, mutta tämä on toimiva, helppokäyttöinen, ja tässä on mm. viestiloki oletuksena käytössä, eikä maksumuurin takana).
G) Aseta FluentSMTP:ssä käyttöön Sendinbluessa luotu lähettäjätili. Tarkista että oikea salaus on valittuna, ja portit oikein.
H) Testaa postin kulkeminen Test email-toiminnolla FluentSMTP:ssä.
