SPF, DKIM, DMARC: de ce emailurile tale ajung la spam și cum repari asta

6 octombrie 2026
Securitate WordPress
32 min read

Îți scrie un client: „Am trimis oferta acum trei zile, de ce nu mi-ați răspuns?”. Te uiți în căsuța de email trimise — e acolo, plecată la oră exactă, cu atașamentul corect. Doar că omul de la celălalt capăt n-a văzut-o niciodată. A ajuns în Spam, între o reclamă la pastile miraculoase și un „prinț nigerian” cu o moștenire de împărțit. Sau, mai rău, a fost respinsă discret, fără să afli vreodată.

Asta e una dintre cele mai frustrante probleme cu care vin oamenii la mine, pentru că nu se vede. Site-ul pică — afli în cinci minute. Emailul ajunge la spam — afli după săptămâni, poate niciodată, din comenzi pierdute, oferte ignorate și clienți care cred că nu-ți pasă. Iar în 2026, problema e mai mare decât oricând: Gmail, Yahoo și Microsoft au strâns serios regulile, iar emailurile care „mergeau” acum doi-trei ani pur și simplu nu mai trec.

Vestea bună: în aproape toate cazurile pe care le-am văzut, cauza ține de trei înregistrări DNS cu nume urâte — SPF, DKIM și DMARC — plus câteva setări greșite în WordPress. Nu trebuie să fii programator ca să înțelegi ce fac. Trebuie doar să înțelegi ideea din spate, iar restul e o listă de verificare. Exact asta îți propun în articolul de față: explicația pe înțelesul oricui, apoi pașii concreți.

Cuprins:

Cum funcționează, de fapt, un email: analogia cu plicul

Ca să înțelegi de ce emailurile ajung la spam, trebuie să știi un lucru care surprinde pe aproape toată lumea: protocolul de email a fost inventat într-o vreme în care nimeni nu se gândea că oamenii vor minți. SMTP, sistemul prin care circulă emailurile între servere, vine de la începutul anilor ’80, când internetul era o rețea mică de universități și institute de cercetare, unde toată lumea se cunoștea. Nimeni nu verifica cine trimite. Pur și simplu se avea încredere.

Gândește-te la un email ca la o scrisoare clasică, într-un plic. Pe plic scrie o adresă de expeditor — cea pe care o folosește poșta ca să-ți returneze scrisoarea dacă nu poate fi livrată. În interior, pe foaia propriu-zisă, scrie din nou un „De la:”, cu numele și adresa pe care le vede destinatarul când deschide scrisoarea. Lucrul interesant e că cele două pot fi diferite. Și, în varianta originală a emailului, nimeni nu verifica niciuna dintre ele.

În termeni tehnici, adresa de pe plic se numește envelope sender sau Return-Path — e adresa la care se întorc mesajele de eroare („bounce”). Adresa de pe foaie se numește header From — e ce vezi tu în Gmail sau Outlook, în dreptul numelui expeditorului. Poți scrie, tehnic, orice în oricare dintre ele. Asta înseamnă că oricine, de oriunde, poate trimite un email care pare să vină de la contact@firmata.ro, fără să aibă acces la contul tău de email.

Exact pe această slăbiciune se bazează phishing-ul, fraudele cu facturi false („v-am schimbat contul IBAN, plătiți aici”) și o bună parte din spam. Iar furnizorii mari de email — Google, Microsoft, Yahoo — au ajuns la concluzia firească: dacă nu pot verifica că un mesaj vine cu adevărat de la cine pretinde, îl tratează cu suspiciune. Adică îl pun la spam. Sau îl resping.

SPF, DKIM și DMARC sunt cele trei „petice” adăugate de-a lungul anilor peste sistemul original, ca să rezolve exact problema asta. Fiecare verifică altceva:

  • SPF verifică dacă serverul care a trimis mesajul are voie să trimită pentru domeniul de pe plic.
  • DKIM verifică dacă mesajul poartă o semnătură digitală validă a unui domeniu și dacă n-a fost modificat pe drum.
  • DMARC verifică dacă domeniul pe care îl vede omul (de pe foaie) se potrivește cu cel verificat de SPF sau DKIM, și spune ce să se întâmple dacă nu se potrivește.

Le luăm pe rând, imediat. Dar înainte, merită să înțelegi de ce, chiar dacă nu ești ținta niciunei fraude, emailurile tale legitime pot fi tratate ca suspecte.

De ce ajung emailurile tale la spam

Filtrele anti-spam moderne nu se uită la un singur lucru. Calculează un fel de „scor de încredere” din zeci de semnale, iar fiecare furnizor are propria rețetă, secretă. Dar câteva semnale contează mult mai mult decât celelalte, iar autentificarea e, de departe, pe primul loc.

Autentificarea lipsă sau greșită. Dacă domeniul tău nu are SPF, DKIM și DMARC configurate corect, serverul care primește mesajul nu are cum să știe dacă emailul e de la tine sau de la un impostor. În 2026, pentru Gmail, Yahoo și Outlook, un mesaj neautentificat e, din start, un mesaj suspect. Nu contează cât de frumos e scris.

