Kodėl laiškai nueina į spam?

Kodėl siunčiami el. laiškai nueina į SPAM?

Problema

Priminimai ir naujienlaiškiai gavėjų dėžutėse dažnai pripažįstami brukalais, eina tiesiai į šiukšlinę ir gavėjai jų nepamato.

Kodėl taip yra?

Siuntėjai ne iki galo susikonfigūruoja savo SMTP serverius ir domenus, todėl gavėjai jų laiškų neautentifikuoja ir palaiko SPAM.

Kaip spręsti?

Susikonfigūruokite domeno SPF ir DKIM įrašus, naudokite veikiantį siuntėjo adresą, reaguokite į grįžusius laiškus ir saugokite reputaciją.

Dar visai neseniai UAB „Virtualioje erdvėje“ siųsdavome klientų komercinius pasiūlymus popieriniais laiškais. Lietuvos paštas savo sutartyje garantuoja 97% laiškų pristatymą. Vadinasi, 3% laiškų gali pasimesti be jokios žinios. Deja, siunčiant asmeniškai nepažįstamiems gavėjams, be žinios dingdavo kur kas didesnė tokių laiškų dalis: įmesti ne į tą pašto dėžutę, dingę ir t.t.

Įskaitant grįžusius laiškus (nėra pašto dėžutės, išsikraustė ir pan.), iš viso adresato nepasiekdavo apie 15% laiškų. Šios priežastys nepriklauso nei nuo jūsų, nei nuo LP, tad belieka pasikliauti sėkme.

Paskambindavus tiems beveik 85%, kas laiškus visgi turėjo gauti, išaiškėdavo dar liūdnesnė statistika. Trečdalis jokio laiško nepamena, net neatplėšę palaikė nesvarbiu, išmetė kartu su Iki, Maximos ir Rimi laikraščiais ir t.t. Žodžiu, vos pusė gavėjų tokį laišką apskritai paėmė į rankas.

Labai panašiai veikia daugelio įmonių el. paštasKai el. paštu siunčiate priminimus ir naujienlaiškius, gavėjų dėžutėse jie dažnai būna pripažįstami kaip brukalai (angl. spam), keliauja tiesiai į šiukšlinę ir jokio dėmesio nesulaukia.

Skirtumas tarp elektroninio ir tradicinio pašto tas, kad el. pašto problemos sprendžiamos daug greičiau ir patikimiau. Susitvarkę kelis techninius niuansus, savo el. laišką klientui visuomet padėsite tiesiai ant stalo, o ne į šiukšlinę.

Bent kelis kartus per mėnesį iš savo naujų klientų gaunu tą patį klausimą: kodėl mūsų įmonės siunčiami rimti el. laiškai nueina į spam? Kadangi mano įmonė yra autorizuota Google Apps for Work paslaugų platintoja Lietuvoje ir apie Gmail žinome daugiau, nei eilinis vartotojas, nuolat gaunu ir prašymų „pakonsultuoti“ ar padėti atkurti reputaciją būtent Gmail akyse.

Iki šiol visų klientų atvejais problema būdavo viena ar kelios iš žemiau aprašytų 7 klaidų. Vien šie 7 sprendimai padėjo daugiau kaip 100 tūkst. reklaminių laiškų per dieną siunčiančiam portalui pereiti iš Spam į Inbox aplanką. Jie padės ir jums.

1. SPF įrašai: nenurodėte serverių, kurie gali siųsti laiškus iš jūsų domeno

El. pašto dėžutės ir el. pašto adresai reikalingi tik el. laiškų gavimui. Juos išsiųsti gali bet koks serveris, nurodęs bet kokį siuntėją. Pavyzdžiui, kad išsiųsčiau el. laišką iš bet kokio serverio, jame pakanka tokios PHP komandos:

<?php
mail(
   '[email protected]',
   'Laiško tema',
   'Laiško tekstas',
   'From: [email protected]'
);
?>

