Sähköpostien lähettäminen sovelluksestasi (ja saapuminen postilaatikkoon)

Jotta sovelluksesi sähköpostit menevät perille luotettavasti, käytä sähköpostin lähetyspalvelua omasta postilaatikosta riippumatta, lähetä omalta domainiltasi ja lisää palveluntarjoajan antamat DNS-tietueet, jotta SPF, DKIM ja DMARC kaikki läpäisevät. Pidä transaktioviestit — salasanan palautukset, kuitit, vahvistukset — erillään markkinointiviesteistä, lähetä kumpaakin vain ihmisille, jotka sitä odottavat, ja hoida palautuneet viestit ja tilausten peruutukset. Hoida todennus ensin: se on yleisin syy siihen, että sovelluksen sähköpostit päätyvät roskapostiin.

Transaktioviesti vs. markkinointiviesti

Nämä kaksi sähköpostityyppiä näyttävät koodissa samalta, mutta postilaatikkopalvelut ja lait käsittelevät niitä hyvin eri tavoin.

Pidä ne erillään. Jos markkinointikampanja saa roskapostivalituksia, et halua, että salasanan palautukset samasta virrasta kärsivät siitä. Yleinen tapa on erilliset alidomainit — esimerkiksi mail.example.com tilien sähköposteille ja news.example.com uutiskirjeille — ja osa palveluntarjoajista erottaa ne myös sisäisesti. Postmark esimerkiksi kuvaa transaktio- ja lähetysviestivirtojaan erillisellä lähetysinfrastruktuurilla syyskuusta 2026 alkaen.

Palveluntarjoajan valinta

Sovelluksesi ei saa lähettää sähköpostia itse omalta palvelimeltaan. Lähetyspalvelut hoitavat infrastruktuurin, IP-maineen, uudelleenyritykset ja palautuneiden viestien käsittelyn. Tunnettuja vaihtoehtoja ovat Postmark, Resend, SendGrid, Amazon SES ja Mailgun. Kullakin on HTTP-rajapinta ja SMTP-yhteys, ja hinnat ja paketit muuttuvat, joten vertaa niitä niiden omilta sivuilta.

Vertailtavaa:

• Painopiste. Osa palveluista keskittyy transaktioviesteihin, toiset yhdistävät transaktio- ja markkinointiviestit.
• Kehittäjäkokemus. Selkeä rajapinta, virallisia kirjastoja kielellesi ja hyödyllisiä lokeja, jotka näyttävät, toimitettiinko, palautuiko vai merkittiinkö viesti roskapostiksi.
• Webhookit palautuneille viesteille, valituksille ja toimituksille, jotta sovelluksesi voi reagoida.
• Mallipohjat — palveluntarjoajan tallentamina tai omassa koodissasi. Koodissa säilytetyt pohjat ovat versioitavia ja testattavia.
• Alue ja tietojenkäsittely, jos sinulla on vaatimuksia siitä, missä tietoja käsitellään.
• Hinta sinun määrälläsi, mukaan lukien se, mitä tapahtuu, kun ylität ilmaisen tason.

Uutiskirjeisiin listalle dedikoitu uutiskirje- tai sähköpostimarkkinointityökalu sopii usein paremmin kuin kampanjaominaisuuksien rakentaminen sovellukseesi.

Määritä lähetysdomain

Lähetä omalta domainiltasi — hello@example.com, ei Gmail- tai Outlook-osoitteesta. Ilmaisesta postilaatikosta kolmannen osapuolen palvelun kautta lähetetty posti epäonnistuu todennustarkistuksissa ja suodatetaan todennäköisesti.

Harkitse alidomainia pelkästään lähettämiseen. Resend suosittelee esimerkiksi lähettämistä alidomaineista kuten updates.example.com lähetysmaineen eristämiseksi (syyskuusta 2026 alkaen). Se pitää myös sähköpostin DNS-tietueet erillään pääsivustosi tietueista.

Palveluntarjoaja antaa sitten DNS-tietueet lisättäväksi siihen paikkaan, jossa domainisi DNS hallitaan. Jos DNS on sinulle uutta, miten domainit ja DNS toimivat selittää tietueet ensin.

SPF

SPF (Sender Policy Framework) on TXT-tietue, joka listaa palvelimet, joilla saa lähettää sähköpostia domainillesi. Vastaanottaja tarkistaa, onko lähettävä palvelin listalla.

• Domainilla pitäisi olla vain yksi SPF-tietue. Kun lisäät palveluntarjoajan, yhdistä se olemassa olevaan tietueeseen sen sijaan, että lisäisit toisen.
• SPF sallii arvioinnissa enintään 10 DNS-hakua; pitkät include:-ketjut voivat ylittää rajan ja aiheuttaa virheitä.
• Monet palveluntarjoajat asettavat SPF:n palautusosoitteen alidomainille, jonka he pyytävät sinua luomaan, joten pääsi SPF-tietueeseen ei välttämättä koske lainkaan.

