Emailurile ajung în spam când sistemul destinatarului vede un risc mai mare decât încrederea acumulată. Cauza poate fi tehnică — autentificare, DNS, IP — sau comportamentală: listă fără permisiune, plângeri, bounce, volum instabil și mesaje pe care oamenii nu le vor. De obicei nu există un singur „cuvânt interzis” care explică tot.
Livrabilitatea nu înseamnă doar că platforma a acceptat trimiterea. Un mesaj poate fi trimis, acceptat de server, livrat într-un folder secundar, pus în spam sau blocat. Diagnosticul corect separă aceste stări și se uită la dovezi: headere, coduri SMTP, rapoarte de autentificare, reclamații și comportamentul cohortei.
Dacă operezi un program de email marketing, tratează domeniul și datele ca infrastructură critică. Copy-ul intră în analiză după ce știi că mesajul este semnat corect, publicul este legitim și fluxurile nu trimit duplicate.
Mai întâi definește unde s-a oprit mesajul
„Nu a ajuns” poate însemna cinci lucruri diferite. Platforma nu l-a trimis deoarece contactul era suprimat. Serverul destinatar l-a respins temporar sau permanent. Serverul l-a acceptat, dar filtrul l-a pus în spam. Mesajul a ajuns în Promotions ori altă categorie. Sau a ajuns în inbox, dar persoana nu l-a observat.
Caută mai întâi logul expeditorului. Pentru fiecare adresă de test notează message ID, ora, statusul, codul SMTP și răspunsul serverului. Un 5xx indică de regulă un eșec permanent pentru acea încercare; un 4xx poate cere retry. Citește textul complet al erorii și documentația furnizorului, nu traduce toate codurile prin „spam”.
Apoi deschide mesajul primit și inspectează sursa originală. În Gmail, secțiunea „Show original” arată rezultatele SPF, DKIM și DMARC. Acestea pot fi pass, fail, softfail, neutral sau alte stări, în funcție de mecanism. Salvează headerul pentru un mesaj bun și unul rău; comparația este mai utilă decât un screenshot cu folderul.
Promotions nu este spam. Este o categorie a interfeței Gmail și poate fi locul normal pentru marketing. Nu există un cod legitim care garantează mutarea în Primary. Optimizează pentru livrare și relevanță, nu pentru păcălirea clasificatorului. Un video analizat pentru acest articol promite exact această garanție fără dovadă; nu îl folosim.
Construiește o probă controlată: trimite același mesaj către adrese de test Gmail, Outlook și Yahoo, plus un domeniu de companie. Dacă eșecul apare doar într-un ecosistem, verifică cerințele și reputația de acolo. Dacă apare peste tot, caută mai întâi configurația comună și lista.
SPF: cine are voie să trimită pentru domeniu
SPF publică în DNS ce servere sunt autorizate să folosească domeniul din envelope sender. Standardul este definit în RFC 7208. El nu semnează corpul și nu garantează că adresa vizibilă din From este aceeași cu domeniul verificat.
Eroarea frecventă este existența mai multor înregistrări SPF independente. Domeniul trebuie să aibă un singur record SPF care include toate sursele legitime: platforma de newsletter, sistemul tranzacțional, CRM-ul și eventual infrastructura proprie. Copierea unui nou v=spf1 lângă cel vechi poate produce permerror.
Inventariază expeditorii înainte de editare. Uită-te în rapoarte DMARC, facturi, DNS, integrări și headere. Elimină serviciile vechi numai după ce verifici că nu mai trimit alerte, facturi sau resetări. Un include poate extinde lista de mecanisme și poate duce la limita de lookup; validează recordul rezultat, nu doar textul introdus.
SPF se poate rupe prin forwarding, deoarece IP-ul intermediar nu este neapărat autorizat de domeniul inițial. De aceea nu se implementează singur. DKIM oferă o cale diferită de autentificare, iar DMARC cere alinierea cu domeniul vizibil.
După schimbarea DNS, nu presupune propagare instant. RoTLD explică în întrebările despre administrarea domeniilor .ro că propagarea modificărilor DNS poate dura până la 24 de ore. Valoarea este specifică indicației registrului; cache-ul și TTL-ul concret pot produce comportamente diferite. Testează din mai multe rezolvoare.
DKIM: dovada criptografică a mesajului
DKIM adaugă o semnătură calculată cu o cheie privată; destinatarul găsește cheia publică în DNS și verifică părțile semnate. Specificația este RFC 6376. Un rezultat pass arată că semnătura verificată nu a fost invalidată și cheia corespunde, nu că mesajul este dorit.
Fiecare platformă oferă un selector și o înregistrare DNS. Publică exact numele și valoarea, apoi verifică mesajul real. Interfața platformei poate spune „authenticated”, dar un anumit flux poate trimite prin alt domeniu sau alt furnizor. Inspectează welcome, newsletter, checkout, factură și emailurile din CRM separat.
Rotește cheile conform capabilității furnizorului și procesului de securitate. Nu șterge selectorul vechi înainte ca mesajele semnate cu el să iasă din circulație. Documentează cine poate genera chei și cine poate modifica DNS.
Forwardingul poate păstra DKIM dacă intermediarul nu modifică părțile semnate. Unele liste rescriu subiectul, footerul sau corpul și pot invalida semnătura. Din nou, citește headerul final. Nu poți deduce rezultatul din recordul DNS singur.
O semnătură DKIM validă pentru domeniul furnizorului nu este suficientă pentru brand dacă From arată domeniul firmei. DMARC introduce conceptul de aliniere: domeniul autentificat trebuie să se potrivească organizațional cu domeniul vizibil, conform modului relaxat sau strict.
DMARC: aliniere, politică și rapoarte
DMARC verifică dacă SPF sau DKIM trece și este aliniat cu domeniul din From. Domeniul publică o politică și adrese pentru rapoarte agregate. RFC 7489 descrie mecanismul și politicile none, quarantine și reject.
Nu sari direct la p=reject fără inventar. Începe cu monitorizare, colectează rapoarte, identifică toate sursele legitime și repară alinierea. Apoi crește politica în pași controlați. Altfel poți bloca mesaje reale trimise de un sistem uitat.
DMARC protejează și marca împotriva spoofingului direct al domeniului, dar nu blochează toate formele de impersonare. Atacatorul poate folosi un domeniu asemănător ori un nume afișat înșelător. Protecția utilizatorului cere și monitorizare, procese interne și educație.
Google cere pentru expeditorii bulk SPF, DKIM și DMARC și alinierea domeniului From cu SPF ori DKIM. Pentru expeditorii mici, autentificarea rămâne necesară și recomandarea practică este să configurezi toate trei, nu să aștepți pragul.
Yahoo spune în best practices pentru expeditori că încurajează DMARC și separarea traficului bulk de mesajele tranzacționale. Microsoft a anunțat cerințe similare pentru expeditorii cu volum mare către domeniile sale de consum, în comunicarea oficială despre ecosistemul Outlook. Verifică paginile curente înainte de orice migrare, deoarece politicile se schimbă.
Reputația: autentificat nu înseamnă dorit
SPF, DKIM și DMARC răspund la identitate, nu la intenția destinatarului. Un expeditor perfect autentificat poate trimite spam. Furnizorii urmăresc plângeri, bounce, volum, consistență, engagement și istoricul domeniului ori IP-ului. Ponderile nu sunt publice și diferă.
Gmail recomandă menținerea spam rate sub 0,1% și evitarea atingerii a 0,3% sau mai mult, conform FAQ-ului pentru sender guidelines. Aceste valori se citesc în Postmaster Tools pentru traficul relevant și nu trebuie confundate cu procentul din platforma de email. Pragul nu este o țintă acceptabilă; este un semnal de risc.
Volumul brusc este suspect dacă domeniul nu are istoric. Încălzirea nu înseamnă generarea artificială de open-uri prin rețele de conturi. Înseamnă trimiterea progresivă către destinatari reali, care se așteaptă la mesaj, cu monitorizarea erorilor și oprirea creșterii când indicatorii se degradează.
Separă fluxurile cu risc diferit. Mesajele tranzacționale cerute — resetări, confirmări, chitanțe — nu ar trebui să împartă toate resursele și reputația cu newsletterul promoțional. Gmail oferă o definiție operațională pentru subscription messages, iar Yahoo recomandă separarea IP-urilor pentru categorii. Arhitectura exactă depinde de volum și furnizor.
Nu schimba simultan domeniul, IP-ul, volumul și conținutul. Vei pierde baza de comparație. Migrează pe etape, păstrează logurile și un grup de control. Dacă reputația era bună, o mutare prost planificată poate crea problema pe care trebuia să o rezolve.
Lista: sursa cea mai des ignorată
Hard bounce-ul indică o adresă care nu poate primi permanent în contextul răspunsului. Suprimă-l automat. Soft bounce-ul poate semnala o problemă temporară, dar repetarea cere o regulă. Nu reimporta adrese suprimate dintr-un CSV vechi.
Contactele cumpărate, scrape-uite și vechi produc necunoaștere și plângeri. Dovada de opt-in trebuie să lege adresa de sursă, dată și promisiune. Pentru creștere sănătoasă, folosește ghidul despre lista de abonați și evită orice furnizor care vinde „contacte verificate” ca substitut pentru permisiune.
Inactivitatea nu se definește doar prin open. Protecțiile de confidențialitate pot încărca pixelul automat, iar un destinatar poate citi fără imagini. Folosește clic, răspuns, autentificare, comandă și recență. Un client sezonier poate fi legitim chiar dacă nu deschide lunar.
Rulează re-engagement pentru segmentul care are încă o relație justificată, apoi redu frecvența sau suprimă. Nu încerca să „reactivezi” o bază fără proveniență. Un instrument de verificare poate identifica sintaxa și unele riscuri, dar nu poate fabrica permisiune.
Ușurează dezabonarea. One-click unsubscribe pentru mesajele eligibile este definit prin RFC 8058, cu headere și o cerere care nu solicită pași suplimentari. Păstrează și linkul vizibil în corp. Dacă oamenii nu găsesc ieșirea, butonul Spam devine ieșirea.
Conținutul contează, dar nu printr-o listă magică de cuvinte
Cuvinte precum „gratuit” sau multe semne de exclamare pot contribui la percepția mesajului, dar nu există o regulă publică prin care un singur cuvânt trimite automat emailul în spam. Contextul, reputația și reacția destinatarilor cântăresc. Un email autentic despre transport gratuit nu trebuie să folosească eufemisme.
Fii exact în From, subiect și preview. Nu simula un răspuns cu Re: și nu pretinde urgență falsă. Linkurile trebuie să ducă spre domenii așteptate, securizate și consecvente. Scurtătoarele obscure și lanțurile de redirect pot crea neîncredere și complică investigația.
Păstrează o versiune text, alt text pentru imagini și o structură lizibilă fără imagini. Nu trimite un singur screenshot cu textul ofertei. Raportul text–imagine nu este un prag universal, dar accesibilitatea și claritatea sunt controlabile.
Verifică domeniile de tracking. Unele platforme folosesc un domeniu comun; configurarea unui domeniu branded poate alinia experiența și reduce dependența, dacă este făcută corect. Testează toate redirecturile și certificatul TLS.
Conținutul trebuie să corespundă motivului abonării. Un contact care a cerut alerte tehnice și primește reduceri zilnice va reacționa negativ chiar dacă mesajul este impecabil autentificat. Segmentarea este o măsură de livrabilitate pentru că reduce nepotrivirea.
Diagnostic în ordinea care economisește timp
Începe cu un singur mesaj și un singur destinatar afectat. Salvează headerul, logul și codul. Confirmă că platforma a trimis și serverul a acceptat. Abia apoi verifică folderul. Fără această disciplină, echipa schimbă copy-ul pentru o eroare DNS sau DNS-ul pentru un contact suprimat.
Ordinea recomandată este:
- statusul contactului și dreptul de trimitere;
- evenimentul care a declanșat mesajul;
- logul și răspunsul SMTP;
- SPF, DKIM și DMARC în header;
- alinierea domeniilor și reputația în instrumentele furnizorului;
- bounce, spam și dezabonări pe cohortă;
- volum și schimbări recente;
- linkuri, redirecturi și conținut;
- comparație între furnizori și segmente.
Păstrează o cronologie a schimbărilor: DNS, platformă, template, listă, domeniu de tracking, frecvență. Corelația temporală nu dovedește cauza, dar restrânge investigația. Dacă problema a început după import, izolează cohorta importată. Dacă a început după migrare, compară headerele înainte și după.
Nu folosi teste dintr-un singur inbox drept verdict pentru toată lista. Seed testing arată ce s-a întâmplat unor conturi controlate; nu reproduce istoricul fiecărui abonat. Combină-l cu datele reale și cu feedback loop-urile disponibile.
Cum citești un header fără să fii administrator de mail
Headerul este o cronologie inversă. Liniile Received sunt adăugate de serverele prin care a trecut mesajul, de regulă cu cea mai recentă sus. Nu te opri la prima adresă IP pe care o vezi și nu publica headerul integral: poate conține adrese, identificatori și date despre infrastructură. Fă o copie de lucru, maschează datele personale pentru colaborare și păstrează originalul într-un loc controlat.
Caută mai întâi Authentication-Results. Notează rezultatul SPF și domeniul evaluat, rezultatul DKIM și domeniul d=, apoi rezultatul DMARC. Compară aceste domenii cu adresa vizibilă din From. Un pass pe domeniul platformei poate coexista cu DMARC fail dacă nu există aliniere. Nu interpreta SPF pass ca dovadă că tot mesajul este autentificat în numele brandului.
Pentru DKIM, notează selectorul s= și domeniul d=. Folosește-le pentru a căuta cheia publică în DNS. Dacă selectorul nu există, poate fi o publicare greșită, o ștergere prematură sau un mesaj semnat de un flux vechi. Dacă există, dar verificarea eșuează, caută modificarea mesajului pe traseu, formatul cheii și configurația furnizorului. Nu regenera la întâmplare cheia înainte să păstrezi proba.
Pentru SPF, urmărește și Return-Path ori envelope-from. Acesta poate fi diferit de From și poate aparține unui domeniu de bounce administrat de platformă. Verifică dacă domeniul este personalizat și aliniat. Când un serviciu terț trimite în numele tău, cere documentația sa exactă; nu adăuga IP-uri găsite într-un header fără să înțelegi dacă sunt stabile și autorizate de furnizor.
ARC-Authentication-Results și sigiliile ARC pot apărea când mesajul traversează intermediari. Ele ajută receptorul să evalueze autentificarea observată anterior, dar nu sunt motiv să ignori propriul SPF, DKIM și DMARC. Pentru un diagnostic de forwarding, compară mesajul înainte și după intermediar și notează ce antet sau corp s-a modificat.
Rapoartele DMARC agregate completează headerul individual. Ele grupează volume pe surse și rezultate de autentificare. Creează o listă cu IP, reverse DNS dacă există, numărul de mesaje, SPF, DKIM și dispoziția aplicată. Etichetează sursele cunoscute, investighează necunoscutele și nu autoriza automat o sursă doar fiindcă are volum mare; poate reprezenta spoofing.
Un raport agregat nu conține textul emailului și nu dovedește că mesajul a ajuns în inbox. El arată cine a pretins folosirea domeniului și cum a trecut autentificarea. Pentru livrare ai nevoie în continuare de loguri, coduri și instrumentele furnizorului. Rapoartele forensic ori failure pot conține date mai sensibile și disponibilitatea lor diferă; implică echipa de securitate și politica de protecție a datelor.
Încheie analiza cu o fișă scurtă: mesaj, flux, furnizor, domeniu From, envelope-from, DKIM d= și selector, rezultate, cod SMTP, folder, segment și ultima schimbare. Două fișe comparabile — una bună și una afectată — transformă o discuție vagă despre spam într-o investigație reproductibilă.
Plan de remediere fără să agravezi reputația
În primele 24 de ore, oprește sursa evident greșită: flux duplicat, listă fără proveniență, autentificare eșuată sau creștere bruscă. Nu opri mesajele tranzacționale sănătoase fără motiv; separă incidentul. Documentează exact ce ai suspendat.
În următoarele zile, repară autentificarea și verifică fiecare tip de mesaj. Publică DMARC prudent, colectează rapoarte și elimină sursele necunoscute. Curăță hard bounce-urile, dezabonările și plângerile. Izolează cohortele cu risc; nu le amesteca în trimiterea „de încălzire”.
Repornește cu destinatarii cei mai recenți și implicați, la volum controlat. Nu trimite emailuri goale doar pentru engagement. Oferă mesajul pe care oamenii îl așteaptă și urmărește erorile pe furnizor. Crește numai după stabilizare.
În paralel, repară cauza comercială. Dacă oferta atrage abonați nepotriviți, schimbă formularul și sursa. Dacă frecvența depășește promisiunea, aliniaz-o. Dacă automatizările de email se suprapun, implementează priorități și condiții de ieșire.
Nu promite data revenirii în inbox. Reputația se reconstruiește prin comportament consecvent, iar furnizorii nu publică o formulă sau un termen garantat. Raportează ce s-a reparat, ce semnale se îmbunătățesc și ce rămâne neverificabil.
Tabel rapid: simptom, probă, acțiune
| Simptom | Dovada de căutat | Prima acțiune |
|---|---|---|
| mesaj respins | cod SMTP și text complet | rezolvă cauza codului; nu retrimite în buclă |
| SPF fail | header și record DNS | inventariază expeditorii și corectează recordul unic |
| DKIM fail | selector, domeniu, header | verifică cheia și fluxul care a semnat |
| DMARC fail | aliniere SPF/DKIM cu From | repară alinierea înainte de policy strict |
| spam doar la Gmail | Postmaster, cohortă, headers | verifică cerințe și reputația Gmail |
| bounce după import | sursă și vechimea listei | oprește cohorta și validează proveniența |
| plângeri crescute | campanie, formular, promisiune | reduce volumul și repară așteptarea |
| tranzacțional afectat | infrastructura comună | separă fluxul critic și investighează reputația |
Acest tabel nu înlocuiește logurile. El previne însă reacția greșită: schimbarea subiectului când serverul respinge autentificarea sau cumpărarea unui „warm-up” când problema este permisiunea.
Întrebări frecvente
De ce ajung emailurile mele în spam?
Cele mai frecvente familii de cauze sunt autentificarea greșită, reputația slabă, lista fără permisiune ori învechită, volum instabil, plângeri și conținut nepotrivit așteptării. Verifică headerul și logul înainte de concluzii.
SPF, DKIM și DMARC garantează inboxul?
Nu. Ele autentifică și aliniază identitatea. Furnizorul evaluează și reputația, comportamentul destinatarilor, lista, volumul și mesajul.
Folderul Promotions înseamnă spam?
Nu. Este o categorie Gmail pentru anumite mesaje comerciale. Livrarea în Promotions nu este echivalentă cu respingerea sau folderul Spam.
Pot repara livrabilitatea cu un instrument de warm-up?
Nu există o garanție. Rețelele care generează engagement artificial pot masca problema și adăuga risc. Repară autentificarea, permisiunea, lista și volumul, apoi reconstruiește cu destinatari reali.
În cât timp se repară reputația domeniului?
Nu există termen public universal. Depinde de gravitate, furnizor, volum și comportamentul ulterior. Raportează progresul pe semnale și nu promite o dată exactă.