Kai adresato serveris gauna el. laišką, tikras yra tik siuntėjo serverio IP adresas, pvz.: 8.8.8.8. Visa kita, įskaitant ir siuntėjo el. pašto adresą, nurodo pats siuntėjas. Vadinasi, galiu išsiųsti el. laišką kad ir iš [email protected] „dėžutės“.

Tuo naudojasi programišiai: įsilaužę į pasenusias WordPress svetaines, jie ima siųsti brukalus kitais vardais. Kad būtų apsisaugota nuo apgavysčių, sukurtas SPF (angl. Sender Policy Framework) standartas. Specialiu TXT įrašu domenų savininkai DNS zonoje nurodo, kurie serveriai (IP adresai) gali siųsti laiškus siuntėjo adrese nurodę jų domeną.

Jei SPF įrašo nesukuriate arba jį nurodote neteisingai, dažniausiai gavėjo serveris laišką pripažins kaip nepatikimą ir nufiltruos į Spam katalogą.

Pasitikrinti, ar teisingai nurodyti jūsų domeno DNS zonos SPF įrašai, galite MXtoolbox puslapyje.

2. DKIM raktai: nepasirašėte siunčiamų el. laiškų

SPF yra tik pirmas žingsnis tikrinant siuntėją. Antras žingsnis – ar laiškas yra pasirašytas kriptografiniu raktu DKIM (angl. DomainKeys Identified Mail).

Panašiai kaip veikia SSL sertifikatai, autentifikuojami ir el. laiškai. El. laiškus siunčiantis serveris susikuria privatų raktą, kuriuo pasirašo laiškus. Domeno DNS zonoje nustatoma vieša DKIM rakto šaknelė, kuria galima patikrinti, ar laiškas tikrai pasirašytas tik domeno savininko turimu raktu.

Jei el. laiškas nepasirašytas DKIM raktu arba pasirašytas neteisingai, gavėjo el. pašto serveriai jį vertina įtariai. Išauga tikimybė, kad toks laiškas nueis į Spam.

El. paštas DKIM raktai
Siuntėjo, kuris pasirašė el. laišką DKIM raktu, informacija gavėjo Gmail dėžutėje.

Ar laiškas teisingai pasirašytas, rodo el. pašto programos. Pavyzdžiui, Gmail dėžutėje paspaudę rodyklę greta siuntėjo pavadinimo, matysite visą siuntėjo informaciją. Laukelyje „siųsta iš“ nurodytas laišką pristačiusio serverio adresas, o „pasirašė“ – kurio domeno DKIM raktas sėkmingai autentifikuotas.

3. DMARC: neteisingai apibrėžėte politiką

DMARC (angl. Domain-based Message Authentication, Reporting & Conformance) apibrėžia politiką, ką daryti su padirbtais laiškais – tais, kurie neatitinka mūsų domeno SPF politikos arba nėra pasirašyti DKIM raktu. Pavyzdžiui, jei koks šlamšto siuntėjas laiško siuntėjo adrese nurodys mūsų domeno adresą [email protected], mes el. pašto tarnyboms pranešame, kad jo nesiuntėme ir jį reikia trinti.

Teoriškai, DMARC nedaro jokios įtakos autentiškiems mūsų siunčiamiems laiškams. Praktiškai, siuntėjui nauda tik tokia, kad pasijungdami DMARC tikrai teisingai susikonfigūruosime SPF bei DKIM ir gausime pranešimus apie bandymus naudoti mūsų domeną šlamšto siuntimui.

Lengviausia DMARC pasijungti su Postmark DMARC įrankiu.

Mes savo klientams pagal nutylėjimą dar nepajunginėjame DMARC nei ant Google Apps for Work, nei ant Hosted Email. Ne visos klientų sistemos (pvz.: el. parduotuvės) pasirašo laiškus su DKIM ir ne visus savo SMTP serverius klientai yra surašę į SPF nustatymus. Tuomet įjungus DMARC su standartiniais nustatymais, būtų daugiau žalos, nei naudos.