Reputația serverului care trimite. Fiecare adresă IP de pe care pleacă emailuri are o reputație, construită în timp. Dacă site-ul tău e pe un hosting ieftin, partajat cu sute de alte site-uri, iar unul dintre ele a fost spart și trimite spam, reputația IP-ului comun scade — și o plătești și tu. E ca și cum ai locui într-un bloc unde un vecin face scandal în fiecare noapte: poliția începe să se uite cu suspiciune la toată scara.

Reputația domeniului. Pe lângă IP, contează și istoricul domeniului tău. Un domeniu nou, care începe brusc să trimită sute de emailuri pe zi, ridică semne de întrebare. Un domeniu care a fost folosit vreodată pentru spam (de exemplu, după ce cineva a spart un formular de contact și a trimis mii de mesaje prin el) poate rămâne „pătat” luni de zile.

Comportamentul destinatarilor. Gmail urmărește ce fac oamenii cu mesajele tale: le deschid, le șterg fără să le citească, le marchează ca spam? Dacă destul de mulți oameni apasă „Raportează spam”, toate mesajele tale viitoare vor avea de suferit. Acesta e motivul pentru care newsletterele trimise către liste cumpărate sau vechi sunt atât de periculoase pentru reputație.

Conținutul mesajului. Contează, dar mult mai puțin decât cred oamenii. Mitul „nu scrie cuvântul GRATUIT că intri la spam” e în mare parte depășit. Filtrele moderne se uită mai degrabă la tipare: un mesaj doar cu o imagine mare și fără text, linkuri scurtate dubioase, atașamente executabile, HTML stricat, discrepanțe între textul afișat al unui link și adresa reală.

Infrastructura tehnică. Detalii pe care omul obișnuit nu le vede niciodată: dacă IP-ul serverului are o înregistrare reverse DNS (PTR) corectă, dacă serverul se prezintă cu un nume valid, dacă suportă conexiuni criptate (TLS). Fiecare lipsă scade scorul.

Din toate acestea, autentificarea e partea pe care o controlezi complet, care nu costă aproape nimic și care are cel mai mare impact. De aceea începem cu ea.

SPF: lista celor care au voie să trimită în numele tău

SPF vine de la Sender Policy Framework. Ideea e foarte simplă: tu, ca proprietar al domeniului, publici în DNS o listă cu serverele care au voie să trimită emailuri în numele tău. Când un server primește un mesaj, se uită la domeniul de pe „plic” (Return-Path), caută lista SPF a acelui domeniu și verifică dacă IP-ul expeditorului e pe listă.

Gândește-te la SPF ca la lista de invitați de la intrarea unui eveniment. Paznicul nu știe cine ești, dar are o listă primită de la organizator. Dacă ești pe listă, intri. Dacă nu, ai o problemă.

Tehnic, SPF e o înregistrare DNS de tip TXT, pusă direct pe domeniu, care arată cam așa:

v=spf1 a mx include:_spf.google.com include:spf.brevo.com ~all

Pe bucăți, asta înseamnă:

  • v=spf1 — „aceasta este o înregistrare SPF, versiunea 1”. Obligatoriu, mereu la început.
  • a — serverul la care duce domeniul (de obicei cel al site-ului) are voie să trimită.
  • mx — serverele care primesc emailurile domeniului au voie și să trimită.
  • include:_spf.google.com — „consultă și lista Google” — necesar dacă folosești Google Workspace pentru email.
  • include:spf.brevo.com — la fel, pentru un serviciu de newsletter sau email tranzacțional (aici, Brevo, ca exemplu).
  • ~all — „orice altceva, tratează-l ca suspect”.

Ultima parte merită o explicație separată, pentru că e sursa multor confuzii. Există trei variante uzuale:

  • -all (cu minus, „hard fail”) — „orice server care nu e pe listă NU are voie”. Cea mai strictă.
  • ~all (cu tildă, „soft fail”) — „orice server care nu e pe listă probabil nu are voie, tratează cu suspiciune”. Cea mai folosită.
  • ?all (neutru) — „nu spun nimic despre ceilalți”. Practic inutil.

Există și +all, care înseamnă „oricine are voie să trimită în numele meu”. Dacă vezi asta în DNS-ul tău, șterge-o imediat: e ca și cum ai pune un afiș la intrare pe care scrie „Lista de invitați: toată lumea”. Am întâlnit-o de mai multe ori decât mi-ar plăcea să recunosc, de obicei pusă de cineva care „a vrut doar să meargă emailurile”.

Care e mai bună, -all sau ~all? În practică, de când există DMARC, diferența contează mai puțin decât pare. Majoritatea furnizorilor mari se bazează pe DMARC pentru decizia finală. Recomandarea mea pentru afacerile mici: începe cu ~all, iar după ce ai DMARC configurat și ai verificat rapoartele, poți trece la -all dacă vrei.

Trei reguli SPF pe care trebuie să le știi, pentru că le încalcă aproape toată lumea:

