SPF, DKIM și DMARC explicate: de ce ajung emailurile tale în spam

Emailul a fost gândit într-o vreme în care nimeni nu verifica cine trimite, iar protocolul de bază încă lasă orice server să pună orice adresă în câmpul de expeditor. SPF, DKIM și DMARC sunt cele trei înregistrări care rezolvă asta: SPF listează serverele care au voie să trimită pentru domeniul tău, DKIM semnează fiecare mesaj ca să poată fi verificat la sosire, iar DMARC le spune serverelor care primesc ce să facă atunci când verificările eșuează. Din februarie 2024, Gmail și Yahoo le cer tuturor celor care trimit în volum mare, iar Outlook.com din mai 2025. Chiar și sub aceste praguri, un domeniu fără ele e primul care ajunge în spam. Ghidul explică fiecare înregistrare și arată cum arată ale noastre pe levelui.com, levelui.ro și levelui.de.

De ce are nevoie emailul de trei înregistrări

Când sosește un mesaj, serverul care îl primește știe doar ce i-a spus serverul care l-a trimis. Adresa expeditorului e doar text, iar nimic din protocolul original de email nu oprește un străin să-ți scrie adresa acolo. Spammerii și escrocii se bazează exact pe asta, așa că furnizorii de email au învățat să nu aibă încredere în niciun mesaj al cărui domeniu nu poate dovedi că l-a trimis. Dovada stă în DNS-ul domeniului tău, unde doar tu o poți schimba, și are trei părți, fiecare acoperind o gaură lăsată de celelalte.

Asta contează pentru mai mult decât newslettere. Facturile pe care le trimiți, răspunsurile la cereri de ofertă, confirmările de comandă din magazin și notificarea pe care ți-o trimite formularul de contact de pe site sunt toate emailuri de pe domeniul tău. Dacă înregistrările lipsesc sau sunt greșite, oricare dintre ele poate ajunge în spam sau poate fi respins, de obicei fără ca cineva să observe, până când un client spune că n-a primit nimic.

SPF: cine are voie să trimită

SPF, Sender Policy Framework, este o singură înregistrare TXT pe domeniul tău care listează serverele care au voie să trimită email pentru el. A noastră e v=spf1 include:_spf.mail.hostinger.com ~all: emailul pentru levelui.com poate veni de pe serverele pe care le listează furnizorul nostru de email, iar orice altceva trebuie tratat cu suspiciune. Finalul contează. ~all le cere destinatarilor să marcheze restul ca suspect, -all le cere să-l respingă, iar cu DMARC configurat merg amândouă.

Fiecare serviciu care trimite în numele domeniului tău trebuie să fie în această singură înregistrare: căsuța de email, unealta de newsletter, CRM-ul, aplicația de facturare și site-ul, dacă trimite emailuri singur. Două reguli îi prind pe mulți. Un domeniu poate avea o singură înregistrare SPF, așa că a doua, adăugată de un serviciu nou, le strică pe amândouă. Iar SPF permite cel mult 10 interogări DNS la evaluare; fiecare include contează, include-urile din include-uri contează și ele, iar peste 10 verificarea eșuează direct, cu eroare permanentă. A noastră folosește 3 din cele 10: include-ul nostru, plus cele două servicii de relay pe care le include la rândul ei înregistrarea Hostinger.

DKIM: o semnătură care supraviețuiește drumului

DKIM, DomainKeys Identified Mail, adaugă o semnătură digitală fiecărui mesaj. Serverul care trimite semnează antetele importante și conținutul cu o cheie privată și publică cheia publică pereche în DNS, sub un nume numit selector. Serverul care primește ia acea cheie și verifică semnătura: dacă se potrivește, mesajul a fost trimis chiar de cineva care are cheia ta, iar nimic din părțile semnate nu s-a schimbat pe drum.

