Miksi tapahtumasähköpostin toimitus on eri peto

Markkinointisähköpostien ja tapahtumasähköpostien välillä on kriittinen ero, jonka monet kehittäjät ohittavat kun he alkavat ensimmäistä kertaa ajatella toimitettavuutta vakavasti. Markkinointisähköpostit — uutiskirjeet, mainoskampanjat, ilmoitukset — menevät tilaajille, jotka ovat antaneet suostumuksensa. Ne sietävät satunnaisia viiveitä ja jopa satunnaisia roskapostikansiosijoituksia. Jos uutiskirje menee roskapostiin 2 %:lle listastasi, se on valitettavaa mutta liiketoimintasi jatkuu.

Tapahtumasähköpostit ovat täysin erilaisia. Vahvistuslinkit, salasanan palautukset, ostovahvistukset, kaksivaiheisen todennuksen koodit, tilin turvahälytykset — nämä saapuvat kriittisillä hetkillä käyttäjän matkalla. Salasanan palautuksen meneminen roskapostiin tarkoittaa, että käyttäjäsi on lukittu ulos tililtään ja avaa todennäköisesti tukipyynnön tai, pahempaa, ei koskaan palaa. Vahvistussähköpostin meneminen roskapostiin tarkoittaa, ettei uusi käyttäjä voi viimeistellä rekisteröitymistä ja hankintasuppilossasi on hiljainen, näkymätön vuoto.

Ja silti tapahtumasähköpostit määritetään usein vähemmällä huolella kuin markkinointikampanjat. Monet kehittäjät käyttävät mitä tahansa sähköpostin lähetyskoodia, jonka heidän kehyksensä tarjoaa, konfiguroivat sen jaetulla SMTP-palvelimella, ottavat sen käyttöön, testaavat sen kerran omalla postilaatikollaan — jolla on anteliaat roskapostikynnykset — ja jatkavat eteenpäin. Ongelmat tulevat esiin vasta kun oikeat käyttäjät Gmailissa, Outlookissa tai Yahoossa raportoivat puuttuvista sähköposteista. Siihen mennessä ongelma on hiljaa epäonnistunut tuotannossa viikkoja.

SPF: sähköpostin todennuksen perusta

Sender Policy Framework (SPF) on DNS TXT -tietue lähettävässä verkkotunnuksessasi, joka kertoo maailmalle, mitkä postipalvelimet on valtuutettu lähettämään sähköpostia puolestasi. Kun Gmail vastaanottaa sähköpostin, jonka väitetään olevan osoitteesta [email protected], se suorittaa DNS-haun verkkotunnuksesi SPF-tietueelle. Jos sen palvelimen IP-osoite, joka todella lähetti sähköpostin, on listattu SPF-tietueessasi, sähköposti läpäisee SPF:n. Jos SPF-tietuetta ei ole lainkaan — tai lähettävää palvelinta ei ole listattu — sähköpostiin suhtaudutaan epäluulolla ennen kuin mitään sisällön arviointia edes alkaa.

SPF:n määrittäminen on suoraviivaista kun tiedät mitä teet. Lisää TXT-tietue verkkotunnuksesi DNS:ään. Arvo riippuu lähetyspalveluntarjoajastasi. Jos käytät SendGridiä: v=spf1 include:sendgrid.net ~all. Jos käytät AWS SES:ää: v=spf1 include:amazonses.com ~all. Jos käytät Mailgunia: v=spf1 include:mailgun.org ~all. Palveluntarjoajasi dokumentaatio antaa sinulle tarkan include-arvon. ~all-pääte on "pehmeä epäonnistuminen" — sähköpostit listaamattomilta palvelimilta merkitään mutta ei hylätä suoraan. Kun olet varma, että SPF-tietueesi on täydellinen ja oikea, voit päivittää arvoon -all (kova epäonnistuminen), joka ohjeistaa vastaanottavia palvelimia hylkäämään valtuuttamattoman postin kokonaan.