1. Un singur SPF pe domeniu. Nu poți avea două înregistrări TXT care încep cu „v=spf1”. Dacă ai două, SPF-ul e invalid în întregime — ca și cum n-ai avea niciunul. Asta se întâmplă foarte des: cineva configurează Google Workspace și adaugă un SPF nou, fără să observe că hostingul pusese deja unul. Soluția: le combini într-unul singur, cu toate „include”-urile la un loc.

2. Maximum 10 interogări DNS. Fiecare „include”, „a”, „mx” și altele asemenea obligă serverul care verifică să facă o căutare DNS suplimentară — iar „include”-urile pot conține, la rândul lor, alte „include”-uri. Standardul permite maximum 10 astfel de căutări. Dacă le depășești, SPF-ul dă eroare („permerror”) și e tratat ca invalid. Cu Google Workspace, un serviciu de newsletter, un CRM, un sistem de facturare care trimite emailuri și hostingul, ajungi la limită mai repede decât crezi.

3. SPF verifică „plicul”, nu ce vede omul. Acesta e detaliul cel mai puțin înțeles. SPF se uită la domeniul din Return-Path, nu la cel din „De la:”. Dacă folosești un serviciu de newsletter, acesta poate pune propriul domeniu pe plic — iar SPF va trece, dar pentru domeniul lor, nu pentru al tău. Aici intră în scenă DMARC și conceptul de „aliniere”, despre care vorbim mai jos.

Mai e o limitare importantă a SPF: nu supraviețuiește redirecționării. Dacă trimiți un email către cineva care are o redirecționare automată către Gmail, serverul care face redirecționarea devine, tehnic, noul expeditor — iar IP-ul lui nu e pe lista ta SPF. Rezultat: SPF eșuează, deși mesajul e perfect legitim. Din acest motiv SPF singur nu e suficient și avem nevoie și de DKIM.

DKIM: semnătura care dovedește că mesajul nu a fost modificat

DKIM vine de la DomainKeys Identified Mail. Dacă SPF e lista de invitați de la intrare, DKIM e sigiliul de ceară de pe plic. Nu contează pe ce drum a venit scrisoarea sau prin câte mâini a trecut — dacă sigiliul e intact și e al tău, destinatarul știe că mesajul vine de la tine și că nimeni nu l-a deschis și modificat pe drum.

Funcționează cu o pereche de chei criptografice. Serverul tău de email are o cheie privată, secretă, cu care „semnează” fiecare mesaj trimis. Semnătura se adaugă într-un antet invizibil al emailului, numit DKIM-Signature. În DNS-ul domeniului tău publici cheia publică corespunzătoare. Serverul care primește mesajul ia cheia publică din DNS și verifică semnătura. Dacă se potrivește, înseamnă două lucruri: mesajul a fost semnat de cineva care deține cheia privată a domeniului tău și conținutul nu a fost modificat după semnare.

Înregistrarea DKIM e tot o înregistrare TXT, dar nu stă direct pe domeniu, ci pe un subdomeniu special, de forma:

selector._domainkey.firmata.ro

„Selectorul” e un nume ales de cel care configurează DKIM — de exemplu google pentru Google Workspace, default pentru multe servere cPanel, sau ceva de genul s1, brevo1 pentru serviciile externe. Selectorul există pentru că un domeniu poate avea mai multe chei DKIM simultan — câte una pentru fiecare serviciu care trimite în numele lui. Asta e o diferență importantă față de SPF: SPF poate fi unul singur, DKIM poate fi câte unul pentru fiecare serviciu, fără să se încurce între ele.

Conținutul înregistrării arată cam așa (prescurtat, cheia reală e mult mai lungă):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Nu trebuie să înțelegi nimic din șirul acela lung de caractere. Important e să știi de unde îl iei: întotdeauna de la serviciul care trimite emailurile. Google Workspace ți-l generează în consola de administrare. cPanel îl generează automat în secțiunea „Email Deliverability”. Serviciile de newsletter și email tranzacțional ți-l dau în pagina de configurare a domeniului. Tu doar îl copiezi în DNS, exact cum ți-l dau, fără să modifici niciun caracter.

De ce DKIM e mai robust decât SPF: semnătura călătorește odată cu mesajul. Dacă emailul e redirecționat, semnătura rămâne în el, iar destinatarul final o poate verifica în continuare. Singura excepție: dacă cineva modifică mesajul pe drum — de exemplu, o listă de discuții care adaugă un subsol la fiecare mesaj, sau un antivirus care rescrie linkurile — semnătura se poate invalida.

Câteva recomandări practice pentru DKIM:

  • Folosește chei de 2048 de biți. Cheile de 1024 de biți sunt considerate tot mai slabe, iar unii furnizori le tratează deja cu suspiciune. Unele panouri DNS mai vechi au probleme cu înregistrări TXT foarte lungi — în acest caz, cheia se împarte în mai multe bucăți între ghilimele, iar furnizorul de DNS le lipește la loc automat.
  • Configurează DKIM pentru fiecare serviciu care trimite: emailul de firmă, newsletterul, platforma de facturare, CRM-ul, magazinul online. Fiecare trebuie să semneze cu domeniul tău, nu cu al lui.
  • Rotește cheile din când în când — o dată pe an e o practică bună pentru o afacere mică. Selectorii fac asta ușor: publici o cheie nouă cu un selector nou, muți semnarea pe ea, apoi o retragi pe cea veche.