Spre deosebire de SPF, o semnătură DKIM supraviețuiește redirecționării, pentru că circulă în interiorul mesajului, în loc să depindă de serverul care l-a livrat. Gmail cere expeditorilor în volum mare chei de cel puțin 1.024 de biți; 2.048 e alegerea sensibilă. Ale noastre folosesc selectorul hostingermail1 și chei de 2.048 de biți pe toate trei domeniile. Fiecare serviciu prin care trimiți are nevoie de propria cheie DKIM sub domeniul tău. Dacă o unealtă de newsletter semnează în schimb cu domeniul ei, semnătura e validă, dar nu contează pentru tine, și ăsta e cel mai des motiv pentru care eșuează DMARC.

DMARC: politica ce le leagă pe toate

SPF și DKIM pot trece amândouă în timp ce DMARC eșuează, pentru că DMARC verifică dacă au trecut pentru domeniul din câmpul de expeditor. Condiția asta se numește aliniere. Un newsletter trimis prin serverele unui furnizor și semnat cu domeniul furnizorului trece SPF și DKIM pentru furnizor, nu pentru tine, deci DMARC eșuează pentru domeniul tău. Cel puțin una dintre cele două verificări trebuie să treacă pentru același domeniu pe care îl vede cititorul.

Înregistrarea spune apoi ce se întâmplă cu emailul care eșuează: p=none înseamnă livrează-l și doar raportează, p=quarantine înseamnă pune-l în spam, iar p=reject înseamnă respinge-l. Adresa rua primește zilnic rapoarte agregate de la marii furnizori, cu fiecare server care a trimis ca domeniul tău și dacă a trecut. A noastră e p=quarantine pe toate trei domeniile, iar rapoartele pentru levelui.ro și levelui.de merg la o adresă de pe levelui.com. Trimiterea rapoartelor către alt domeniu funcționează doar dacă acel domeniu e de acord, așa că levelui.com publică mici înregistrări de autorizare numite levelui.ro._report._dmarc.levelui.com și levelui.de._report._dmarc.levelui.com. Fără ele, rapoartele pentru cele două domenii de țară pur și simplu n-ar ajunge.

DMARC a fost revizuit în mai 2026 ca RFC 9989. Revizia renunță la tagul pct, care aplica politica doar unui procent din emailuri, și adaugă un tag t pentru testare. Înregistrările noastre încă au pct=100, care cerea oricum politica completă, așa că pentru ele nu se schimbă nimic.

Ce cer acum Gmail, Yahoo și Outlook

Al doilea tabel de mai sus rezumă totul. Orice expeditor către Gmail sau Yahoo are nevoie cel puțin de SPF sau DKIM, iar oricine trimite 5.000 sau mai multe mesaje pe zi către conturi personale are nevoie de SPF, DKIM și o înregistrare DMARC, cu domeniul expeditorului aliniat și o dezabonare cu un clic în emailurile de marketing. Outlook.com a pus aceeași ștachetă pentru expeditorii în volum mare din 5 mai 2025 și respinge emailurile care eșuează cu eroarea 550 5.7.515. Gmail a înăsprit aplicarea pentru emailurile neconforme în noiembrie 2025.

O firmă mică ce trimite câteva sute de mesaje pe zi e sub pragul de volum mare, dar asta nu e un motiv să sară peste vreuna dintre cele trei. Filtrele care citesc aceste înregistrări rulează la fiecare mesaj, iar un domeniu fără DMARC e și cel mai ușor de falsificat. Configurarea tuturor celor trei durează o oră și nu costă nimic.

Cum le configurezi, în ordine

Începe cu un inventar: fiecare serviciu care trimite emailuri cu domeniul tău în câmpul de expeditor, inclusiv site-ul, magazinul, CRM-ul, unealta de newsletter și programul de facturare. Apoi publici o singură înregistrare SPF care le include pe toate și activezi DKIM în fiecare serviciu, ceea ce de obicei înseamnă să adaugi una sau două înregistrări DNS pe care ți le dă serviciul. Verifică amândouă cu un mesaj de test: în Gmail, „Afișează originalul” arată rezultatul SPF, DKIM și DMARC pentru orice mesaj primit.

