Fiecare site trimite e-mailuri. Resetări de parolă, confirmări de comandă, notificări din formularul de contact, mesajul care anunță echipa de vânzări că tocmai a sosit o cerere de ofertă. Aproape nimeni nu le pomenește când descrie ce face site-ul lui, și exact asta e problema. E-mailul tranzacțional e invizibil până în clipa în care nu mai ajunge, iar când nu mai ajunge, o face în tăcere. Site-ul arată bine. Formularul spune mulțumim. Și undeva, un client așteaptă un răspuns care nu va veni niciodată, și trage încet concluzia că l-ai ignorat.
Noi tratăm e-mailurile trimise de un site ca pe infrastructură, la fel ca DNS-ul sau TLS-ul. Se proiectează, se configurează, se monitorizează și se testează, pentru că "probabil merge" nu e un plan. Iată cum arată asta în practică și de ce credem că orice proprietar de site ar trebui să înțeleagă măcar în linii mari cum stau lucrurile.
E-mailul pe care nu-l vede nimeni până nu se strică
Merită făcută o distincție între newsletterele pe care o firmă alege să le trimită și e-mailurile pe care un site trebuie să le trimită. E-mailul de marketing e o campanie: cineva îl scrie, îl programează și urmărește rata de deschidere. E-mailul tranzacțional e un efect secundar al site-ului care își face treaba. Un vizitator completează un formular, o comandă se finalizează, un editor își resetează parola, iar un mesaj trebuie să plece și să ajungă în inboxul potrivit în câteva secunde.
Pentru că nu stă nimeni cu ochii pe vreun panou de control, e-mailul tranzacțional nu primește nici pe departe atenția de care are parte cel de marketing, deși fiecare mesaj în parte cântărește mult mai greu. Un newsletter ratat e o ridicare din umeri. O confirmare de comandă ratată e un telefon la suport. O notificare de formular ratată e un client potențial căruia i-a răspuns primul concurentul tău. Așa că atunci când luăm un site în grijă, unul dintre primele lucruri pe care le verificăm e drumul pe care îl face fiecare dintre mesajele astea, de la codul care îl compune până la inboxul în care ajunge.
Livrabilitatea se câștigă, nu se presupune
Serverele care primesc e-mailuri au devenit stricte, și pe bună dreptate: lumea e plină de mesaje falsificate. Marii furnizori de e-mail se așteaptă acum ca domeniul expeditor să dovedească, criptografic și prin DNS, că un mesaj chiar vine de unde pretinde că vine. Mesajele care nu pot dovedi asta sunt filtrate, întârziate sau aruncate, de multe ori fără să afle nimeni.
De aceea un site care pur și simplu lasă mesajele pe mâna programului local de e-mail oferit de server ajunge, mai devreme sau mai târziu, să aibă probleme. Poate merge azi și se poate strica luna viitoare, pentru că livrabilitatea nu e un buton pe care îl apeși o dată și gata. E o reputație pe care o câștigi și o păstrezi. Ingredientele tehnice sunt bine cunoscute: e-mailul pleacă printr-o conexiune SMTP autentificată către un serviciu de e-mail serios, înregistrările SPF declară ce servere au voie să trimită pentru domeniu, iar semnăturile DKIM îi permit destinatarului să verifice că mesajul nu a fost modificat pe drum și că vine cu adevărat de la domeniul din antet. Nimic din toate astea nu e exotic. Dar totul trebuie configurat corect, laolaltă, și ținut în ordine pe măsură ce site-ul și DNS-ul lui se schimbă.
Un singur drum de ieșire, autentificat
Regula noastră e că un site are exact un singur mod de a trimite e-mailuri: o conexiune autentificată către un serviciu de e-mail cunoscut, cu date de acces păstrate în siguranță, care se pot schimba fără să umbli în cod. Fiecare mesaj trimis de site, fie că vine din sistemul de bază, dintr-un formular de contact sau dintr-o funcționalitate personalizată, merge pe același drum.
Un singur drum contează mai mult decât pare. Când toate e-mailurile trec prin același loc, știi ce se întâmplă acolo. Poți vedea ce s-a trimis și când. Poți schimba datele de acces dintr-o singură mișcare, dacă e vreodată nevoie. Iar când ceva chiar merge prost, ai o singură conexiune de verificat, nu o expediție prin toate modulele care ar putea trimite e-mailuri pe cont propriu. E același instinct pe care îl aplicăm peste tot în munca noastră de infrastructură: mai puține drumuri, mai bine cunoscute.
Verificăm că e-mailurile chiar ajung
Configurarea e începutul, nu sfârșitul. Defecțiunea de care ne temem cel mai mult e cea tăcută: totul configurat corect anul trecut, apoi cineva modifică o înregistrare DNS dintr-un motiv fără legătură, expiră o parolă sau serviciul de e-mail își schimbă politica. Site-ul compune mesaje mai departe, senin, mesajele continuă să nu ajungă, tot în liniște, și nu observă nimeni până când un client întreabă de ce formularul de contact e mort de trei săptămâni.
Așa că monitorizăm e-mailul așa cum monitorizăm disponibilitatea. Verificăm că traseul de trimitere funcționează, nu doar că e configurat, și ținem sub ochi înregistrările DNS de care depinde livrabilitatea. Când ceva din lanțul ăsta se strică, vrem să observăm noi primii, chiar în ziua aia, nu să refacem firul evenimentelor după aceea, pornind de la un e-mail nedumerit sosit pe alt canal. Sistemele tăcute merită o monitorizare gălăgioasă, tocmai pentru că nu le urmărește nimeni zi de zi.
Staging-ul nu poate trimite niciodată e-mail unui client real
E-mailul făcut ca la carte are și o a doua jumătate, care ține de siguranță, nu de livrare. Fiecare site pe care îl administrăm are medii din afara producției: o copie locală pe calculatorul unui dezvoltator, un mediu de staging unde modificările se verifică înainte de lansare. Mediile astea rulează același cod ca producția, așa că vor încerca, fără nicio reținere, să trimită aceleași e-mailuri ca producția. Imaginează-ți că testezi un flux de comandă pe staging, iar sistemul trimite un e-mail de confirmare cât se poate de real unui client cât se poate de real, despre o comandă care nu există.
Pe platforma noastră, asta nu se poate întâmpla, iar "nu se poate" e spus la propriu. Mediile din afara producției nu pot, fizic, să livreze e-mailuri către exterior. Traficul de e-mail spre exterior e blocat la nivelul mediului, iar tot ce încearcă site-ul să trimită e redirecționat într-un colector de e-mailuri: un instrument care prinde fiecare mesaj, ca un dezvoltator să îl poată deschide, să verifice conținutul și formatarea și să confirme că fluxul funcționează, fără ca vreun mesaj să ajungă vreodată afară. Nimeni nu trebuie să țină minte să schimbe o setare și niciun modul configurat greșit nu poate ocoli blocajul, pentru că restricția stă sub nivelul aplicației.
Rezultatul e un soi de libertate ușor de subestimat. Dezvoltatorii pot testa resetări de parolă, confirmări de comandă și fluxuri de notificare oricât de agresiv vor, pe date realiste, cu zero șanse ca un mesaj rătăcit să ajungă într-un inbox real. Siguranța care depinde de atenția tuturor, de fiecare dată, cedează până la urmă. Siguranța construită în mediu, nu.
Ce înseamnă asta pentru tine, ca proprietar de site
Nu trebuie să știi ce înseamnă SPF. Dar există câteva întrebări la care merită să poți răspunde despre orice site de care depinzi. E-mailurile lui pleacă printr-un serviciu autentificat sau prin ce se nimerește să ofere serverul? Înregistrările DNS pe care le verifică furnizorii de e-mail chiar există și sunt corecte? Ar observa cineva dacă de mâine notificările din formulare nu ar mai sosi? Și poate un mediu de test să trimită vreodată e-mailuri reale unor oameni reali?
Pentru site-urile pe care le avem în grijă, răspunsurile sunt: autentificat întotdeauna, da și monitorizate, da chiar în aceeași zi, și nu, prin construcție. Ultimele două sunt partea la care ținem cel mai mult. Un site care își livrează e-mailurile fără greș și care, demonstrabil, nu le poate trimite din mediul nepotrivit face ceva deloc spectaculos, dar important: își ține fiecare promisiune, oricât de mică. Formularul care spune că mesajul a fost trimis spune adevărul. Cea mai mare parte a încrederii pe care o firmă o câștigă online e clădită tocmai din astfel de promisiuni mici, ținute.