DMARC: regula care leagă totul și îți spune ce se întâmplă

Avem SPF, care verifică serverul. Avem DKIM, care verifică semnătura. De ce ne mai trebuie ceva? Pentru că, așa cum am văzut, niciunul dintre ele nu verifică direct adresa pe care o vede omul — „De la:”-ul. Un escroc poate trimite un mesaj cu „De la: contabilitate@firmata.ro”, de pe propriul lui domeniu pe plic, semnat DKIM cu propriul lui domeniu. SPF trece (pentru domeniul escrocului). DKIM trece (pentru domeniul escrocului). Iar omul vede numele firmei tale.

DMARC (Domain-based Message Authentication, Reporting and Conformance) rezolvă exact gaura asta. Face trei lucruri:

1. Cere aliniere. Un mesaj trece de DMARC doar dacă SPF sau DKIM trec și domeniul verificat de ele se potrivește cu domeniul din „De la:”. Explic pe larg în secțiunea următoare, pentru că e partea cea mai importantă.

2. Spune ce să se facă cu mesajele care pică testul. Tu, ca proprietar al domeniului, decizi: „lasă-le să treacă, doar raportează-mi” (none), „pune-le la spam” (quarantine) sau „respinge-le de tot” (reject).

3. Îți trimite rapoarte. Furnizorii mari îți trimit zilnic rapoarte despre toate mesajele care au circulat cu domeniul tău în „De la:” — de pe ce servere, câte au trecut, câte au picat. E singurul mod prin care poți afla că cineva trimite emailuri în numele tău fără să știi.

Înregistrarea DMARC e tot un TXT, pus pe subdomeniul _dmarc:

_dmarc.firmata.ro

Cu un conținut de genul:

v=DMARC1; p=none; rua=mailto:dmarc@firmata.ro; fo=1

Pe bucăți:

  • v=DMARC1 — versiunea, obligatoriu la început.
  • p=none — politica: deocamdată doar monitorizare, nu bloca nimic.
  • rua=mailto:… — adresa la care primești rapoartele agregate zilnice.
  • fo=1 — opțiune pentru rapoartele de eroare (acceptată de puțini furnizori, dar nu strică).

Alte etichete utile, pe care le poți întâlni:

  • sp= — politica pentru subdomenii (dacă vrei să fie diferită de cea a domeniului principal).
  • pct= — procentul de mesaje la care se aplică politica (util la trecerea treptată spre „reject”).
  • adkim= și aspf= — cât de strictă e alinierea (r = relaxată, s = strictă). Implicit e relaxată, și așa recomand s-o lași.

Despre politici, pe scurt și sincer: „p=none” nu protejează nimic. E o etapă de observație. Îți spune ce se întâmplă, dar nu oprește un escroc să trimită mesaje în numele tău. Protecția reală vine abia cu „p=quarantine” sau „p=reject”. Dar nu sări direct acolo: dacă ai un serviciu legitim pe care l-ai uitat (sistemul de facturare, de exemplu) și nu e configurat corect, „reject” îl va bloca și pe el. Drumul corect e: none → analizezi rapoartele câteva săptămâni → repari ce lipsește → quarantine → reject.

Despre rapoarte: vin în format XML, comprimat, și nu sunt făcute pentru oameni. Dacă deschizi unul, vei vedea o grămadă de cifre și adrese IP. Pentru o afacere mică, soluția practică e un serviciu care le primește și le transformă în grafice lizibile — există variante gratuite pentru volume mici. Sau, desigur, cineva care se ocupă de asta pentru tine.

Alinierea: detaliul pe care îl ratează aproape toată lumea

Dacă reții un singur lucru din acest articol, să fie acesta: nu e suficient ca SPF și DKIM să „treacă”. Trebuie să treacă pentru domeniul tău.

Să luăm un exemplu concret. Trimiți un newsletter printr-un serviciu extern. Mesajul are „De la: noutati@firmata.ro”. Dar, dacă n-ai configurat nimic special, serviciul pune pe plic propriul lui domeniu (ceva de genul bounces.serviciul.com) și semnează DKIM tot cu domeniul lui. Ce vede serverul destinatarului?

  • SPF: trece — dar pentru serviciul.com, nu pentru firmata.ro.
  • DKIM: trece — dar pentru serviciul.com, nu pentru firmata.ro.
  • DMARC: pică — pentru că niciunul nu e aliniat cu domeniul din „De la:”.

Asta e situația în care oamenii îmi spun, sincer nedumeriți: „Dar am verificat, SPF e PASS, DKIM e PASS, de ce intră la spam?”. Pentru că PASS-ul e al altcuiva.

Alinierea relaxată (cea implicită) înseamnă că e suficient să se potrivească domeniul principal. Adică un mesaj cu „De la: contact@firmata.ro” e aliniat și dacă semnătura DKIM vine de la mail.firmata.ro sau plicul e pe bounces.firmata.ro. Aceasta e cheia: serviciile externe serioase îți permit să configurezi un subdomeniu al tău pentru plic și să semneze DKIM cu domeniul tău. Se numește, de obicei, „autentificarea domeniului” sau „domeniu de expediere personalizat” în setările serviciului.

