Sähköposti verkkosivustoltasi ja lomakkeista

Moduuli 7: Uutiskirjeet ja sähköposti verkkosivustolta · Lukuaika: 11 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat asettaa verkkosivuston sähköpostit (yhteydenottolomakkeet, tilausvahvistukset, WordPress-ilmoitukset) niin, että ne tulevat perille, eivät aiheuta DMARC-ongelmia eivätkä altista pakettiasi väärinkäytölle.

Keskeiset käsitteet: PHP mail(), SMTP kirjautumisella, envelope sender, From vs. Reply-To, kävijän osoite ei koskaan From-kenttään, SMTP-lisäosa, transaktiosähköposti, lomakespammi, captcha, honeypot, lähetysraja, paikallinen toimitus kun MX osoittaa muualle

Verkkosivustosi on myös sähköpostiohjelma

Verkkosivustosi lähettää enemmän sähköpostia kuin luulet. Yhteydenottolomake lähettää sinulle jokaisen viestin. Verkkokauppa lähettää tilausvahvistuksia, laskuja ja toimitusilmoituksia. WordPress lähettää sähköpostia uudesta kommentista, päivityksestä tai salasanan nollauksesta. Vastaanottajalle se on tavallista postia domeenistasi, ja se tarkistetaan yhtä tiukasti kuin postilaatikostasi lähtevä posti: SPF, DKIM, DMARC, maine.

Silti verkkosivuston sähköposti menee pieleen useammin kuin tavallinen sähköposti. Syynä on yleensä yksi kolmesta asiasta: lähetystapa, lähettäjän osoite tai lomakkeen väärinkäyttö.

Tapa 1: PHP mail()

Yksinkertaisin tapa verkkosivustolle lähettää sähköpostia on PHP-funktio mail(). Sivusto antaa viestin tällöin suoraan verkkopalvelimen sähköpostiohjelmalle kirjautumatta sisään. Se toimii yleensä, mutta siinä on haittapuolia:

• Envelope sender (Return-Path) on usein pakettisi järjestelmätili, kuten kayttaja@server.hosting.example, ei omaa osoitettasi. SPF tarkistetaan tällöin palvelimen domeenille, eikä se ole linjassa From-domeenisi kanssa (oppitunti 7.1).
• Tuleeko mukaan DKIM-allekirjoitus domeenistasi, riippuu palvelimesta. Joillakin palvelimilla kyllä, toisilla ei.
• Et näe mitään takaisin. Jos viesti ei tule perille tai saat bouncen, se menee järjestelmätilille, jota kukaan ei katso.
• Ei lomakekohtaista rajaa. Jos lomaketta väärinkäytetään, palvelin lähettää viestejä sinun nimissäsi, kunnes pakettisi raja täyttyy.

Tapa 2: SMTP kirjautumisella (parempi)

Anna verkkosivustosi lähettää samaan tapaan kuin sähköpostiohjelmasi tekee: kirjaudu lähtevän postin palvelimelle oikealla postilaatikolla, portin 587 (STARTTLS) tai 465 (SSL/TLS) kautta, käyttäjätunnuksena koko sähköpostiosoite (oppitunti 1.4 ja 2.1). Tällöin:

• envelope sender on oma osoitteesi ja viesti allekirjoitetaan kuten domeenisi tavallinen posti;
• bouncet tulevat postilaatikkoon, jota voit lukea;
• lähetetty viesti näkyy halutessasi Sent-kansiossa;
• voit asettaa postilaatikkokohtaisen lähetysrajan.

WordPressissä tämä tehdään SMTP-lisäosalla. Se korvaa WordPressin oletussähköpostitoiminnon lähetyksellä SMTP:n kautta. Täytät samat tiedot kuin sähköpostiohjelmassa: palvelin, portti, suojaus, käyttäjätunnus ja salasana. Luo tätä varten mieluiten erillinen postilaatikko, esimerkiksi website@example.com. Jos salasana joskus varastetaan, oma postilaatikkosi pysyy turvassa, ja näet heti mikä posti tulee sivustolta.

Omalle PHP-sivustolle on kirjastoja, jotka lähettävät SMTP:n kautta, kuten PHPMailer. Laita salasana asetustiedostoon verkkokansion ulkopuolelle, älä sivun koodiin.