Publică DMARC întâi cu p=none, citește rapoartele două până la patru săptămâni și abia apoi înăsprește politica. Rapoartele vor arăta servicii pe care le-ai uitat, cum ar fi un formular de contact vechi sau o unealtă de programări, care încă trimit ca domeniul tău. Rezolvă-le pe fiecare, apoi treci la p=quarantine și la p=reject când rapoartele sunt curate. Cine sare direct la reject din prima zi descoperă un expeditor uitat pierzându-i emailurile.

De ce pot ajunge emailurile tale totuși în spam

Autentificarea dovedește cine a trimis un mesaj; nu face pe nimeni să și-l dorească. Chiar cu toate trei înregistrările trecute, emailul poate ajunge în spam dacă destinatarii îl marchează ca spam, dacă domeniul e nou și nu are istoric de trimitere, dacă mesajul are linkuri spre domenii cu reputație proastă sau dacă serverul de pe care pleacă e pe o listă neagră. Postmaster Tools de la Gmail îți arată gratuit rata de spam și reputația domeniului, după ce îl verifici.

Emailurile trimise de site sunt un vinovat frecvent. Formularele de contact de pe hosting shared trimit des prin serverul web însuși, nu prin căsuța ta de email, de pe un server pe care înregistrarea SPF nu îl listează și fără semnătura ta DKIM. Trimiterea emailurilor din formular prin SMTP, prin căsuța ta reală, rezolvă problema. Dacă alegi un domeniu pentru o firmă nouă, merită citit întâi ghidul nostru despre cum alegi un nume de domeniu, iar dacă site-ul stă pe hosting shared, VPS vs hosting shared explică ce poate și ce nu poate face acel cont.

Un ultim pas: logoul tău în inbox

Odată ce DMARC e pe quarantine sau reject, o a patra înregistrare, numită BIMI, poate indica logoul tău, iar unii furnizori de email îl afișează lângă mesajele tale. Al nostru e activ pe toate trei domeniile. Yahoo și AOL îl afișează doar pe baza înregistrării; Gmail și Apple Mail afișează un logo doar cu un certificat plătit în plus. Nu e necesar pentru livrare, dar e o mică recompensă vizibilă pentru că celelalte trei sunt corecte.

Surse

Cerințele sunt din paginile fiecărui furnizor de email, iar formatele înregistrărilor din standardele publicate, verificate pe 28 octombrie 2026. Înregistrările noastre au fost citite din DNS-ul public în aceeași zi.

• Ajutor pentru administratori Google Workspace — Reguli pentru expeditorii de email ↗

  Cerințe pentru toți expeditorii și pentru cei cu peste 5.000 de mesaje pe zi; chei DKIM de cel puțin 1.024 de biți; rată de spam sub 0,3%; eroarea 5.7.26.

• Ajutor pentru administratori Google Workspace — Întrebări despre regulile pentru expeditori ↗

  Gmail înăsprește aplicarea pentru traficul neconform din noiembrie 2025.

• Yahoo Sender Hub — Bune practici pentru expeditori ↗

  Cerințe pentru toți expeditorii și pentru cei în volum mare din februarie 2024; dezabonările respectate în 2 zile. În engleză.

• Asistență Microsoft — Remedierea erorii NDR 550 5.7.515 în Outlook.com ↗

  Cerințele pentru expeditorii cu peste 5.000 de mesaje pe zi către emailul Microsoft pentru consumatori. În engleză.

• RFC 7208 — Sender Policy Framework (SPF) ↗

  Secțiunea 4.6.4: cel mult 10 termeni cu interogări DNS, altfel eroare permanentă. În engleză.

• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures ↗

  Cum funcționează semnătura și înregistrarea selectorului. În engleză.

• RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) ↗

  Publicat în mai 2026 ca standard; înlocuiește RFC 7489 și renunță la tagul pct. În engleză.

• RFC 7489 — DMARC, secțiunea 7.1 ↗

  Definiția originală a înregistrării de autorizare pentru rapoartele trimise către alt domeniu. În engleză.