Regula practică: pentru fiecare serviciu care trimite emailuri cu adresa ta în „De la:”, verifică dacă e configurat să semneze DKIM cu domeniul tău. DKIM aliniat e mai valoros decât SPF aliniat, pentru că supraviețuiește redirecționărilor. Ideal le ai pe amândouă, dar DMARC trece și dacă doar una dintre ele e aliniată.

Noile reguli Gmail, Yahoo și Microsoft: ce s-a schimbat

Mult timp, SPF, DKIM și DMARC au fost „recomandări bune”. Le aveai, era bine. Nu le aveai, emailurile tot ajungeau, de cele mai multe ori. Asta s-a terminat.

Din februarie 2024, Google și Yahoo au introdus cerințe obligatorii pentru expeditori. Pe scurt:

Pentru oricine trimite emailuri către adrese Gmail sau Yahoo:

  • trebuie să ai cel puțin SPF sau DKIM configurat pentru domeniul tău;
  • serverul care trimite trebuie să aibă reverse DNS (PTR) valid;
  • conexiunea trebuie să folosească TLS (criptare);
  • rata de reclamații de spam trebuie să rămână mică — sub 0,3%, iar recomandarea e sub 0,1%.

Pentru expeditorii de volum mare (în jur de 5.000 de mesaje pe zi către Gmail):

  • SPF și DKIM, ambele;
  • DMARC publicat, cel puțin cu „p=none”;
  • alinierea „De la:” cu SPF sau DKIM;
  • dezabonare cu un singur clic pentru mesajele de marketing, procesată în maximum două zile.

În 2025, Microsoft a anunțat cerințe similare pentru Outlook.com, Hotmail și Live.com, pentru expeditorii de volum mare. Iar în ultimul an, aplicarea a devenit tot mai strictă: unde înainte mesajele neconforme ajungeau la spam, acum tot mai multe sunt pur și simplu respinse, cu un mesaj de eroare care menționează explicit autentificarea.

„Dar eu nu trimit 5.000 de emailuri pe zi” — e ce aud cel mai des. Adevărat, pragul de volum mare nu te privește direct. Dar două lucruri contează. Primul: cerințele de bază (SPF sau DKIM, PTR, TLS) se aplică tuturor. Al doilea: chiar dacă regulile oficiale nu te obligă, filtrele tratează din ce în ce mai suspicios orice domeniu fără autentificare completă. În practică, în 2026, SPF + DKIM + DMARC sunt minimul de igienă pentru orice domeniu de firmă, indiferent de volum.

De ce emailurile trimise de WordPress ajung la spam

Până acum am vorbit despre emailul de firmă în general. Dar dacă ai un site WordPress — mai ales un magazin WooCommerce — mai ai o sursă de emailuri, adesea uitată: site-ul însuși. Confirmări de comandă, facturi, resetări de parolă, notificări de la formularul de contact, mesaje de bun venit pentru conturi noi. Toate pleacă de pe site, iar foarte des sunt primele care ajung la spam.

Motivul e tehnic, dar ușor de înțeles. În configurația implicită, WordPress trimite emailuri folosind funcția mail() din PHP, adică direct de pe serverul pe care stă site-ul, fără nicio autentificare. Asta creează câteva probleme simultan:

1. Serverul site-ului nu e neapărat pe lista SPF. Dacă emailul de firmă e pe Google Workspace sau Microsoft 365, iar site-ul e pe un hosting separat, IP-ul hostingului probabil nu apare în SPF. Rezultat: SPF pică.

2. Lipsește semnătura DKIM. Funcția mail() din PHP nu semnează nimic. Dacă serverul de hosting nu adaugă el semnătura (unele o fac, altele nu), mesajul pleacă nesemnat.

3. Adresa de expeditor e una generică. Implicit, WordPress trimite de la wordpress@domeniultau.ro — o adresă care adesea nici nu există. Unele pluginuri pun adrese și mai ciudate.

4. Plicul poate purta numele serverului, nu al domeniului. Pe hostingurile partajate, Return-Path-ul poate ajunge să fie ceva de genul utilizator@server123.hosting.ro, care nu are nicio legătură cu domeniul tău. Alinierea SPF devine imposibilă.

5. Reputația IP-ului partajat. Pe un hosting partajat, aceeași adresă IP trimite emailuri pentru zeci sau sute de site-uri. Dacă unul dintre ele e compromis și trimite spam, pătează reputația tuturor.

Rezultatul practic îl știi: clientul plasează comanda, nu primește confirmarea, crede că n-a mers, mai comandă o dată sau sună nervos. Sau, mai rău, uită de tine. Un client care nu-și poate reseta parola nu mai revine.