Yksi yleinen sudenkuoppa: 10 DNS-haun raja. SPF-tietueet, jotka ketjuttavat yhteen useita include:-direktiivejä, voivat ylittää tämän rajan, aiheuttaen SPF:n epäonnistumisen vaikka kaikki palvelimesi olisivat teknisesti listattuja. Käytä MXToolboxia tarkistaaksesi SPF-tietueesi — se merkitsee hakumäärän ongelmat selkeästi. Sen ymmärtäminen, kuinka SPF, DKIM ja DMARC liittyvät toisiinsa, käydään hyvin läpi SendGridin dokumentaatiossa aiheesta sähköpostin todennus.

DKIM: kryptografinen todiste siitä ettei sähköpostiasi peukaloitu

DomainKeys Identified Mail (DKIM) lisää kryptografisen allekirjoituksen jokaiseen lähettämääsi sähköpostiin. Allekirjoitus luodaan yksityisellä avaimella, jota lähetyspalveluntarjoajasi pitää, ja vastaanottavat postipalvelimet varmentavat sen julkista avainta vasten, jonka julkaiset DNS TXT -tietueena. Jos allekirjoitus täsmää, kaksi asiaa todistetaan: sähköposti on aidosti peräisin lähetysinfrastruktuuristasi, eikä sisältöä muokattu lähetyksen ja vastaanoton välillä.

Ilman DKIM:iä konfiguroituna pahantahtoisten toimijoiden on huomattavasti helpompi väärentää verkkotunnuksesi — lähettää sähköposteja, jotka näyttävät tulevan osoitteesta [email protected] mutta jotka joku aivan muu itse asiassa lähetti. Näin tietojenkalastelukampanjat toimivat. Roskapostisuodattimet tietävät tämän myös, minkä vuoksi sähköpostiin, josta puuttuu kelvollinen DKIM-allekirjoitus verkkotunnukselta jolla sellainen pitäisi olla, suhtaudutaan kohonneella epäluulolla. Spamhaus ja muut mainepalvelut ottavat DKIM-allekirjoitushistorian huomioon verkkotunnuksen mainepisteissä.

DKIM:n määrittäminen tehdään lähetyspalveluntarjoajasi kautta. He luovat avainparin, pitävät yksityisen avaimen infrastruktuurissaan ja antavat sinulle julkisen avaimen lisättäväksi DNS:ääsi TXT-tietueena. Kun tuo DNS-tietue on julkaistu ja levitetty, jokainen sähköposti jonka he lähettävät puolestasi kantaa kelvollisen DKIM-allekirjoituksen automaattisesti. Useimmat suuret palveluntarjoajat — SendGrid, Mailgun, Amazon SES, Postmark — opastavat sinut tämän prosessin läpi alkuasennuksen aikana. Jos ohitit sen, palaa takaisin ja konfiguroi se nyt.

DMARC: käytäntökerros joka sitoo sen yhteen

DMARC (Domain-based Message Authentication, Reporting, and Conformance) rakentuu SPF:n ja DKIM:n päälle määrittelemällä mitä vastaanottavien palvelinten tulisi tehdä kun sähköposti epäonnistuu näissä tarkistuksissa. Se tuo myös "kohdistuksen" — vaatien että sähköpostin From-otsakkeen verkkotunnus todella täsmää sen verkkotunnuksen kanssa, joka läpäisi SPF:n tai DKIM:n. Tämä estää hyökkääjiä läpäisemästä SPF-tarkistuksia yhdellä verkkotunnuksella samalla kun he väärentävät toista näkyvässä From-osoitteessa.

Oikea lähestymistapa DMARC:iin on aloittaa asteittain. Aloita pelkän valvonnan käytännöllä: v=DMARC1; p=none; rua=mailto:[email protected]. p=none kertoo vastaanottaville palvelimille, etteivät ne ryhdy toimiin epäonnistumisissa, vaan lähettävät sinulle vain raportteja. Nuo koostetut raportit kertovat sinulle, mitkä palvelimet lähettävät sähköpostia puolestasi ja läpäisevätkö ne SPF:n ja DKIM:n. Tarkastele niitä muutaman viikon ajan ennen minkään käytäntömuutoksen tekemistä.

