SPF, DKIM și DMARC: ce sunt, cum le configurezi și ce faci dacă e-mailurile firmei tale nu ajung (cazul Outlook.com)

Publicat pe 11 noiembrie 2026 · Echipa mitza.es

„E-mailul meu nu ajunge la client” este una dintre cele mai frecvente probleme informatice dintr-un IMM și aproape întotdeauna are aceeași rădăcină: serverul care primește mesajul nu poate verifica dacă vine cu adevărat de la domeniul tău. Această verificare depinde de trei înregistrări DNS: SPF, DKIM și DMARC. La începutul lunii noiembrie 2026, subiectul a ajuns în presa de tehnologie din cauza celor întâmplate cu Outlook.com. Rezumăm ce s-a întâmplat, ce este fiecare înregistrare și cum le configurezi cu cap.

Ce s-a întâmplat cu Outlook.com în noiembrie 2026

Începând cu 5 sau 6 noiembrie, administratori ai unor domenii mici au început să observe respingeri ale e-mailurilor trimise către adrese Outlook.com, Hotmail.com și Live.com, cu mesaje precum 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Publicația germană heise a pus cazul în legătură cu domeniile fără înregistrare DMARC, cu respingeri chiar și atunci când SPF și DKIM erau corecte și cu cazuri intermitente. În firul de discuție al comunității Microsoft au scris și administratori de Microsoft 365 și de domenii care aveau deja DMARC.

Versiunea Microsoft, potrivit unui moderator al forumului lor (incidentul EX1545193), este diferită: problema s-a datorat unei „actualizări recente a regulilor de aplicare antispam” care a identificat din greșeală ca încălcări ale SPF unele e-mailuri legitime. Microsoft a anulat modificarea, iar pe 10 noiembrie serviciul figura ca restabilit. În plus, Microsoft nu a anunțat nicio cerință generală de DMARC pentru expeditorii mici: ceea ce rămâne în vigoare din mai 2025 este obligația de SPF, DKIM și DMARC (cel puțin p=none) pentru domeniile care trimit peste 5.000 de mesaje pe zi. În propriul ghid, Microsoft spune că expeditorii mici „beneficiază” de aceste bune practici, fără să le impună.

Ce rămâne din toate acestea? Că publicarea unui DMARC minim este o asigurare ieftină și că, dacă e-mailurile tale sunt respinse, merită să verifici mai întâi cele trei înregistrări. Totuși, episodul nu dovedește că DMARC ar fi fost cauza în toate cazurile: explicația Microsoft vorbește despre o eroare a regulilor lor antispam.

Ce sunt SPF, DKIM și DMARC, pe limba tuturor

• SPF (Sender Policy Framework): o listă, publicată în DNS-ul domeniului tău, cu serverele care au voie să trimită e-mailuri în numele tău. Este ca o listă de poștași autorizați.
• DKIM (DomainKeys Identified Mail): o semnătură digitală adăugată fiecărui mesaj. Destinatarul o verifică cu o cheie publică pe care o publici în DNS și astfel știe că mesajul vine de la cine spune și că nu a fost modificat pe drum.
• DMARC: politica care le leagă pe cele două. Îi spune destinatarului ce să facă dacă SPF sau DKIM nu coincid cu adresa „De la:” vizibilă (nimic, carantină sau respingere) și unde să-ți trimită rapoarte. Aici intervine ideea de aliniere: domeniul care se autentifică trebuie să coincidă cu cel pe care îl vede destinatarul.

Toate trei se publică ca înregistrări de tip TXT (sau CNAME, în cazul DKIM, în funcție de furnizor) în zona DNS a domeniului tău. Dacă le-ai întâlnit deja pe scurt în ghidul nostru despre Google Workspace sau Microsoft 365 pentru emailul profesional, aici le vedem mai în detaliu.

Cum arată înregistrările

Exemple cu un domeniu fictiv (înlocuiește domeniultau.com cu al tău):

SPF

O singură înregistrare TXT la rădăcina domeniului. Pentru Microsoft 365, de obicei arată așa, iar pentru Google Workspace se schimbă serviciul inclus:

domeniultau.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"
domeniultau.com.   TXT   "v=spf1 include:_spf.google.com ~all"   (Google Workspace: una sau alta, nu ambele)

Poate exista doar o singură înregistrare SPF per domeniu, iar SPF admite cel mult 10 interogări DNS: dacă adaugi multe servicii, trebuie să le unești în aceeași înregistrare. ~all înseamnă „eșec ușor”, iar -all „eșec ferm”; începe cu prima variantă dacă nu ești sigur.

DKIM

Nu se scrie de mână: se generează în consola serviciului tău de e-mail (Google Workspace, Microsoft 365, instrumentul tău de newslettere, magazinul tău online…) și ți se dau una sau două înregistrări de publicat în DNS. Trebuie activat în fiecare serviciu care trimite e-mailuri cu domeniul tău.

DMARC

O înregistrare TXT pe subdomeniul _dmarc. Minimul cu care poți începe, cu rapoarte trimise către o căsuță a ta:

_dmarc.domeniultau.com.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none nu schimbă ce se întâmplă cu e-mailurile tale: doar cere rapoarte. rua este adresa care va primi rapoartele agregate. O înregistrare DMARC nu garantează că totul trece: în plus, SPF sau DKIM trebuie să fie aliniate cu domeniul vizibil.

Cum le configurezi pas cu pas