Soluția: trimiterea prin SMTP autentificat. În loc să lași WordPress să trimită „pe cont propriu”, îl configurezi să trimită printr-un server de email real, cu autentificare. Concret, instalezi un plugin SMTP — FluentSMTP (gratuit, fără funcții blocate în versiunea plătită) sau WP Mail SMTP sunt cele mai folosite — și îl conectezi la una dintre aceste variante:

  • Contul tău de email de firmă (Google Workspace, Microsoft 365 sau emailul din hosting). Merge pentru site-uri mici, cu puține emailuri. Atenție la limitele zilnice de trimitere ale contului.
  • Un serviciu de email tranzacțional — Amazon SES, Brevo, Postmark, Mailgun, SendGrid și altele. Gândite exact pentru emailurile automate ale aplicațiilor, cu reputație bună a IP-urilor, statistici de livrare și DKIM pe domeniul tău. Pentru orice magazin online, asta e varianta recomandată.

Indiferent de variantă, pașii sunt aceiași: adaugi serviciul în SPF, configurezi DKIM cu domeniul tău, setezi în plugin o adresă de expeditor reală de pe domeniul tău (de exemplu comenzi@firmata.ro) și trimiți un email de test.

Un bonus important al pluginurilor SMTP: au jurnal de emailuri. Vezi fiecare email trimis de site, când a plecat și dacă a dat eroare. Când un client spune „n-am primit factura”, nu mai ghicești — te uiți în jurnal.

Formularul de contact care se „falsifică” singur

Aceasta e o greșeală atât de frecventă încât merită o secțiune separată. O văd, fără exagerare, pe aproape jumătate dintre site-urile pe care le preiau.

Un vizitator completează formularul de contact: numele, adresa lui de email (să zicem ion.popescu@gmail.com), mesajul. Formularul trimite un email către tine. Iar mulți oameni configurează formularul astfel încât emailul să pară că vine de la ion.popescu@gmail.com — „ca să pot da direct Reply”.

Doar că, din punctul de vedere al Gmail-ului tău, s-a întâmplat ceva foarte suspect: a sosit un mesaj care pretinde că e de la o adresă @gmail.com, dar a fost trimis de pe serverul site-ului tău, care evident nu e un server Google. Gmail are DMARC cu politică strictă. Mesajul pică autentificarea. Și ajunge la spam — sau e respins de tot.

Practic, formularul tău de contact se comportă exact ca un escroc care falsifică adrese. Nu e intenționat, dar filtrul nu are cum să știe asta.

Soluția corectă:

  • „De la:” (From) — mereu o adresă de pe domeniul tău, de exemplu formular@firmata.ro sau site@firmata.ro.
  • „Răspunde la:” (Reply-To) — adresa vizitatorului, preluată din câmpul completat de el.

Așa, mesajul trece de autentificare (e trimis legitim în numele domeniului tău), iar când apeși „Reply”, răspunsul pleacă direct către vizitator. Toate formularele serioase — Fluent Forms, Contact Form 7, Gravity Forms, WPForms — permit setarea separată a acestor două câmpuri. Durează două minute.

Configurarea pas cu pas: de la zero la DMARC activ

Pasul 1: Fă inventarul. Notează fiecare loc din care pleacă emailuri cu domeniul tău în „De la:”: emailul de firmă, site-ul WordPress, magazinul, newsletterul, platforma de facturare, CRM-ul, sistemul de programări. Acesta e pasul pe care îl sare toată lumea și din cauza căruia, mai târziu, „nu mai merg facturile”.

Pasul 2: Află unde e DNS-ul tău. Nu neapărat unde ai cumpărat domeniul. DNS-ul poate fi la registrar, la hosting sau la un serviciu precum Cloudflare. Verifici ce „nameservere” are domeniul — acolo faci modificările.

Pasul 3: Construiește un singur SPF. Pornești de la v=spf1, adaugi câte un „include” (sau IP) pentru fiecare serviciu din inventar, folosind exact valorile din documentația lor, și închei cu ~all. Dacă există deja un SPF, îl editezi, nu adaugi altul.

Pasul 4: Activează DKIM pentru fiecare serviciu. În fiecare platformă cauți „Domain authentication” sau „DKIM”, generezi cheia și o pui în DNS exact cum ți-e dată. În cPanel, secțiunea Email Deliverability arată starea SPF și DKIM pentru fiecare domeniu și, de cele mai multe ori, le poate repara cu un clic, dacă DNS-ul e pe același server.

Pasul 5: Configurează WordPress să trimită prin SMTP, cu un plugin precum FluentSMTP, de la o adresă reală de pe domeniul tău. Repară formularele de contact (From = domeniul tău, Reply-To = vizitatorul).

Pasul 6: Publică DMARC în modul de monitorizare: v=DMARC1; p=none; rua=mailto:dmarc@firmata.ro, cu o adresă (sau un serviciu de analiză) care chiar primește rapoartele.

Pasul 7: Analizează rapoartele două-patru săptămâni. Cauți surse legitime care pică (un serviciu uitat, de obicei) și le repari. Sursele necunoscute, din țări în care nu ai treabă, sunt de obicei încercări de falsificare — exact ce vrei să blochezi.

Pasul 8: Strânge șurubul. Treci la p=quarantine, eventual cu pct=25 la început, apoi 100. După încă câteva săptămâni fără probleme, p=reject. Abia acum domeniul tău e protejat cu adevărat împotriva falsificării.