Kun olet varma että kaikki laillinen läpäisee, siirry arvoon p=quarantine (epäonnistuneet sähköpostit menevät roskapostikansioon) ja lopulta arvoon p=reject (epäonnistuneet sähköpostit hylätään suoraan). Tämä eteneminen suojaa verkkotunnuksesi mainetta väärentämiseltä samalla kun se antaa sinulle aikaa napata mahdolliset lailliset sähköpostilähteet, jotka olet ehkä unohtanut. DMARC-käytäntö p=reject yhdistettynä läpäisevään SPF:ään ja DKIM:iin tekee hyökkääjille lähes mahdottomaksi esiintyä verkkotunnuksenasi tehokkaasti.

IP-maine: miksi lähettävällä palvelimellasi on merkitystä

Jopa täydellisen SPF:n, DKIM:n ja DMARC:n kanssa sähköpostisi voivat silti mennä roskapostiin, jos IP-osoitteella josta ne lähetetään on huono maine. Vastaanottavat postipalvelimet ylläpitävät — tai konsultoivat kolmannen osapuolen palveluita jotka ylläpitävät — estolistoja ja mainepisteitä lähettäville IP-osoitteille. IP-osoite, jolla on roskapostin lähettämisen historia, tai joka esiintyy estolistoilla joita ylläpitävät palvelut kuten Spamhaus, saa lähtevät sähköpostinsa kohdelluiksi epäluulolla riippumatta todennusasetuksistasi.

Jos käytät jaettua IP-osoitetta jaetulta hosting-palveluntarjoajalta tai halvalta SMTP-palvelulta, maineesi on sidottu kaikkiin muihin jotka käyttävät samaa IP:tä. Yksi roskapostittaja samassa jaetussa poolissa voi romahduttaa toimitettavuuden kaikille tuon IP:n lähettäjille. Tämä on yksi vahvimmista perusteista käyttää omistautunutta tapahtumasähköpostin palveluntarjoajaa — SendGrid, Amazon SES, Postmark, Mailgun — sen sijaan että lähettäisit sähköpostia suoraan sovelluspalvelimeltasi tai jaetun SMTP-palvelun kautta.

Uudella lähettävällä IP:llä sinun täytyy myös "lämmittää" IP asteittain. Äkillisen sähköpostivolyymipiikin lähettäminen tuoreelta IP:ltä näyttää roskapostikäyttäytymiseltä vastaanottaville palvelimille. Aloita pienemmillä volyymeilla ja lisää asteittain päivien tai viikkojen aikana. Useimmat omistautuneet sähköpostipalveluntarjoajat hoitavat IP:n lämmityksen automaattisesti jos olet jaetussa lähetyspoolissa, tai tarjoavat IP-lämmitysaikatauluja jos käytät omistettua IP:tä.

Sisältö ja aiherivi: mikä laukaisee suodattimet

Todennuksen ja IP-maineen lisäksi roskapostisuodattimet arvioivat itse sähköpostisi sisällön. Tietyt kuviot laukaisevat luotettavasti roskapostiluokituksen. Roskaposti-liipaisusanat aiherivillä — "ILMAINEN", "TAATTU", "TOIMI NYT", liialliset huutomerkit, ISOT KIRJAIMET — ovat ilmeisiä joita useimmat kehittäjät välttävät. Vähemmän ilmeistä: aiherivit jotka ovat liian epämääräisiä ("Tärkeä viesti sinulle"), liian kiireellisiä ("Tilisi suljetaan") tai liian mainosmaisia tapahtumasähköpostiksi tarkoitettuun.

Tekstin ja kuvan suhteella on myös merkitystä. Sähköposti joka on enimmäkseen kuvia minimaalisella tekstillä on klassinen roskapostikuvio — massapostittajat käyttävät kuvia hämärtääkseen avainsanat tekstipohjaisilta suodattimilta. Tapahtumasähköpostien tulisi olla ensisijaisesti tekstipohjaisia minimaalisilla kuvilla. Rikkinäinen HTML — sulkematon merkintä, virheelliset attribuutit — on toinen varoitusmerkki. Lähetä aina pelkkä tekstivaihtoehto HTML-versiosi rinnalla. Roskapostisuodattimet suhtautuvat pelkkiin HTML-sähköposteihin kohonneella epäluulolla, ja yritysten sähköpostijärjestelmät poistavat usein HTML:n kokonaan.