DMARC yra naudingas. Mano įmonė jį jau gan seniai naudoja visiems savo domenams. Vsiems stambiems klientams patariu jį susikonfigūruoti. Bet tiems, kurių autentiški laiškai tebeina į Spam, pasijungti DMARC yra per anksti. Jo įrašą prisidėkite tik susitvarkę visa kita, kai jūsų laiškai jau nebeina į aplanką Šlamštas.

4. Automatinius laiškus siunčiate iš neteisingo domeno

Kai susikuriame SPF įrašus ir nusistatome DKIM pasirašymą, darbuotojų siunčiami laiškai yra gaunami tvarkingai. Bet dažnai pamirštame, kad automatinius priminimus interneto svetainė siunčia pati, iš kito serverio. Jam irgi reikia sukonfigūruoti SPF ir DKIM nustatymus.

Paprasčiausias sprendimas – el. pašto serveryje sukurkite vieną SMTP vartotoją tokiems el. laiškams siųsti. Kai laiškus siųsite per savo pagrindinį SMTP serverį, gavėjai tuos laiškus matys kaip gautus iš normalios jūsų domeno dėžutės ir nieko nebereikės keisti.

Jei siunčiate didelius automatinių laiškų kiekius, paprasta el. pašto dėžutė netiks dėl siunčiamų laiškų limito. Masinių laiškų siuntimui reikės pasijungti atskirą SMTP serverį su atskiru DKIM raktu ir papildytu SPF įrašu.

Naudojant ne pagrindinį SMTP serverį, dažnai pasitaiko neteisingai nustatytas siuntėjo adresas. Pavyzdžiui, DKIM ir SPF susikonfigūruojame ant tera.lt, o masinius laiškus siunčiantis serveris siuntėjo adrese nurodo el. pašto adresą su savo hostname, pvz.: [email protected]. DNS zona mail.tera.lt neturi DKIM ir SPF įrašų, todėl tokie laiškai laikomi gautais iš nepatvirtinto siuntėjo ir keliauja į Spam.

Šią problemą pastebėsite bet kurioje el. pašto programoje patikrinę From laukelį. Ten turi būti nurodytas el. pašto adresas su jūsų pagrindiniu domenu, o ne kokiu nors subdomenu.

5. Nereaguojate į grįžtančius el. laiškus ir skundus

Visos el. pašto saugumo priemonės, kaip SPF ir DKIM, skirtos identifikuoti siuntėją. Jei jį identifikavus paaiškėja, kad tai gerai žinomas brukalų siuntėjas, tie laiškai iš karto eis į spam. Todėl savo domeno tapatybei turite susikurti ir saugoti gerą reputaciją.

Pirmiausia, laiškus siųskite tik iš egzistuojančio adreso, kuriuo iš tikrųjų veikia el. pašto dėžutė. Kitaip negausite grįžtančių laiškų ir skundų.

Tokios platformos kaip Gmail grąžina pranešimus apie kilusias problemas pristatant jūsų laišką ir vartotojų skundus FBL formatu. Jei į juos nereaguosite ir toliau bombarduosite laiškais tuos, kurie nenori jų gauti arba kurių adresai pasikeitė, greitai užsitarnausite brukalų siuntėjo reputaciją ir visi jūsų siunčiami laiškai eis tiesiai į Spam.

Tokie SMTP serveriai kaip AWS SES leidžia automatizuoti grįžtančių laiškų ir skundų apdorojimą. Tuomet skundai nesikartos ir išvengsite reputacijos problemų.

6. Jūsų SMTP serveris įtrauktas į juoduosius sąrašus

Visos el. pašto platformos tikrina ne tik siuntėjo domeną, bet ir siunčiančio serverio IP adresą. Jei jis įtrauktas į juoduosius sąrašus, laiškai iš jo apskritai nebus priimami.

Pasitaiko, kad būna nulaužiamos svetainės, el. pašto dėžutės ar visi serveriai. Tuomet iš jų pasipila brukalai ir serverio IP adresas patenka į blokuojamųjų sąrašus.

