El. pašto pristatomumas: SPF, DKIM ir DMARC paaiškinti

Laiškai dažniausiai patenka į šiukšliadėžę todėl, kad gavėjo paštas negali patikrinti, ar laiškas tikrai išsiųstas iš jūsų vardo. Šią problemą išsprendžia trys domeno įrašai — SPF, DKIM ir DMARC. Teisingai juos sukonfigūravus, Gmail, Outlook ir kiti pašto tiekėjai įsitikina, kad laiškas autentiškas, ir įdeda jį į gautųjų aplanką, o ne į „spam“. Šiame straipsnyje paaiškiname, kaip kiekvienas iš jų veikia, kaip juos patikrinti ir kokia veiksmų seka užtikrina, kad jūsų el. pašto rinkodara ar transakciniai laiškai realiai pasiektų klientą.

Kodėl net geri laiškai patenka į šiukšliadėžę

Geras laiško turinys — tik pusė reikalo. Prieš parodydamas laišką žmogui, gavėjo pašto serveris per kelias milisekundes atlieka eilę patikrų: ar siuntėjo domenas leido būtent šiam serveriui siųsti laiškus, ar laiško turinys nebuvo pakeistas kelyje, kokia siuntėjo IP adreso ir domeno reputacija. Jei atsakymai neaiškūs, laiškas keliauja į šiukšlių aplanką arba apskritai atmetamas.

2024 m. Google ir Yahoo sugriežtino reikalavimus masiniams siuntėjams: jeigu per parą siunčiate daug laiškų, autentifikacija tapo privaloma, o ne rekomendacija. Praktiškai tai reiškia, kad be SPF, DKIM ir DMARC net visiškai legalus naujienlaiškis ar užsakymo patvirtinimas gali nepasiekti gavėjo.

Dažniausios priežastys, dėl kurių laiškai krenta į „spam“:

• Nėra autentifikacijos įrašų — gavėjas negali patvirtinti siuntėjo tapatybės.
• Neteisingai sukonfigūruotas SPF arba DKIM — patikra nepavyksta (fail), ir tai dažnai blogiau nei jokio įrašo.
• Prasta siuntimo reputacija — daug atmetimų, skundų, siuntimas į neegzistuojančius adresus.
• Turinio signalai — vien didelės nuotraukos su mažai teksto, įtartinos nuorodos, „spam“ žodynas.

Techninė autentifikacija išsprendžia pirmuosius du punktus, o tai yra pamatas, be kurio visa kita neturi prasmės. Svarbu suprasti tvarką: jokia tobula tema ar pasiūlymas neišgelbės laiško, jeigu jis net nepateks į gautųjų aplanką. Todėl pristatomumą verta sutvarkyti pirmiau nei investuoti į turinį ar dizainą.

Trys įrašai, kurie patvirtina, kad laiškas tikrai jūsų

SPF, DKIM ir DMARC dirba kartu, bet kiekvienas atsako už skirtingą klausimą. Paprasčiausia įsivaizduoti juos kaip tris dokumento tikrinimo sluoksnius: kas turi teisę siųsti, ar turinys nepaliestas ir ką daryti, jei kažkas neatitinka.

SPF — kurie serveriai gali siųsti jūsų vardu

SPF (Sender Policy Framework) yra jūsų domeno DNS įrašas, kuriame išvardyti serveriai ir paslaugos, turintys teisę siųsti laiškus jūsų domeno vardu. Kai gavėjo serveris gauna laišką, jis patikrina, ar siuntusio serverio IP adresas yra šiame sąraše.

Tipinis SPF įrašas atrodo taip:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Čia include nurodo patikimas siuntimo paslaugas (pvz., Google Workspace, SendGrid), o ~all (softfail) reiškia, kad kiti šaltiniai laikomi įtartinais. Griežtesnis variantas -all (hardfail) reiškia „bet kas kitas — atmesti“.

Keli praktiniai niuansai, kuriuos verta žinoti:

• SPF įrašas turi būti tik vienas TXT įraše domenui; du atskiri SPF įrašai sukelia klaidą.
• Galioja 10 DNS užklausų limitas — per daug include sukelia „permerror“ ir patikra nepavyksta.
• SPF tikrina vadinamąjį „envelope“ adresą, o ne tą, kurį mato vartotojas, todėl persiunčiant laiškus SPF gali „lūžti“ — čia ir įsijungia DKIM bei DMARC.