Sähköpostin toimituksen testaaminen — oikea tapa

Nopein ja käytännöllisin testausmenetelmä sähköpostin toimitukselle on: lähetä testisähköposti tuoreeseen temp mail -postilaatikkoon ja tarkista sekä saapuneet-kansio että roskapostikansio. Tämä antaa sinulle välittömän, yksiselitteisen palautteen siitä, saavuttaako sähköpostisi postilaatikon vai suodatetaanko se. Toisin kuin testaus omalla Gmail-tililläsi — jolla sinut on ehkä sallittu usein lähettäjänä — tuoreella väliaikaisella osoitteella ei ole aiempaa historiaa verkkotunnuksesi kanssa, mikä simuloi tarkemmin uuden käyttäjän ensikontaktikokemusta.

Sinun tulisi testata toimitus joka kerta kun muutat jotain, joka voisi vaikuttaa siihen: sähköpostipalveluntarjoajien vaihtaminen, HTML-mallipohjasi merkittävä päivittäminen, lähettävän verkkotunnuksesi muuttaminen, uuden lähettävän aliverkkotunnuksen lisääminen tai käyttöönotto uudessa ympäristössä (staging, tuotanto). Se vie kaksi minuuttia ja antaa sinulle lopullisen näytön. Vaihtoehto — käyttäjien odottaminen raportoimaan ongelmista — tarkoittaa, että toimitettavuusongelmasi ovat jo hiljaa epäonnistuneet tuntemattoman ajan.

Saapuneet/roskaposti-tarkistuksen lisäksi käytä MXToolboxin sähköpostin terveystarkistinta tarkistaaksesi verkkotunnuksesi yleisen terveyden: SPF, DKIM, DMARC, mustan listan tila ja MX-tietueen konfiguraatio kaikki yhdessä paikassa. Tee tästä osa esilaunkkilistaasi kaikille uusille sovelluksille tai lähettäville verkkotunnuksille. Tarkista myös OWASP-ohjeet turvallisuuteen liittyvistä sähköpostin parhaista käytännöistä.

Palautusluvut ja roskapostivalitukset: mittarit joilla on merkitystä

Kahdella mittarilla on suhteeton vaikutus pitkän aikavälin toimitettavuuteen: palautusluku ja roskapostivalitusluku. Yli 2 %:n palautusluku kertoo vastaanottaville palvelimille ja lähetyspalveluntarjoajallesi, että lähetät paljon virheellisiin tai olemattomiin osoitteisiin — mikä on ostettuihin sähköpostilistoihin ja roskapostioperaatioihin liittyvä kuvio. Vaikka tekisit kaiken muun oikein, korkea palautusluku aiheuttaa toimitettavuusongelmia. Poista kovat palautukset lähetyslistaltasi välittömästi ja pysyvästi.

Yli 0,1 %:n roskapostivalitusluku (yksi valitus tuhatta lähetettyä sähköpostia kohti) on kynnys, jolla useimmat lähetyspalveluntarjoajat alkavat rajoittaa tiliäsi. Gmailin Postmaster Tools raportoi valitusluvut suoraan jos olet määrittänyt sen. Seuraa näitä mittareita lähetyspalveluntarjoajasi hallintapaneelin kautta. Jos valitusluvut nousevat, tutki miksi — lähetätkö käyttäjille jotka eivät nimenomaisesti antaneet suostumustaan? Ovatko sähköpostisi liian usein toistuvia? Onko ristiriita sen välillä mitä käyttäjät odottivat ja mitä he saavat?

Täydellinen toimitettavuuden tarkistuslista

