Ai un domeniu, un server pe care rulează site-ul și cineva îți spune că poți pune și emailul acolo. Pare logic: un abonament mai puțin, totul la un loc. Apoi un client te sună să întrebe de ce nu a primit oferta. A primit-o, dar în Spam. Sau nu a primit-o deloc și nimeni nu știe unde a dispărut.
La email, să trimiți e simplu, iar să ajungi la destinație e greu. Regulile le fac cei care primesc, adică Gmail, Outlook și Yahoo, și le-au înăsprit în 2024. Un server propriu intră în jocul ăsta fără istoric, fără reputație și cu toată responsabilitatea pe umerii tăi.
Mai jos găsești ce cer marii furnizori de la un expeditor, cât costă în timp un server pe care nu îl vezi în factură și cele două servicii care fac treaba mai bine decât ai face-o tu.
Problema nu e să trimiți, ci să ajungi în Inbox
Orice server poate trimite email. Protocolul e vechi, deschis și nu cere permisiune. Ce nu poate garanta niciun server este că mesajul va fi acceptat și pus în Inbox. Decizia o ia serverul destinatarului, iar la Gmail, Outlook și Yahoo se ia după reputație: a IP-ului de pe care vine mesajul și a domeniului expeditorului.
Un server nou pornește cu reputație zero, așa că filtrele sunt prudente. Mai rău, IP-ul primit de la furnizorul de hosting a fost, cel mai probabil, folosit de altcineva înainte. Dacă acel cineva a trimis spam, IP-ul poate figura pe liste negre înainte să trimiți tu primul mesaj.
Iar reputația se pierde repede. Un formular de contact fără protecție, folosit de roboți ca să trimită mii de mesaje prin serverul tău. Un cont cu parolă slabă, spart și pus la treabă pentru spam timp de o noapte. O singură întâmplare de felul ăsta pune IP-ul și domeniul pe liste negre, iar scoaterea durează zile. Între timp, nici facturile, nici ofertele nu mai ajung.
Ce cer Gmail, Outlook și Yahoo de la expeditori
Din 2024, Google și Yahoo au publicat cerințe clare pentru cine trimite email în volum către utilizatorii lor, iar Microsoft a urmat aceeași direcție. Pe scurt: SPF, DKIM și DMARC publicate în DNS, rată de reclamații la spam sub un prag mic, dezabonare cu un click la newslettere, înregistrare PTR validă pentru IP-ul expeditor și trimitere prin TLS. Lista oficială a Google e în ghidul pentru expeditori de email.
SPF: cine are voie să trimită în numele domeniului
SPF este o listă publicată în DNS-ul domeniului tău, în care spui ce servere au voie să trimită email cu adrese @firma.ro. Când Gmail primește un mesaj de la tine, verifică dacă serverul de unde a venit e pe listă. Dacă nu e, mesajul e suspect. Fără SPF, oricine poate trimite email cu numele tău și destinatarul nu are cum să deosebească mesajul real de unul falsificat.
DKIM: semnătura care dovedește că mesajul nu a fost modificat
DKIM adaugă fiecărui mesaj o semnătură criptografică, iar cheia cu care se verifică stă tot în DNS. Destinatarul poate confirma că mesajul a plecat de la un server autorizat de domeniul tău și că nu a fost modificat pe drum. Fără DKIM, mesajele nu au nicio dovadă de autenticitate, iar filtrele le tratează în consecință.
DMARC: ce se întâmplă când SPF sau DKIM pică
DMARC este politica prin care îi spui destinatarului ce să facă cu mesajele care nu trec verificările de mai sus: să le accepte oricum (p=none), să le pună în carantină (p=quarantine) sau să le respingă (p=reject). Tot DMARC îți trimite rapoarte despre cine a trimis în numele domeniului tău și cu ce rezultat. Fără DMARC, SPF și DKIM sunt verificări fără consecință, iar din 2024 lipsa politicii e ea însăși motiv de respingere la expeditorii de volum.
Restul listei: PTR, TLS, rata de spam și dezabonarea
PTR, sau reverse DNS, înseamnă că IP-ul serverului tău răspunde cu un nume de domeniu când e întrebat; fără el, serverul arată ca un calculator de acasă. TLS înseamnă că legătura dintre servere e criptată. Rata de spam este procentul de destinatari care apasă „Raportează spam” pe mesajele tale, măsurat de Google în Postmaster Tools. Dezabonarea cu un click se aplică mesajelor de marketing și trebuie să funcționeze din antetul mesajului, nu doar dintr-un link din subsol.
Ce înseamnă de fapt să întreții un server de email
Instalarea e partea ușoară. Un server de email care funcționează bine cere, săptămână de săptămână:
- actualizări de securitate pentru serverul de email, antispam și sistemul de operare, aplicate la timp;
- un filtru antispam pentru ce primești și unul antivirus pentru atașamente, cu reguli care se învechesc;
- monitorizarea listelor negre, ca să afli că ai fost pus pe una înainte să afle clienții;
- cozi de mesaje blocate, care se umplu tăcut când un destinatar mare te refuză temporar;
- spațiu pe disc, pentru că oamenii nu șterg nimic și cutia de 2 GB devine 40 GB;
- backup la cutiile poștale, testat, nu doar configurat;
- disponibilitate: când serverul cade duminică seara, cineva trebuie să îl ridice.
Nimic din lista asta nu apare în factura de hosting. Toate se plătesc însă, în orele cuiva din firmă, ale unui administrator extern sau în mesajele pierdute. În practică, un server de email întreținut corect costă mai mult în timp decât abonamentul pe care voiai să îl eviți.
Două nevoi diferite, două soluții
„Emailul firmei” înseamnă de fapt două lucruri care nu seamănă între ele. Le pui pe servicii separate.
Cutiile poștale ale oamenilor
Aici intră contact@, vanzari@ și adresele fiecărui angajat. Sunt cutii citite de oameni, cu răspunsuri, atașamente și calendar. Pentru ele, Google Workspace sau Microsoft 365 sunt alegerile firești: spațiu, calendar partajat, autentificare în doi pași, filtre antispam bune, suport și o reputație de livrare construită de ani de zile.
Emailurile automate ale site-ului
Confirmări de comandă, resetări de parolă, notificări de la formulare, facturi generate automat. Nimeni nu răspunde la ele, dar trebuie să ajungă de fiecare dată și repede. Pentru ele folosești un furnizor de SMTP tranzacțional: SMTP2GO, Postmark, Amazon SES, Brevo sau Mailgun sunt exemple cunoscute. Toți îți dau ce nu ai pe un server propriu: jurnal cu fiecare mesaj, statistici de livrare, rapoarte de respingere. Dacă un client spune că nu a primit confirmarea, cauți adresa în jurnal și vezi imediat dacă a fost livrată, respinsă sau marcată ca spam.
| Nevoie | Ce folosești | Ce primești |
|---|---|---|
| Cutii poștale citite de oameni | Google Workspace, Microsoft 365 | Calendar, spațiu, securitate, suport, reputație bună |
| Emailuri automate ale site-ului | Furnizor SMTP tranzacțional | Jurnal per mesaj, statistici, rapoarte de respingere |
| Newslettere și campanii | Platformă de email marketing | Dezabonare, segmentare, rapoarte de deschidere |
De ce nu le amesteci
Reputația se calculează pe domeniu, nu pe cutie. Dacă trimiți un newsletter către câteva mii de adrese de pe contact@firma.ro, iar câteva zeci de oameni îl raportează ca spam, scade reputația întregului domeniu. A doua zi, oferta trimisă de un coleg de pe adresa lui ajunge și ea în Spam. Campaniile merg pe o platformă făcută pentru asta, cu dezabonare și liste curate; ce presupune un program de email marketing făcut fără să îți strici reputația e o discuție separată de infrastructură.
De ce nu PHP mail() de pe serverul web
Majoritatea site-urilor, WordPress inclus, trimit email în mod implicit prin funcția mail() din PHP. Serverul web devine astfel un server de email improvizat, fără niciuna din condițiile de mai sus. Nu există autentificare. Nu există semnătură DKIM. IP-ul este, la hosting partajat, același cu al altor zeci de site-uri, iar reputația lui depinde de vecini. Și nu există jurnal: mesajul pleacă și nu mai știi nimic despre el.
Rezultatul se vede la aproape orice site nou: resetările de parolă nu vin, confirmările de comandă ajung în Spam, mesajele de la formular dispar. Soluția este un plugin de SMTP în WordPress, configurat să trimită prin furnizorul tranzacțional ales. Verificarea că funcționează face parte din întreținerea normală a site-ului, la fel ca actualizările.
Capcane frecvente
Chiar și cu servicii bune, câteva greșeli de configurare apar mereu.
Adrese de expeditor care nu există. Un no-reply@firma.ro care respinge răspunsurile pare inofensiv, dar fiecare răspuns respins e un semnal negativ, iar clientul rămâne fără răspuns. Mai grav: adresa de administrator din WordPress, pe care vin resetările de parolă și notificările de securitate, e uneori o adresă care nu a existat niciodată sau a unui fost angajat. Verifică ce scrie în Setări și dacă acea cutie e citită de cineva.
SPF cu prea multe „include”. Verificarea SPF permite cel mult 10 căutări DNS. Fiecare include: consumă una, iar serviciile incluse au la rândul lor include-uri. Cu Google Workspace, un furnizor tranzacțional, o platformă de newsletter și un CRM, limita se depășește ușor și SPF-ul devine invalid, ca și cum nu l-ai avea.
DMARC pe „reject” înainte de a verifica toate sursele. Politica strictă e ținta, dar pusă prea devreme oprește emailurile de la sistemul de facturare sau de la CRM-ul pe care ai uitat că îl ai. Începe cu p=none, citește rapoartele câteva săptămâni, adaugă fiecare sursă legitimă în SPF și DKIM, apoi urcă la quarantine și la final la reject.
Emailurile automate pe domeniul principal. Multe firme trimit tranzacționalele de pe un subdomeniu dedicat, de exemplu notificari.firma.ro, cu SPF și DKIM proprii. Dacă un formular e abuzat sau un magazin trimite prea mult într-o zi, suferă reputația subdomeniului, nu a domeniului de pe care scriu oamenii.
Când schimbi furnizorul sau adaugi un serviciu care trimite în numele domeniului, actualizează SPF și DKIM în aceeași zi. Un serviciu neautorizat produce exact eșecurile pe care DMARC le pedepsește.
Cum verifici singur
Nu ai nevoie de un administrator ca să afli în ce stare e domeniul. Trimite un email de pe adresa firmei către un cont Gmail personal. Deschide mesajul, apasă pe cele trei puncte și alege „Afișează originalul”. Sus vezi trei rânduri: SPF, DKIM și DMARC, fiecare cu PASS sau FAIL. Pentru site, fă același test cu o resetare de parolă sau o comandă de probă. Mesajul trebuie să vină semnat DKIM de furnizorul tranzacțional, nu de pe serverul web.
Există și unelte publice de verificare DNS, gratuite, în care introduci domeniul și vezi înregistrările SPF, DKIM și DMARC cu greșelile marcate: include-uri în plus, sintaxă greșită, politici lipsă. Iar dacă DMARC e publicat cu adresă de raportare, rapoartele îți spun, sursă cu sursă, cine trimite în numele tău și cât trece verificările.
Lista de verificare
- Cutiile oamenilor sunt pe Google Workspace sau Microsoft 365, nu pe serverul site-ului.
- Emailurile automate ale site-ului pleacă printr-un furnizor SMTP tranzacțional, cu jurnal de livrare.
- WordPress trimite prin plugin de SMTP, nu prin
mail(). - SPF este publicat și rămâne sub limita de 10 căutări DNS.
- DKIM este activ pentru fiecare serviciu care trimite în numele domeniului.
- DMARC este publicat, cu adresă de raportare, și politica a fost ridicată treptat.
- Adresa de administrator din site există și e citită de cineva.
- Newsletterele pleacă de pe o platformă de marketing, nu de pe
contact@. - Emailurile automate au subdomeniu propriu, cu SPF și DKIM separate.
- „Afișează originalul” în Gmail arată PASS la toate trei.
Deschide o unealtă gratuită de verificare DNS, introdu domeniul firmei și uită-te dacă apar înregistrările SPF, DKIM și DMARC. Notează ce lipsește sau ce e marcat ca eroare. E tot ce ai nevoie ca să știi ce ceri de la cine îți administrează domeniul.