Kai naudojatės bendru hostingo serveriu, iš jo laiškus siunčia ir kiti. Bent vienam vartotojui prisidirbus, visas serveris žymimas kaip spam siuntėjas ir nukenčia visi jo vartotojai.

Patariu laiškus siųsti tik iš specialiai tam skirtų el. pašto platformų, kuriose filtruojami ir išsiunčiami laiškai. Jos pastebi kenkėjiškus arba nulaužtus vartotojus ir užblokuoja jų prieigą anksčiau, nei visas serveris papuola į juoduosius sąrašus.

Turėkite omenyje, kad tokių juodųjų sąrašų yra tūkstančiai. Tokius sąrašus susikuria kibernetinės apsaugos paslaugas teikiančios įmonės, interneto paslaugų teikėjai, IT specialistai ar studentai. Daugumos tų sąrašų niekas nenaudoja. Dalies jų administratoriai jau nebeprižiūri. Todėl ne į visus juoduosius sąrašus verta reaguoti.

Dauguma el. pašto tarnybų naudoja Spamhaus, Spamcop ir Barracuda administruojamus juoduosius sąrašus. Jei patekote į tuos sąrašus, tai labai svarbi problema. Jei patekote tik į kažkokį Kinijos interneto paslaugų teikėjo juodąjį sąrašą, dažnai tai neturi praktinės reikšmės.

7. Jūs siunčiate SPAM

4-ios iš 5 klientų užklausų dėl laiškų pripažinimo brukalais prasideda vyniojimu į vatą: tik susirašinėjame su partneriais, siuntėme naujienlaiškį savo lojaliems klientams ir t.t. Todėl mano komanda turi standartinę klausimų seką, kaip tą vatą nuvynioti ir sužinoti, kas iš tiesų įvyko.

Taupydami savo ir paslaugų teikėjo laiką, iš karto prisipažinkite, kad siuntėte naujienlaiškį per MailChimp ar MailerLite. Galiu lažintis, kad problemas sukėlė tas naujienlaiškis, o ne paprastas pavienis laiškas iš Gmail, todėl ir aiškintis reikia pradėti nuo jo.

Jūs žinote, kad naujienlaiškis yra personalizuotas el. laiškas su aktualiomis naujienomis tam, kas jas užsisakė. Kadangi vis dar skaitote šį straipsnį, esu 80% tikras, kad siuntėte ne naujienlaiškį, o brukalus.

Yra dalykų, kuriuos galima pataisyti, ir tie brukalai taps tikrais naujienlaiškiais:

  1. Siųskite tik tiems gavėjams, kurie aiškiai užsiprenumeravo jūsų prekės ženklo laiškus ir dar prieš gaudami pirmąjį laišką turėjo galimybę jų atsisakyti.
  2. Laišką pradėkite kreipimusi į konkretų Vardenį Pavardenį.
  3. Tekstą maksimaliai pritaikykite kiekvienam gavėjui: artimiausia parduotuvė pagal jo miestą, pasiūlymai pagal jo pirkimo istoriją ir t.t.
  4. Siųskite tik naują, šiuo momentu aktualią informaciją, kurios lygiai tokios pačios dar nesate siuntę.

Jei nesivadovausite šiais principais ir toliau siųsite šlamštą, gavėjai spaus Report Spam. Taip patys pasmerkiate savo prekės ženklą neišlipti iš Spam aplanko.

Jei jau prisidirbote, sprendimas priklauso nuo to, kas gavo blogą reputaciją: IP adresas ar domenas.

Jei anksčiau nenaudojote SPF ir DKIM, tikriausiai SMTP serverio IP adresas buvo įrašytas į juoduosius sąrašus. Tuomet reikia susitvarkyti siunčiamus el. laiškus, kad jie atitiktų Masinių pranešimų siuntėjų gaires, ir užpildyti prašymus juodųjų sąrašų administratoriams, kad jie pašalintų IP adresus iš savo sąrašų.