DKIM — skaitmeninis parašas, patvirtinantis turinį

DKIM (DomainKeys Identified Mail) prideda prie kiekvieno laiško kriptografinį parašą. Siunčiant, jūsų sistema pasirašo laišką privačiu raktu, o gavėjas viešąjį raktą pasiima iš jūsų DNS ir patikrina parašą. Jei parašas sutampa, tai įrodo du dalykus: laišką tikrai siuntė įgaliota sistema ir turinys kelyje nebuvo pakeistas.

Skirtingai nuo SPF, DKIM išlieka galioti net persiunčiant laišką, nes parašas keliauja kartu su laišku. Todėl daugumai gavėjų DKIM yra svaresnis autentiškumo signalas. Praktiškai DKIM įdiegiamas DNS pridedant TXT įrašą su „selektoriumi“ (pvz., selector1._domainkey.jusudomenas.lt), kurio reikšmę pateikia jūsų pašto tiekėjas.

Be tinkamos autentifikacijos net visiškai legalus laiškas atrodo kaip galimas sukčiavimas — o gavėjo serveris visada renkasi atsargumą.

DMARC — politika, ką daryti su įtartinais laiškais

DMARC (Domain-based Message Authentication, Reporting and Conformance) sujungia SPF ir DKIM ir nurodo gavėjui, ką daryti, jei laiškas patikros nepraeina. Be DMARC SPF ir DKIM tik „informuoja“, bet nieko nereikalauja.

Tipinis DMARC įrašas:

v=DMARC1; p=none; rua=mailto:dmarc@jusudomenas.lt

Politikos reikšmės p:

1. p=none — nieko nedaryti, tik stebėti ir siųsti ataskaitas. Tinkamas startas pirmoms savaitėms.
2. p=quarantine — įtartinus laiškus dėti į „spam“.
3. p=reject — neautentiškus laiškus visai atmesti. Stipriausia apsauga nuo padirbtų laiškų jūsų vardu.

DMARC taip pat įveda suderinimo (alignment) reikalavimą: matomas „From“ domenas turi sutapti su tuo, kurį patvirtino SPF arba DKIM. Be to, rua adresu gaunate XML ataskaitas, leidžiančias matyti, kas iš tikrųjų siunčia laiškus jūsų vardu — neretai paaiškėja pamiršti įrankiai ar net bandymai apsimesti jūsų įmone.

Trumpas palyginimas, kuris klausimas kuriam įrašui priklauso:

• SPF atsako į klausimą „ar šis serveris turi teisę siųsti?“
• DKIM atsako „ar turinys autentiškas ir nepakeistas?“
• DMARC atsako „ką daryti, jei atsakymas neigiamas, ir kam pranešti?“

Visi trys reikalingi kartu: SPF be DMARC lengvai apeinamas persiunčiant, DKIM be DMARC nieko nereikalauja, o DMARC be veikiančio SPF ar DKIM neturi kuo remtis.

Kaip patikrinti, ar jūsų domenas teisingai sukonfigūruotas

Prieš keičiant ką nors, verta pamatyti esamą būklę. Tai galima padaryti per kelias minutes:

1. Atsiųskite sau bandomąjį laišką į Gmail, atidarykite jį, pasirinkite „Show original“ ir patikrinkite, ar prie SPF, DKIM ir DMARC rašoma „PASS“.
2. Naudokite nemokamus tikrintuvus — MXToolbox, dmarcian ar panašūs įrankiai parodo jūsų DNS įrašus ir įspėja apie klaidas (pvz., kelis SPF įrašus ar viršytą užklausų limitą).
3. Peržiūrėkite DNS tiesiogiai per domeno valdymo skydelį (pas registratorių ar hostingo tiekėją) ir įsitikinkite, kad TXT įrašai įvesti be papildomų tarpų ar nukopijuotų kabučių.
4. Stebėkite DMARC ataskaitas bent porą savaičių prieš griežtinant politiką iš none į quarantine ar reject.