WebOké:llä SMTP-tiedot löytyvät DirectAdmin-ohjeesta 8.1, pakettisi palvelimen nimellä; muilla tarjoajilla ne löytyvät ohjeesta tai tervetuliaisviestistä, ja toimintatapa on samankaltainen.

Paljon transaktiosähköpostia? Käytä palvelua

Jos lähetät satoja tilausvahvistuksia päivässä, kannattaa käyttää transaktiopalvelua: automaattisen postin lähetyspalvelua. Sillä on hyvä maine, ja se näyttää mitä kullekin viestille tapahtui. Liität domeenin samaan tapaan kuin uutiskirjepalvelun kanssa (DKIM CNAME:n kautta, oppitunti 7.1). Pidä transaktiosähköposti ja uutiskirjeet erillään: epäonnistunut kampanja ei saa vaikuttaa tilausvahvistusviesteihisi.

Kultainen sääntö: kävijän osoite ei ole koskaan lähettäjä

Yhteydenottolomakkeessa houkuttelee lähettää viesti "kävijän nimissä". Silloin voit sähköpostiohjelmassasi klikata suoraan Vastaa. Se näyttää tältä:

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

Mutta palvelimesi ei saa lähettää postia domeenin example.net nimissä. Oletetaan, että domeenilla example.net on DMARC-käytäntö p=reject. Vastaanottava palvelin (sinun oma tai Gmailin, jos ohjaat postia eteenpäin) näkee viestin, jonka From on example.net, mutta joka ei läpäise domeenin example.net SPF:ää tai DKIM:ää, ja hylkää sen. Monilla suurilla maildomeeneilla on tiukka käytäntö: 8. marraskuuta 2026 tehdyssä tarkistuksessa muun muassa yahoo.com, aol.com, ziggo.nl ja kpnmail.nl käyttivät DMARC-käytäntöä p=reject, ja icloud.com, gmx.de ja web.de käytäntöä p=quarantine. Tällaisella osoitteella varustettu kävijä täyttää lomakkeesi, ja viesti ei koskaan tule sinulle tai se menee roskapostikansioon. Domeenit, joilla on p=none (kuten tällä hetkellä gmail.com ja hotmail.com), voivat kiristää käytäntöään milloin tahansa, ja Google kirjoittaa ohjeissaan nimenomaisesti, ettei Gmail-osoitteita saa jäljitellä From-kentässä. Älä siis koskaan luota siihen, että se menisi hyvin.

Oikea tapa:

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

Lähettäjä on oma osoitteesi, joten SPF, DKIM ja DMARC täsmäävät. Kävijän osoite on kentässä Reply-To. Kun klikkaat Vastaa, vastauksesi menee Pieterille. Useimmissa lomakelisäosissa tämä löytyy sähköpostiasetuksista: aseta kohtaan Lähettäjä (From) oman domeenisi kiinteä osoite, ja Reply-To-kenttään se kenttä, johon kävijä kirjoittaa oman osoitteensa.

Lomakkeiden suojaaminen väärinkäytöltä

Suojaamaton lomake löytyy ennemmin tai myöhemmin botteina. Parhaassa tapauksessa saat itse roskapostia. Pahimmassa tapauksessa sitä käytetään roskapostin lähettämiseen muille: jos lomakkeesi lähettää vahvistuksen "osoitteeseen, jonka kävijä syöttää", botti voi syöttää sinne minkä tahansa osoitteen maailmassa, omalla viestitekstillä. Silloin domeenisi lähettää roskapostia, mikä vaikuttaa maineeseesi (oppitunti 5.2).

Suojaus kerroksittain:

• Captcha tai näkymätön tarkistus (kuten reCAPTCHA tai Turnstile) pysäyttää useimmat botit.
• Honeypot: piilotettu kenttä, jota ihmiset eivät näe mutta botit täyttävät. Jos se on täytetty, viestiä ei lähetetä.
• Ei vapaata tekstiä kävijälle lähetettävässä vahvistuksessa, tai ei lainkaan vahvistusta annettuun osoitteeseen. Yksinkertainen ilmoitus "Kiitos, olemme vastaanottaneet viestisi" sivulla riittää.
• Postilaatikkokohtainen lähetysraja verkkosivuston postilaatikolle, pakettisi rajaa alempi.
• Ohjelmistojen päivittäminen. Vanhat lisäosat ovat tunnettu väärinkäytön reitti.