• SPF-tietue: DNS TXT -tietue lähettävässä verkkotunnuksessasi, joka listaa kaikki valtuutetut lähettävät palvelimet. Testaa MXToolboxilla.
• DKIM: Kryptografinen allekirjoitus konfiguroituna lähetyspalveluntarjoajasi kautta, julkinen avain julkaistuna DNS:ssä.
• DMARC: Aloita p=none-valvonnalla, etene arvoon p=quarantine ja sitten p=reject koostettujen raporttien tarkastelun jälkeen.
• Omistautunut lähetyspalveluntarjoaja: Käytä SendGridiä, SES:ää, Postmarkia tai Mailgunia — ei sovelluspalvelintasi tai jaettua SMTP:tä.
• Puhtaat aiherivit: Tarkkoja, olennaisia, ei liipaisusanoja, ei liiallista välimerkitystä tai isoja kirjaimia.
• HTML + pelkkä teksti: Sisällytä aina molemmat. Älä koskaan lähetä pelkkiä HTML-sähköposteja.
• Ei URL-lyhentäjiä: Käytä täysiä, suoria URL:eja sähköpostin rungossa ja vahvistuslinkeissä.
• Peruutuslinkki: Sisällytä jopa tapahtumasähköpostiin missä se on aiheellista — jotkut palveluntarjoajat vaativat sitä.
• Fyysinen osoite: CAN-SPAM:n ja vastaavien säädösten vaatima monilla lainkäyttöalueilla.
• Kovien palautusten käsittely: Poista välittömästi; älä koskaan yritä uudelleen kovaa palautusta.
• Valitusten seuranta: Määritä Gmail Postmaster Tools; seuraa valituslukujen hallintapaneelia.
• Postilaatikkotestaus: Lähetä testisähköposteja tuoreisiin väliaikaisiin postilaatikoihin ennen jokaista käyttöönottoa ja minkä tahansa mallipohja- tai konfiguraatiomuutoksen jälkeen.
• MXToolbox-terveystarkistus: Sisällytä esilaunkkilistaasi jokaiselle uudelle verkkotunnukselle ja ympäristölle.

Milloin käyttää omistautunutta tapahtumasähköpostipalvelua

Jos sovelluksesi lähettää lainkaan sähköpostia, joka käyttäjän täytyy vastaanottaa toimiakseen — vahvistuslinkkejä, salasanan palautuksia, ostovahvistuksia — sinun tulisi käyttää omistautunutta tapahtumasähköpostin palveluntarjoajaa ensimmäisestä päivästä alkaen. Kustannus on matala (usein ilmainen kymmeniin tuhansiin sähköposteihin kuukaudessa), luotettavuus on dramaattisesti parempi kuin tee-se-itse-SMTP, ja toimitettavuusinfrastruktuuri — jaetut IP-poolit hallitulla maineella, automaattinen DKIM-allekirjoitus, palautusten ja valitusten käsittely — ylläpidetään tiimien toimesta, joiden koko työ on pitää sähköposti postilaatikoissa.

Yleisin tee-se-itse-virhe on postipalvelimen ajaminen samassa IP:ssä kuin verkkosovelluksesi, tai halvan hosting-palveluntarjoajan pakettiin kuuluvan SMTP-palvelun käyttäminen. Nämä IP:t lisätään rutiininomaisesti estolistoille palveluiden kuten Spamhaus toimesta, koska hosting-ympäristö on jaettu pahantahtoisten toimijoiden kanssa. Vaihtaminen omistautuneeseen tapahtumapalveluntarjoajaan on yleensä iltapäivän työ ja sillä on välitön positiivinen vaikutus toimitettavuuteen. Se on yksi korkeimman vipuvaikutuksen infrastruktuuriparannuksista, joita pieni tiimi voi tehdä. Yksityisyystietoisten tiimien tulisi myös tarkastella ohjeistusta Electronic Frontier Foundationilta käyttäjädatan vastuullisesta käsittelystä kun sähköposti on mukana. Lisäksi osoitteiden seuraaminen tunnettuja tietomurtotietokantoja vasten palvelun Have I Been Pwned kautta voi täydentää petosten ehkäisyäsi kun uusia tilejä luodaan.