Un detaliu despre DNS: modificările nu sunt instantanee. În funcție de setările de cache (TTL), pot dura de la câteva minute la câteva ore. Nu intra în panică dacă testul de imediat după modificare încă arată valoarea veche.

Cum verifici dacă totul funcționează

Gmail, „Afișează originalul”. Trimite-ți un email la o adresă Gmail, deschide-l, apasă cele trei puncte și alege „Afișează originalul”. Sus apar trei rânduri: SPF, DKIM, DMARC, fiecare cu PASS sau FAIL, plus domeniul verificat. Vrei PASS la toate trei, cu domeniul tău.

mail-tester.com. Îți dă o adresă temporară, trimiți un email la ea și primești o notă din 10, cu explicații pentru fiecare problemă. Fă testul și pentru emailul de firmă, și pentru un email trimis de site (formularul de contact sau o comandă de test).

MXToolbox verifică înregistrările SPF, DKIM și DMARC, numără interogările SPF și verifică dacă IP-ul tău apare pe liste negre.

Google Postmaster Tools. Dacă trimiți volume mai mari către Gmail, îți arată reputația domeniului, rata de spam și erorile de autentificare, direct din perspectiva Google.

Greșelile pe care le văd cel mai des

  • Două înregistrări SPF — una de la hosting, una de la Google. Ambele devin invalide.
  • Peste 10 interogări SPF, după ani de servicii adăugate și niciunul șters.
  • Servicii vechi rămase în SPF, deși nu le mai folosești de ani de zile. Fiecare e o ușă lăsată deschisă.
  • DKIM configurat doar pentru emailul de firmă, nu și pentru newsletter, facturare sau site.
  • DMARC cu „p=none” lăsat așa pentru totdeauna, cu rapoarte trimise la o adresă pe care n-o citește nimeni.
  • Sărit direct la „p=reject” fără monitorizare — și apoi facturile nu mai ajung la clienți.
  • Formulare de contact care falsifică adresa vizitatorului, discutate mai sus.
  • Ghilimele, spații sau caractere în plus copiate greșit în DNS. Un singur caracter lipsă din cheia DKIM o invalidează.
  • Schimbarea hostingului sau a furnizorului de email fără actualizarea DNS-ului. SPF-ul încă indică serverul vechi, DKIM-ul folosește cheia veche.

Dincolo de SPF, DKIM și DMARC: reputație, liste negre și conținut

Autentificarea e fundația, dar nu garantează inbox-ul. Câteva lucruri suplimentare contează:

Reverse DNS (PTR). IP-ul serverului care trimite trebuie să aibă un nume asociat, iar acel nume trebuie să indice înapoi către același IP. Pe hostingurile serioase e configurat; pe un VPS administrat de tine, e treaba ta.

Listele negre. Spamhaus și altele țin evidența IP-urilor și domeniilor care trimit spam. Dacă apari pe una, multe servere îți vor respinge mesajele direct. Cauza e aproape mereu un site compromis sau un formular abuzat — deci securitatea site-ului și livrabilitatea emailului sunt legate direct.

Lista de destinatari. Trimite doar celor care au cerut, curăță adresele care dau eroare și oferă dezabonare ușoară. O listă cumpărată distruge reputația în câteva zile.

Conținutul. Echilibru text-imagini, linkuri către domenii cu reputație bună, fără scurtători dubioși, fără atașamente executabile, și o versiune text pe lângă HTML.

BIMI și MTA-STS, pentru cei care vor să meargă mai departe: BIMI îți afișează logo-ul lângă mesaj în unele aplicații de email, dar cere DMARC la nivel „quarantine” sau „reject” (și, pentru Gmail, un certificat special). MTA-STS forțează livrarea criptată a mesajelor primite. Utile, dar abia după ce ai baza pusă la punct.

Trei cazuri reale (anonimizate)

Magazinul fără confirmări de comandă. Un magazin WooCommerce primea zilnic telefoane de la clienți care „n-au primit confirmarea”. Emailul de firmă era pe Google Workspace, site-ul pe alt hosting, trimitea prin mail() din PHP, iar SPF-ul conținea doar Google. Am mutat trimiterea pe un serviciu tranzacțional, cu DKIM pe domeniu și SPF actualizat. Telefoanele s-au oprit în aceeași săptămână.

Factura falsă. O firmă de servicii a aflat de la un client că primise o „factură actualizată, cu un IBAN nou” de la adresa lor de contabilitate. Domeniul nu avea DMARC deloc. Am configurat SPF, DKIM și DMARC, iar rapoartele au arătat sute de mesaje trimise în numele lor din servere din trei țări diferite. După trecerea la „p=reject”, acele mesaje sunt respinse înainte să ajungă la clienți.

Formularul care nu mai suna. Un cabinet se plângea că „nu mai vin cereri de programare de pe site”. Veneau — dar formularul trimitea de la adresa Gmail a vizitatorului, iar Gmail-ul cabinetului le punea pe toate la spam. Două minute de setări: From pe domeniul lor, Reply-To pe vizitator. În folderul de spam erau peste 40 de cereri neprocesate din ultimele luni.