Huomaatko, että paketistasi lähtee yhtäkkiä paljon postia, tai saatko ilmoituksen päivärajan täyttymisestä, vaikka itse lähetät vähän postia? Vaihda silloin heti salasanat ja selvitä, mikä lomake tai skripti lähettää postia (oppitunti 3.4).

Posti on muualla, sivusto täällä

Yleinen sudenkuoppa: verkkosivustosi on yhdellä palveluntarjoajalla, postisi toisella (esimerkiksi Microsoft 365 tai Google Workspace). MX-tietueesi osoittaa tuohon toiseen palveluun. Mutta verkkopalvelin luulee yhä hoitavansa itse domeenisi postin, koska domeeni on myös sen omalla paketilla. Lomakkeesta tulevan postin osoitteeseen info@example.com se toimittaa tällöin paikallisesti, postilaatikkoon verkkopalvelimella, jota kukaan ei katso, tai se antaa virheen kuten 550 ... mailbox unavailable.

Ratkaisu on ilmoittaa verkkopalvelimen hallintapaneelissa, että posti hoidetaan muualla. WebOké:n DirectAdminissa tämä on MX Records -kohdan rastitus "Käytä tätä palvelinta sähköpostieni käsittelyyn" (Use this server to handle my e-mails) (poista käytöstä). Muissa paneeleissa on vastaavia asetuksia, kuten "sähköpostin reititys: ulkoinen" cPanelissa. Vielä parempi: lähetä sivustolta posti SMTP:n kautta postilaatikolla sillä palveluntarjoajalla, jolla postisi todella sijaitsee.

Yhteenveto

• Verkkosivuston postia tarkistetaan yhtä tiukasti kuin tavallista postia. Lähetä sivustolta SMTP:n kautta kirjautumalla, ei mail()-funktiolla.
• Käytä sivustolle erillistä postilaatikkoa, jolla on oma lähetysraja.
• Kävijän osoite kuuluu Reply-To-kenttään, ei koskaan From-kenttään. Muuten DMARC epäonnistuu, ja domeeneilla, joilla on p=reject (kuten yahoo.com, ziggo.nl, kpnmail.nl), viesti hylätään.
• Suojaa lomakkeet captchalla, honeypotilla ja ilman vapaata vahvistustekstiä annettuihin osoitteisiin.
• Jos postisi on toisella palveluntarjoajalla, kytke paikallinen toimitus pois verkkopalvelimelta tai lähetä SMTP:n kautta kyseisellä palvelulla.

Tietovisa

Tehtävä

Tehtävä O7.3: Verkkosivun sähköpostin läpikäynti. Täytä lomake omalla verkkosivustollasi käyttäen Gmail- tai Outlook.com-osoitetta lähettäjänä, ja tarkastele sinulle tulevan viestin otsikkorivejä. Vastaa tarkistuslistaan: mikä osoite on From-kentässä, onko kävijän osoite Reply-To-kentässä, mitä spf=, dkim= ja dmarc= kertovat Authentication-Results-rivillä, lähettääkö sivustosi SMTP:n vai mail()-funktion kautta, ja onko lomakkeessa captcha tai honeypot? Jos sinulla ei ole omaa verkkosivustoa, vastaa kysymyksiin tämän oppitunnin esimerkin perusteella. Saat sen jälkeen mallivastauksen.

Lue lisää

Näiden artikkelien vaiheet koskevat WebOkén paneeleita; muilla palveluntarjoajilla toimintatapa on vastaava.

• Verkkosivustosi yhteydenottolomake: lähetä kentät sähköpostitse ja estä roskaposti
• Miten saan PHP:n mail()-funktiolla oikean lähettäjän? SMTP
• Sähköpostin lähettäminen PHP:llä ei onnistu, MX-tietueet osoittavat muualle
• Sähköpostin lähetysraja
• Päivittäinen sähköpostiraja täynnä
• DirectAdmin-ohje 8.1: Kaikki asetukset yhdessä paikassa: palvelimet, portit ja suojaus
• DirectAdmin-ohje 5.10: Sähköposti Microsoft 365:ssä tai Google Workspacessa, verkkosivu WebOkéssa