DKIM

DKIM (DomainKeys Identified Mail) lisää jokaiseen viestiin kryptografisen allekirjoituksen. Palveluntarjoaja allekirjoittaa yksityisellä avaimella, ja sinä julkaiset vastaavan julkisen avaimen DNS-tietueena (TXT tai CNAME palveluntarjoajasta riippuen). Vastaanottajat tarkistavat allekirjoituksen varmistaakseen, että viesti tuli valtuutetulta lähettäjältä eikä sitä ole muutettu matkalla.

DKIM on suurimmaksi osaksi palveluntarjoajan "vahvista domain" -vaiheen asia. Älä ohita sitä.

DMARC

DMARC yhdistää muut kaksi. Se on TXT-tietue osoitteessa _dmarc.yourdomain.com, joka kertoo vastaanottajille:

• Linjaus: näkyvässä From-osoitteessa oleva domain täytyy vastata domainia, joka läpäisi SPF:n tai DKIM:n.
• Käytäntö: mitä tehdä viesteille, jotka epäonnistuvat — p=none (vain raportoi), p=quarantine (käsittele epäilyttävänä, usein roskapostina) tai p=reject.
• Raportit: mihin osoitteeseen lähetetään yhteenvetoraportit (rua=), jotta näet, kuka lähettää domainisi nimissä.

Järkevä polku on aloittaa p=none:lla ja raportointiosoitteella, varmistaa että laillinen posti läpäisee, siirtyä sitten quarantine-tilaan ja lopulta reject-tilaan. Tiukka käytäntö tekee myös muiden väärennettyjen lähetysten tekemisen huomattavasti vaikeammaksi.

Mitä Gmail vaatii

Syyskuusta 2026 alkaen Googlen lähettäjäohjeet sanovat:

• Kaikki lähettäjät henkilökohtaisiin Gmail-tileihin tarvitsevat SPF:n tai DKIM:n, toimivat käänteiset ja eteenpäin suuntautuvat DNS-tiedot lähettäville palvelimille, TLS:n sekä roskapostiosuuden alle 0,3 % Postmaster Toolsissa.
• Massalähettäjät (yli 5 000 viestiä päivässä Gmailiin) tarvitsevat SPF:n ja DKIM:n, DMARC-tietueen (p=none-käytäntö on sallittu), From-domainin linjauksen sekä yhden napsautuksen peruutuksen ja näkyvän peruutuslinkin markkinointi- ja tilausviesteihin.

Palveluntarjoajasi hoitaa palvelinpuolen osat. DNS-tietueet ja peruutusten käsittely ovat sinun vastuullasi. Vaikka lähettäisit selvästi alle 5 000 päivässä, massalähettäjien säännöt täyttämällä pysyt turvallisella puolella.

Rakenna lähettäminen sovellukseesi

Kun domain on vahvistettu:

1. Tallenna API-avain palvelinpuolen salaisuutena — ei koskaan etupään koodissa. Katso mitä ympäristömuuttujat ja salaisuudet ovat.
2. Lähetä palvelimelta, kun viestiä laukaiseva toiminto on onnistunut.
3. Älä pakota käyttäjää odottamaan sähköpostia. Kaikelle muulle kuin yksinkertaisimmalle sovellukselle lisää lähetys jonoon ja yritä uudelleen tilapäisissä virheissä, jotta hidas palveluntarjoaja ei hidasta rekisteröitymistä.
4. Kirjaa tulos — palveluntarjoajan viestitunnus ja tila — kirjaamatta avainta tai koko viestin sisältöä, jossa on henkilötietoja.
5. Käsittele webhookit palautuneille viesteille ja valituksille: lopeta lähettäminen osoitteisiin, jotka palautuvat pysyvästi tai joista saat roskapostivalituksen.

Perusasiat kattava kehote:

Lähetä transaktioviestit palveluntarjoajalla [PROVIDER] palvelimen salaisuudella [ENV_NAME], lähettäjänä "Acme hello@mail.acme.com". Lähetä tervetuloviesti rekisteröitymisen jälkeen ja varausvahvistus, kun varaus on tallennettu. Pidä mallipohjat koodissa, ja tekstiversio HTML:n rinnalla. Jonota lähetykset ja yritä tilapäisiä virheitä uudelleen enintään kolme kertaa. Kirjaa virheet palveluntarjoajan virheilmoituksella, mutta älä koskaan API-avainta. Lisää webhook-päätepiste, joka merkitsee osoitteet toimittamattomiksi pysyvissä palautuksissa ja valituksissa, ja ohita nämä osoitteet jatkossa.