Jei naudojote SPF ir DKIM įrašus, tikriausiai įtraukėte savo domeną į Gmail juodąjį sąrašą. Tai lyg daryti nusikaltimą ir nusikaltimo vietoje palikti savo paso kopiją. Jei susitvarkysite savo siunčiamus el. laiškus, jie vis tiek toliau eis į Spam aplanką. Į Inbox pateksite tik tuomet, kai ant jūsų siunčiamų laiškų gavėjai spaus Not Spam arba praeis pakankamai laiko nuo šlamšto siuntimo.

Tokia praktika man atrodo nelogiška. Kokia prasmė siųsti klientams vertingus laiškus, jei jie jų nematys? Not Spam irgi daug nespaudinės, nebent po kiekvieno laiško išsiuntimo paskambinsite ir paprašysite tai padaryti. Jei susigadinote domeno reputaciją ir reikia valandų bėgyje atstatyti tvarkingą laiškų siuntimą, lengviausia būtų laiškų išsiuntimui laikinai pasijungti naują domeną, pvz.: su kita galūne, .com ar .eu.

Google neskelbia, kokiam terminui įtraukia domenus į juodąjį sąrašą. Todėl belieka bent kartą per savaitę išsiųsti tvarkingą el. laišką iš to domeno ir stebėti jo pristatomumą.

***

Retais atvejais el. laiškai patenka į gavėjų Spam katalogą per klaidą. Pavyzdžiui, gavėjo el. pašto serveris naudojasi pasenusiu neprižiūrimu juoduoju sąrašu, į kurį jūsų serveris patenka per klaidą.

Visgi dažniausiai problema būna siuntėjo pusėje. Kol kas kiek naujų klientų besikreipė, kad jų automatiniai laiškai eina į Spam, visais atvejais užteko atlikti šiuos 7 žingsnius:

  1. Sukuriame SPF įrašą nurodę visus SMTP serverius, kurie siunčia laiškus iš mūsų domeno.
  2. Nustatome DKIM raktą ir įjungiame laiškų pasirašymą visuose SMTP serveriuose.
  3. Pataisome arba ištriname DMARC įrašą.
  4. Automatinius laiškus siunčiame su autorizuotu SMTP vartotoju pagrindiniame domene.
  5. Priimame ir automatiškai apdorojame visus grįžtančius el. laiškus ir skundus.
  6. Laiškus siunčiame tik iš tų SMTP serverių, kurie filtruoja ir išeinančius laiškus.
  7. Personalizuojame laiško turinį ir laiškus siunčiame tik tiems, kurie jų laukia.

Siunčiant tradicinius laiškus, nėra jokių būdų garantuoti, kad laiškas gavėją pasieks. Tuo tarpu el. laiškų pristatymą galima garantuoti kur kas didesniu procentu. Jei visgi iškiltų kokių nors problemų, el. pašto platformos tiksliai praneš apie kiekvieną incidentą.

Jei siunčiate bent po kelis šimtus el. laiškų per dieną, patariu užsiregistruoti Google Postmaster Tools. Ten tiesiogiai matysite daugumą naujų problemų su jūsų siunčiamais el. laiškais.

Susitvarkę savo SMTP serverį ir pasijungę statistiką būsite garantuoti, kad jūsų išsiųstus laiškus klientai tikrai gauna.

Autoriaus interesų atskleidimas

Mano vadovaujama UAB „Virtuali erdvė“ stambiems el. laiškų siuntėjams teikia debesų kompiuterijos pagrindu veikiančius SMTP serverius, su garantija ir statistika kasdien pristatančius šimtus tūkstančių el. laiškų.

Autorių teisės

Creative Commons licencija Straipsnis „Kodėl siunčiami el. laiškai nueina į SPAM?“, kurio autorius Pakamore pasilieka ir saugo visas savo autoriaus teises, yra licencijuotas publikavimui pagal Creative Commons Priskyrimas + Jokių išvestinių darbų (BY-ND) 4.0 tarptautinę licenciją.