1. Fă o listă cu tot ce trimite e-mailuri cu domeniul tău: serviciul tău de e-mail, site-ul web (formularele de contact), magazinul online, instrumentul de facturare, CRM-ul, newsletterele.
2. Publică un singur SPF care să includă toate aceste servicii.
3. Activează DKIM în fiecare serviciu și publică înregistrările lui.
4. Publică DMARC cu p=none și rua. Astfel începi să primești rapoarte fără să riști e-mailurile legitime.
5. Verifică rapoartele timp de două până la patru săptămâni (pot fi lungi de citit; există servicii gratuite care le rezumă) ca să descoperi servicii care trimit în numele tău și pe care le uitaseși.
6. Înăsprește politica treptat: de la p=none la p=quarantine și, când totul este curat, la p=reject. Microsoft și specialiștii sunt de acord să se avanseze gradual.

Cum verifici că funcționează

• Interoghează înregistrările: pe Windows, nslookup -type=txt _dmarc.domeniultau.com; pe Linux sau macOS, dig TXT _dmarc.domeniultau.com. Schimbă numele ca să verifici SPF și DKIM.
• Trimite-ți un e-mail de test către un cont Gmail și deschide mesajul cu opțiunea „Afișează originalul”: SPF, DKIM și DMARC trebuie să apară ca „PASS”.
• Uită-te la antetul Authentication-Results al e-mailurilor pe care le primești de la alții: acolo notează fiecare server dacă verificarea a trecut.
• Testează cu destinații diferite: Gmail, Outlook.com și contul unui client.

Dacă e-mailurile tale sunt respinse sau ajung în spam

1. Citește codul respingerii. Textul erorii (de exemplu, 550 5.7.1 sau 5.7.515) indică ce verificare a eșuat și cine a respins mesajul.
2. Verifică cele trei înregistrări cu controalele de mai sus și corectează ce nu merge: un SPF duplicat și un serviciu uitat sunt cauze frecvente.
3. Nu retrimite în buclă același e-mail: înrăutățește reputația domeniului tău.
4. Păstrează dovezi (mesajul complet de respingere, identificatorul mesajului și un exemplu în format .eml) ca să poți contacta serviciul de suport al destinatarului, ceea ce a recomandat moderatorul Microsoft în cazul din noiembrie.
5. Dacă este intermitent și înregistrările tale sunt în regulă, poate fi o problemă a furnizorului destinatar, ca aceea pe care Microsoft a anulat-o pe 10 noiembrie: așteaptă, repetă testul și consultă starea serviciului.

Greșeli frecvente

• Publicarea a două înregistrări SPF pe același domeniu: rezultatul este o eroare permanentă, iar SPF nu mai validează.
• Uitarea serviciilor care trimit e-mailuri în numele tău: facturare, CRM, buletine informative, chiar site-ul web.
• Trecerea la -all sau la p=reject fără să fi verificat mai întâi rapoartele.
• Trimiterea formularelor de contact ale site-ului cu funcția de e-mail a serverului, fără autentificare: este mai bine să folosești o trimitere autentificată (SMTP) sau un serviciu autorizat în SPF și DKIM.
• Neprotejarea subdomeniilor sau a domeniilor pe care nu le folosești pentru e-mail.

Dincolo de livrare: să nu ți se uzurpe domeniul

Cu DMARC pe quarantine sau reject, e-mailurile false care folosesc domeniul tău au mai mari dificultăți să ajungă în inboxul celui care le primește, ceea ce îngreunează fraude precum cele pe care le explicăm în înșelăciunile care îți imită magazinul online sau în frauda schimbării IBAN. Nu elimină riscul, pentru că atacatorii pot folosi și domenii asemănătoare cu al tău, dar închide o ușă foarte des folosită.

Ce cer Google, Yahoo și Microsoft

• Google și Yahoo: din 2024, SPF, DKIM și DMARC pentru cine trimite peste 5.000 de mesaje pe zi către utilizatorii lor.
• Microsoft (Outlook.com): din mai 2025, SPF, DKIM și DMARC cu cel puțin p=none pentru domeniile care trimit peste 5.000 de mesaje pe zi. Potrivit notei lor, e-mailul neconform ar fi trimis mai întâi în folderul de mesaje nesolicitate și respins mai târziu, la o dată care urmează să fie anunțată. Pentru ceilalți expeditori nu este obligatoriu, dar este recomandat.
• Dacă firma ta trimite buletine informative sau campanii către mulți destinatari, chiar dacă tu nu ajungi la această cifră, serviciul de trimitere pe care îl folosești poate fi supus acestor cerințe.

Întrebări rapide

Este DMARC obligatoriu pentru un IMM?

Nu există o obligație generală pentru volume mici, dar este o practică recomandată și din ce în ce mai frecventă. Cu p=none începi fără risc.

Poate DMARC să-mi facă să pierd e-mailuri?

Cu p=none, nu. Riscul apare la trecerea la quarantine sau reject dacă există servicii legitime neautorizate. De aceea se verifică mai întâi rapoartele.

Cât durează până se simte o modificare DNS?

Depinde de timpul de cache (TTL) al înregistrării. Poate varia de la câteva minute la câteva ore; uneori, ceva mai mult.

Trebuie să o fac eu sau o face furnizorul meu de e-mail?

Înregistrarea se publică în DNS-ul domeniului tău, deci depinde de cine îl administrează (furnizorul tău de domeniu, de hosting sau de servicii informatice). Dacă nu știi cine este, ai un ghid în domeniu și hosting: ce sunt și cum alegi.

Cum te ajutăm la Mitza

Verificăm înregistrările domeniului tău, configurăm SPF, DKIM și DMARC treptat și ne asigurăm că tot ce trimite e-mailuri în numele tău este autorizat. Vezi serviciul nostru de mentenanță IT pentru IMM-uri sau spune-ne cazul tău din pagina de contact.

Citește și: cum citești un aviz de securitate și SMS-urile false de la DGT, Correos și Fisc.