exim.ro

De ce ajung mailurile în spam și cum reparați

Cauzele tehnice pentru care mailul ajunge în spam: SPF, DKIM, DMARC, DNS invers, blacklist-uri, TLS, antete și dezabonare, cu testul și remedierea lor.

Actualizat la 5 minute de citit10 secțiuni

Deschide Test de livrare

Fiecare furnizor de mail are filtrele lui, iar reputația unui expeditor se construiește în timp, din reclamațiile și reacțiile destinatarilor. O parte însă se poate verifica tehnic, și e de obicei prima care strică livrarea: autentificarea, adresa de pe care pleacă mailul, listele negre, criptarea și forma mesajului. Ghidul le ia pe rând. Testul de livrare le verifică pe toate pe un mesaj real: primiți o adresă, îi trimiteți un mesaj și vedeți ce vede serverul care îl primește.

Ce cer marii furnizori

Gmail a publicat cerințe explicite pentru cine îi trimite mail (pagina „Email sender guidelines”, citită la 25 septembrie 2026). Pentru toți expeditorii:

  • SPF sau DKIM pentru domeniul de pe care trimiteți;
  • înregistrări DNS directe și inverse (PTR) valide pentru domeniul sau adresa IP de pe care trimiteți;
  • conexiune TLS la transmitere;
  • mesaje formatate după RFC 5322;
  • rata de reclamații pentru spam, raportată în Postmaster Tools, sub 0,3%.

Pentru cine trimite peste 5.000 de mesaje pe zi către Gmail se adaugă: SPF și DKIM, o politică DMARC (poate fi p=none), alinierea domeniului din From cu domeniul SPF sau DKIM, iar mesajele de marketing și cele la care destinatarul s-a abonat trebuie să aibă dezabonare cu un clic și un link de dezabonare vizibil în text. Cine nu respectă cerințele riscă limitarea ritmului de trimitere, blocarea mesajelor sau marcarea lor ca spam.

SPF, DKIM și DMARC

  • SPF (RFC 7208) spune ce servere pot trimite pentru domeniul din adresa de plic (Return-Path). Un server lipsă din SPF dă softfail sau fail.
  • DKIM (RFC 6376) semnează mesajul cu o cheie a domeniului. Semnătura supraviețuiește redirecționărilor, SPF nu (RFC 7208, secțiunea 10.3).
  • DMARC (RFC 7489) leagă SPF și DKIM de adresa din From: mesajul trece doar dacă una dintre ele trece și e aliniată cu domeniul din From.

Greșeala obișnuită: un serviciu extern (newsletter, facturare, CRM) care trimite cu domeniul dumneavoastră în From, dar semnează cu domeniul lui și trimite din SPF-ul lui. Trece SPF și DKIM, dar pică DMARC. Remedierea: DKIM cu domeniul dumneavoastră în acel serviciu. Unelte: generatorul SPF, generatorul DKIM, generatorul DMARC, iar ghidul DMARC pas cu pas arată trecerea treptată la o politică strictă.

DNS-ul invers

Adresa IP a serverului care trimite trebuie să aibă o înregistrare PTR, iar numele din ea trebuie să ducă înapoi la aceeași adresă. RFC 1912 (secțiunea 2.1) cere ca fiecare adresă să aibă un PTR potrivit cu înregistrarea A, pentru că altfel serviciile se pot comporta ca pentru un nume neînregistrat. Gmail îl cere explicit. PTR-ul îl setează cine deține adresa IP (furnizorul de hosting sau de internet), nu panoul DNS al domeniului. Îl verificați cu verificarea serverului SMTP.

Listele negre

Multe servere întreabă, pentru fiecare conexiune, liste publice de adrese care au trimis spam (DNSBL, RFC 5782). O adresă listată își vede mailul respins sau trimis în spam oriunde e folosită lista. Cauze posibile: un cont compromis care a trimis spam, un formular web folosit abuziv, o adresă IP moștenită de la cineva care a trimis spam. Verificați adresa cu verificarea blacklist, reparați cauza, apoi cereți scoaterea după procedura fiecărei liste.

TLS

STARTTLS (RFC 3207) criptează conversația dintre servere. Gmail cere o conexiune TLS la transmitere, deci serverul care îi trimite mail trebuie să folosească STARTTLS. Testul de livrare arată dacă mesajul a sosit criptat și cu ce versiune de TLS.

Antetele

RFC 5322 (secțiunea 3.6) cere în fiecare mesaj un câmp Date și câmpul de expeditor (From), iar secțiunea 3.6.4 spune că fiecare mesaj ar trebui să aibă și un Message-ID. Gmail cere mesaje formatate după RFC 5322, deci un mesaj generat de o aplicație care uită Date sau From nu respectă cerințele. From trebuie să apară o singură dată: mesajele cu două câmpuri From sunt de obicei respinse de serverele care aplică DMARC, pentru că RFC 5322 interzice forma (RFC 7489, secțiunea 6.6.1).

Dezabonarea

Câmpul List-Unsubscribe (RFC 2369) le dă clienților de mail o cale standard de dezabonare. RFC 8058 adaugă dezabonarea cu un clic: pe lângă un URI HTTPS în List-Unsubscribe, mesajul poartă List-Unsubscribe-Post: List-Unsubscribe=One-Click, iar semnătura DKIM trebuie să acopere ambele câmpuri. Motivul, spus chiar în RFC 8058: când dezabonarea e prea grea, destinatarul marchează mesajele ca spam, iar expeditorii ale căror mesaje sunt des marcate așa au o livrare proastă.

Ce nu se vede dintr-un singur mesaj

Reputația domeniului și a adresei IP, rata de reclamații, volumul brusc de pe o adresă nouă și conținutul (linkuri către domenii cu reputație proastă, doar imagini, fără text) contează și ele, dar diferă de la un furnizor la altul și nu pot fi verificate dintr-un mesaj de test. Pentru Gmail, Postmaster Tools arată reputația și rata de reclamații.

Pașii, pe scurt

  1. Dacă ați primit un mesaj de eroare (bounce), lipiți-l aici: codul din el, de exemplu 550 5.7.26, spune de obicei exact ce verificare a picat.
  2. Trimiteți un mesaj real la testul de livrare, din sistemul care are probleme.
  3. Reparați ce iese roșu: SPF, DKIM, DMARC, PTR, liste negre.
  4. Repetați testul până trec toate verificările, apoi urmăriți rapoartele DMARC câteva săptămâni.

Surse