Tilien sähköpostit — vahvistuslinkit, kirjautumislinkit ja salasanan palautukset — ovat osa kirjautumista. Miten lisäät kirjautumisen sovellukseesi kertoo, miten nämä virrat liittyvät toisiinsa; tee näistä linkeistä kertakäyttöisiä ja lyhytikäisiä.

Toimitettavuuden tavat

Todennus saa postisi harkittavaksi. Käyttäytyminen pitää sen postilaatikossa.

• Lähetä vain sitä, mitä ihmiset odottavat. Vahvistetut rekisteröitymiset, selkeä lupa markkinointiin, ei ostettuja listoja.
• Tee peruuttamisesta helppoa kaikessa, mikä ei ole ehdottomasti transaktioviesti, ja kunnioita sitä heti.
• Lämmitä uudet domainit. Täysin uusi domain, joka lähettää tuhansia viestejä ensimmäisenä päivänä, näyttää epäilyttävältä. Aloita transaktioviesteillä ja kasvata määrää vähitellen.
• Pidä listat puhtaina. Poista pysyvästi palautuneet osoitteet heti ja harkitse pitkään avaamattomien osoitteiden poistamista.
• Kirjoita kuin ihminen. Selkeä aihe, tunnistettava lähettäjän nimi, tekstiosa, vähän kuvia ja linkkejä omaan domainiisi. Vältä linkkien lyhentäjiä.
• Seuraa. Rekisteröi domainisi Google Postmaster Toolsiin ja lue DMARC-raportteja silloin tällöin.
• Käytä oikeaa vastausosoitetta, jonka joku lukee. Vastaukset ovat hyvä signaali ja hyödyllistä palautetta.

Testaa tekemättä roskapostia kenellekään

• Käytä palveluntarjoajasi testitilaa tai hiekkalaatikkoa, jos sellainen on, tai lähetä osoitteisiin, jotka omistat.
• Kehityksessä lähetä kaiken vastaanottavaan testilaatikkoon oikeiden käyttäjien sijaan. Täynnä oikealta näyttäviä osoitteita oleva kanta on helppo tapa lähettää viestejä vahingossa vieraille.
• Tarkista jokainen mallipohja muutamassa asiakasohjelmassa — Gmail selaimessa, puhelimen postisovellus, Outlook — sekä tummassa teemassa.
• Katso testiviestin otsikot: ne näyttävät, läpäisivätkö SPF, DKIM ja DMARC.

Lakiasiat

Säännöt vaihtelevat maittain. Yleisesti ottaen markkinointiviesti vaatii monissa paikoissa suostumuksen, täytyy tunnistaa lähettäjä ja tarjota toimiva peruutusmahdollisuus. Transaktioviestit kohdellaan eri tavalla, mutta niitä ei pidä käyttää markkinoinnin ujuttamiseen. Jos keräät osoitteita odotuslistasivulta, kerro, mitä lähetät ja tallennat ja milloin ja miten jokainen henkilö liittyi. Jos epäilet, tarkista säännöt maassa, jossa käyttäjäsi ovat.

Sähköpostitarkistuslista

• Lähetyspalveluntarjoaja valittu; API-avain tallennettu palvelimen salaisuutena
• Lähetys omalta domainilta tai alidomainilta, ei ilmaisesta postilaatikosta
• SPF-, DKIM- ja DMARC-tietueet lisätty ja läpäisevät
• Transaktio- ja markkinointiposti erillään
• Lähetykset jonotettu ja uudelleenyritetty; tulokset kirjattu
• Palautusten ja valitusten webhookit käsitelty
• Peruutus muussa kuin transaktioviestissä, ja se kunnioitetaan heti
• Mallipohjat testattu useissa asiakasohjelmissa; testiposti ei koskaan tavoita oikeita käyttäjiä

Sähköpostin lähettäminen Mythex-sovelluksesta

Mythex ei sisällä sisäänrakennettua sähköpostipalvelua rakentamillesi sovelluksille, joten tuot oman palveluntarjoajan, kuten Resendin, SendGridin tai Postmarkin. Tallenna sen API-avain projektin salaisuutena — agentti voi pyytää sitä chatin salaisuuskortilla — ja pyydä tarvitsemasi viestit tavallisin sanoin. Dokumentaatiossa on aloituskehote kohdassa lähetä sähköposti sovelluksestasi. Jos ostit domainin Mythexin kautta Pro-tasolla, voit lisätä palveluntarjoajan TXT- ja CNAME-tietueet domainin DNS-asetuksiin; katso mukautetut domainit.

Kysymykset