Lista de verificare finală

  • Am inventarul tuturor serviciilor care trimit emailuri în numele domeniului.
  • Am un singur SPF, cu toate serviciile, sub 10 interogări, terminat în ~all sau -all.
  • Fiecare serviciu semnează DKIM cu domeniul meu, cu chei de 2048 de biți.
  • Am DMARC publicat, cu rapoarte care chiar sunt citite.
  • WordPress trimite prin SMTP autentificat, de la o adresă reală de pe domeniu.
  • Formularele folosesc From = domeniul meu și Reply-To = vizitatorul.
  • „Afișează originalul” în Gmail arată PASS la SPF, DKIM și DMARC.
  • IP-ul și domeniul nu apar pe liste negre.
  • Am un plan de trecere la quarantine și apoi la reject.

Întrebări frecvente

1. Dacă am doar SPF, e suficient?
Nu, în 2026. SPF nu supraviețuiește redirecționărilor, nu e mereu aliniat și nu protejează adresa „De la:”. Ai nevoie de toate trei.

2. DMARC cu „p=reject” poate bloca emailurile mele legitime?
Da, dacă un serviciu legitim nu e configurat corect. De aceea treci prin etapa „p=none” și analizezi rapoartele înainte.

3. Am Google Workspace. De ce mai am nevoie?
De DKIM activat în consola de administrare (nu e pornit implicit), de un DMARC publicat de tine și de configurarea separată a tuturor celorlalte servicii care trimit în numele tău, inclusiv site-ul.

4. Pot face asta singur?
Da, dacă ai acces la DNS și răbdare să citești documentația fiecărui serviciu. Partea delicată e inventarul complet și interpretarea rapoartelor DMARC.

5. Ajută SPF, DKIM și DMARC și la securitate, nu doar la spam?
Da, mult. DMARC în modul „reject” e cea mai eficientă protecție împotriva escrocilor care trimit facturi false sau mesaje de phishing în numele firmei tale.

6. De ce încă ajung la spam, deși am PASS la toate trei?
Autentificarea e doar o parte din ecuație. Verifică reputația IP-ului, listele negre, conținutul mesajului și reclamațiile destinatarilor.

7. Am un domeniu pe care nu-l folosesc pentru email. Trebuie să fac ceva?
Da, și e una dintre cele mai ignorate măsuri. Escrocii adoră domeniile „adormite”, pentru că nimeni nu le supraveghează. Pentru un domeniu care nu trimite niciodată emailuri, publici un SPF care nu permite nimănui să trimită (v=spf1 -all) și un DMARC cu politică de respingere (v=DMARC1; p=reject). Așa, orice mesaj care pretinde că vine de pe acel domeniu e respins din start. Durează cinci minute și închide o ușă pe care probabil nici nu știai că o ai deschisă.

8. Ce se întâmplă cu subdomeniile, de exemplu newsletter.firmata.ro?
Implicit, subdomeniile moștenesc politica DMARC a domeniului principal, dacă nu au una proprie. Asta e, de cele mai multe ori, exact ce vrei. Dacă însă trimiți newsletterul de pe un subdomeniu separat — o practică bună, care ține reputația marketingului despărțită de cea a emailurilor de zi cu zi — subdomeniul are nevoie de propriul SPF și de propriul DKIM, configurate la serviciul care trimite. Iar dacă vrei o politică diferită pentru subdomenii, folosești eticheta sp= în DMARC-ul principal.

9. Cât de des trebuie verificate aceste setări?
De fiecare dată când adaugi sau renunți la un serviciu care trimite emailuri, și oricum măcar o dată la câteva luni. Furnizorii își schimbă uneori valorile recomandate, iar regulile Gmail și Microsoft continuă să se înăsprească. La clienții noștri, verificarea DNS-ului de email face parte din mentenanța lunară, tocmai ca să nu afle nimeni de problemă din telefoanele clienților nemulțumiți.

Concluzia, pe scurt

Emailul a fost construit pe încredere, iar încrederea a fost abuzată. SPF, DKIM și DMARC sunt modul prin care îi dovedești lumii că mesajele tale sunt cu adevărat ale tale. Fără ele, în 2026, emailurile firmei tale sunt tratate ca ale oricui altcuiva — adică cu suspiciune.

Nu e o investiție mare: câteva înregistrări DNS, un plugin SMTP configurat corect, un formular reparat și câteva săptămâni de monitorizare. În schimb, câștigi comenzi confirmate, oferte care ajung la destinație, clienți care își pot reseta parola și un domeniu pe care escrocii nu-l mai pot folosi împotriva ta.

Dacă vrei să știi exact în ce stare e domeniul tău și unde se pierd emailurile, pornește de la un audit gratuit WebFixer. Verificăm SPF, DKIM, DMARC, configurarea emailurilor din WordPress și formularele de contact, și îți spunem pe înțelesul tău ce trebuie reparat.

Descoperă mai multe la WebFixer

Abonează-te ca să primești ultimele articole prin email.

This is a staging environment
Mastodon