Jei tvarkote ir savo svetainę, panašiai naudinga periodiškai atlikti bendrą svetainės patikrą — pristatomumas ir techninė svetainės būklė dažnai susiję per tuos pačius DNS nustatymus.

Kiti pristatomumo veiksniai

Autentifikacija atveria duris, bet ar liksite gautųjų aplanke ilgam, lemia ir kiti dalykai:

• Siuntėjo reputacija. IP adreso ir domeno istorija. Naujas domenas reputaciją turi „užsiauginti“ — siunčiant palaipsniui didinamus kiekius (warm-up), o ne iškart tūkstančius laiškų.
• Sąrašo higiena. Reguliariai valykite neegzistuojančius ir neaktyvius adresus. Aukštas „bounce“ ar neatidarymų rodiklis kenkia visiems jūsų laiškams.
• Sutikimas (opt-in). Siųskite tik tiems, kurie sutiko gauti laiškus. Tai ne tik pristatomumo, bet ir BDAR (GDPR) reikalavimas.
• Turinys ir struktūra. Tekstas–vaizdas balansas, aiškus „From“ vardas, matoma atsisakymo (unsubscribe) nuoroda, vengimas „spam“ žodyno.
• Įsitraukimas. Atidarymai, paspaudimai ir atsakymai siunčia teigiamą signalą; masiniai ištrynimai be skaitymo — neigiamą. Todėl geriau siųsti rečiau, bet tikslingiau, nei dažnai užkimšti neaktyvių gavėjų dėžutes.
• Siuntimo dažnis ir reguliarumas. Staigūs šuoliai (pvz., nuo 50 iki 5000 laiškų per dieną) atrodo įtartinai; tolygus, prognozuojamas srautas saugesnis.

Norintiems pamatuoti, ar el. paštas apskritai atsiperka, naudinga el. pašto rinkodara derinti su aiškiais rodikliais ir realia grąža.

Dažnos klaidos, dėl kurių krenta pristatomumas

• Du SPF įrašai viename domene — vietoj dviejų sujunkite į vieną su keliais include.
• Viršytas 10 DNS užklausų SPF limitas — patikra grąžina „permerror“ ir laikoma nesėkminga.
• DKIM neįdiegtas naujam siuntimo įrankiui — pridėjus naują paslaugą (pvz., naujienlaiškių platformą), pamirštama įjungti jos DKIM.
• Iškart p=reject be stebėjimo — galite netyčia blokuoti savo pačių legalius laiškus. Pradėkite nuo p=none.
• „From“ ir tikrojo siuntėjo nesuderinamumas — DMARC alignment nepavyksta, net jei SPF ar DKIM techniškai „PASS“.
• Vienas „visada blokuojamas“ tiekėjas — kartais reikia atskiro pošvietinio domeno (subdomeno) rinkodaros laiškams, kad nepakenktumėte pagrindinio domeno reputacijai.

Praktinis veiksmų sąrašas prieš pradedant siųsti

1. Inventorizuokite siuntėjus — surašykite visas paslaugas, kurios siunčia jūsų vardu (paštas, CRM, naujienlaiškiai, sąskaitų sistema).
2. Sukonfigūruokite SPF — vienas įrašas su visais reikalingais include ir ~all pradžiai.
3. Įjunkite DKIM kiekvienam siuntimo įrankiui ir pridėkite jo selektoriaus TXT įrašą.
4. Įdiekite DMARC su p=none ir nurodykite rua adresą ataskaitoms.
5. Stebėkite ataskaitas 2–4 savaites, kol visi legalūs šaltiniai praeina patikrą.
6. Griežtinkite politiką iki quarantine, vėliau iki reject.
7. Prižiūrėkite reputaciją — valykite sąrašą, sekite „bounce“ ir skundų rodiklius.

Šie įrašai gali atrodyti techniški, bet juos sukonfigūruoti reikia vieną kartą — o nauda jaučiama kiekviename išsiųstame laiške. Jei norite, kad pristatomumas, autentifikacija ir laiškų srautai būtų sutvarkyti iš karto teisingai, susisiekite per el. pašto rinkodaros paslaugą arba sujunkite tai su automatizavimu, kad transakciniai laiškai — sąskaitos, patvirtinimai, priminimai — visada pasiektų klientą.