Pe această paginăOutlook.com și regulile din mai 2025
- Outlook.com și regulile din mai 2025
- Ce îți spune codul de respingere
- Expeditorii terți și cerința SPF
- Microsoft 365 este filtrat de politica altcuiva
- Interpretarea verdictului din anteturi
- SNDS și JMRP, acum pe site-ul Postmaster
- Ce poate schimba persoana de la celălalt capăt
- Testarea înainte de trimiterea propriu-zisă
„Outlook” înseamnă trei filtre diferite, iar soluția depinde de cel care ți-a mutat emailul în Junk. Există Outlook.com, serviciul de email pentru consumatori al Microsoft, care gestionează și adresele hotmail.com, live.com și msn.com. Există Microsoft 365, cu căsuțele poștale pentru companii, unde un administrator din compania destinatarului stabilește politica de spam. Și există aplicația Outlook pe computerul unei persoane, care poate aplica propriul filtru Junk peste decizia luată de server. Regulile pentru expeditori anunțate de Microsoft în 2025 se aplică doar primului dintre acestea.
Așadar, înainte să modific chiar și o singură înregistrare DNS, verific adresa destinatarului. O adresă hotmail.com sau outlook.com înseamnă că se aplică regulile pentru consumatori de mai jos. Pentru o adresă a unei companii care își gestionează emailul prin Microsoft, se aplică politica entității găzduite, redactată de echipa IT a companiei respective.
Outlook.com și regulile din mai 2025
În aprilie 2025, Microsoft a anunțat cerințe pentru domeniile care trimit peste 5.000 de emailuri pe zi către serviciul său pentru consumatori, iar pagina cu politicile Postmaster indică data de 5 mai 2025 ca momentul intrării lor în vigoare. Peste acest volum:
- SPF trebuie să treacă verificarea pentru domeniul expeditor.
- DKIM trebuie să treacă verificarea.
- DMARC trebuie publicat cu „cel puțin p=none” și aliniat cu SPF sau DKIM, „de preferat cu ambele”. Pagina cu politici adaugă că se recomandă
p=reject.
Articolul de asistență despre mesajul de respingere formulează cerințele puțin diferit. Acesta ia în calcul cel puțin 5.000 de mesaje către serviciile Microsoft pentru consumatori, toate folosind același domeniu în adresa From, precizează că atât verificarea SPF, cât și DKIM trebuie să treacă și că, odată ce un domeniu atinge acest prag, Microsoft se așteaptă ca „toate mesajele de la expeditorii din domeniu” să respecte regulile, nu doar newsletterul care a dus la depășirea pragului. Exemplul său DMARC este aproape cel mai scurt record posibil:
Hostname: _dmarc
TXT value: v=DMARC1; p=noneI-aș adăuga o adresă de raportare, rua=mailto:dmarc@example.com sau o adresă la care chiar citești mesajele. Outlook.com trimite rapoarte agregate (întrebările frecvente Microsoft precizează că trimite RUA și nu intenționează să trimită RUF), iar instrumentul de verificare DMARC îți va arăta dacă adresa specificată le poate primi.
Google a stabilit același prag de 5.000 de mesaje pe zi pentru Gmail în februarie 2024 și a început să intensifice aplicarea regulilor, inclusiv respingerile, în noiembrie 2025. Yahoo aplică o listă similară de cerințe, fără să specifice vreun prag.
Modul de aplicare a regulii s-a schimbat cât timp anunțul era încă recent. Postarea inițială spunea că mesajele neconforme vor ajunge mai întâi în Junk și ar putea fi respinse ulterior. O actualizare din 29 aprilie spune că Microsoft a decis să le respingă direct, însă aceeași postare conține încă, mai jos, paragraful mai vechi despre trimiterea inițială în Junk. Interpretarea prudentă în prezent este că, din 5 mai 2025, mesajele neconforme ajung în Junk, iar Outlook.com le respinge acum și cu acest mesaj:
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.
Nu am găsit o dată publicată pentru trecerea la respingere. Articolul de asistență o descrie pur și simplu la timpul prezent.
Ce îți spune codul de respingere
Un mesaj respins de Outlook.com este mai util decât unul care rămâne neobservat în folderul Junk, deoarece indică un motiv. Pagina de depanare Microsoft conține un tabel cu aceste coduri, iar următoarele apar în cazul expeditorilor obișnuiți:
| Cod | Ce înseamnă potrivit Microsoft |
|---|---|
550 5.7.515 | Domeniul trimite peste 5.000 de mesaje pe zi și nu este autentificat prin SPF, DKIM și DMARC |
550 SC-001 | Respingere pe baza politicii, „conținut cu caracteristici de spam sau reputația IP-ului/domeniului” |
550 SC-004 | O blocare a IP-ului tău în urma reclamațiilor privind mesajele trimise de la acesta |
421 RP-001 | Limită de frecvență aplicată IP-ului care se conectează, tot din motive de reputație |
Un simplu 550 5.7.1, fără codurile proprii Microsoft, reprezintă un alt tip de refuz și există o pagină separată despre interpretarea acestuia.
Expeditorii terți și cerința SPF
Multe domenii trimit simultan prin mai multe servicii: o platformă de newslettere, un CRM, un serviciu de asistență, un sistem de facturare. Fiecare trimite folosind domeniul tău în câmpul From și fiecare trebuie să fie acoperit de înregistrările tale. Întrebată dacă regulile se aplică și atunci când un furnizor trimite în numele tău, Microsoft răspunde în FAQ: „Da. Chiar dacă externalizezi trimiterea, autentificarea este legată de domeniul tău.” Articolul de asistență precizează ce trebuie să verifici: că DKIM semnează cu domeniul tău și că înregistrarea SPF „include adresa IP sau valorile include necesare serviciului”.
Aici cerința ca atât SPF, cât și DKIM să treacă poate deveni derutantă. Multe platforme folosesc pentru adresa de bounce propriul lor domeniu, iar SPF verifică de fapt acel Return-Path. Astfel, SPF trece pentru platformă, ceea ce îndeplinește condiția „trebuie să treacă”, iar alinierea DMARC trebuie să provină din semnarea DKIM cu domeniul tău. Dacă platforma semnează în schimb cu propriul domeniu, obții două verificări reușite și nicio aliniere, iar problema DMARC fail care urmează este exact ceea ce indică 5.7.515. Articolul de asistență îți cere, de asemenea, să verifici dacă domeniul Return-Path este aliniat cu domeniul From.două verificări reușite, zero aliniere: întreaga poveste a erorii 5.7.515
Fiecare serviciu pe care îl adaugi în SPF consumă și interogări DNS. FAQ-ul Microsoft explică astfel: „Dacă depășești 10 interogări DNS, verificarea SPF poate eșua.” Instrumentul de verificare SPF le numără pentru tine, iar dacă ai depășit limita, iată cum poți reveni sub zece. Instrumentul de verificare DKIM face verificarea corespunzătoare pentru selectorul fiecărei platforme.
Microsoft 365 este filtrat de politica altcuiva
O organizație Microsoft 365 are politici anti-spam configurate de administratori. În mod implicit, mesajele spam, cele identificate cu un grad ridicat de încredere ca spam și mesajele în masă ajung în folderul Junk Email, în timp ce mesajele de phishing ajung în carantină, iar cele identificate cu un grad ridicat de încredere ca phishing sunt întotdeauna plasate în carantină. Pentru expeditor, carantina este rezultatul cel mai neplăcut, deoarece destinatarul nu găsește mesajul în niciun folder decât dacă îl caută în mod explicit. Politica implicită îl păstrează acolo timp de 15 zile, iar presetările Standard și Strict timp de 30 de zile.
Mesajele în masă au propria unitate de măsură, nivelul reclamațiilor privind mesajele în masă. Un BCL între 1 și 3 indică un expeditor de mesaje în masă cu puține reclamații, iar 8 sau 9 indică un expeditor cu multe reclamații. Politica implicită trimite mesajele în masă în Junk începând de la BCL 7, presetarea Standard de la 6, iar Strict de la 5. Din iulie 2026 există și un nivel mai nou: mesajele în masă cu caracter promoțional primesc eticheta Promotions indiferent de BCL, iar dacă un administrator a activat "Bulk moves enabled", acestea ajung într-un folder Promotions. Acesta nu este spam, dar nici Inbox. Funcționalitatea este încă în curs de implementare.
Cele două sisteme Microsoft nu sunt izolate unul de celălalt. Microsoft afirmă că filtrarea spam din Microsoft 365 „învață din amenințările cunoscute de spam și phishing și din feedbackul utilizatorilor platformei noastre pentru consumatori, Outlook.com”, astfel încât raportările cititorilor hotmail.com contribuie la filtrul folosit de inboxurile companiilor.
Administratorii pot adăuga și un expeditor pe o listă de permisiuni, ceea ce ocolește majoritatea mecanismelor de protecție, cu excepția celor împotriva programelor malware și a mesajelor identificate cu un grad ridicat de încredere ca phishing. Dacă o companie parteneră continuă să primească facturile tale în Junk, echipa sa IT este cea care poate vedea verdictul real.
Interpretarea verdictului din anteturi
Când poți obține mesajul așa cum a fost primit de o cutie poștală Microsoft 365, anteturile anti-spam indică direct decizia. X-Forefront-Antispam-Report conține câteva câmpuri pe care merită să le cunoști:
SFV:SPMînseamnă că filtrarea anti-spam a marcat mesajul ca spam,SFV:NSPMcă nu l-a marcat ca spam, iarSFV:SFEcă filtrarea a fost omisă deoarece expeditorul se află în lista Safe Senders a utilizatorului.CATindică categoria politicii aplicate:SPM,HSPM(spam cu nivel ridicat de încredere),BULK,PHSH,SPOOF.SCLeste un număr, -1 sau de la 0 la 9. Ghidurile mai vechi îl tratează drept verdict. Pagina actuală despre SCL de la Microsoft precizează că valoarea „nu determină dacă filtrarea anti-spam identifică un mesaj ca spam sau spam cu nivel ridicat de încredere”, deci verifică mai întâiCAT.
Anteturile conțin și compauth, verdictul compozit Microsoft bazat pe SPF, DKIM, DMARC și alte componente ale mesajului. Codul de motiv 001 înseamnă că autentificarea implicită a eșuat, de obicei deoarece domeniul expeditorului nu avea înregistrări de autentificare publicate sau avea doar o politică slabă.
SNDS și JMRP, acum pe site-ul Postmaster
Smart Network Data Services, sau SNDS, se află acum pe noul site Postmaster și îl înlocuiește pe cel vechi de la sendersupport.olc.protection.outlook.com. Acesta raportează date pentru fiecare adresă IP, așa că trebuie să dovedești că deții un interval de adrese IP înainte să-ți afișeze ceva. Datele includ volumul, ratele reclamațiilor și o culoare care arată cât de mult din traficul tău a fost clasificat drept spam de filtru: verde sub 10%, galben între 10% și 90%, roșu peste 90%. Accesul expiră acum la 10 luni după aprobare sau migrare și trebuie reînnoit.
Pentru un expeditor mic, este posibil ca SNDS să nu afișeze nimic, deoarece poate omite o adresă IP care a trimis mai puțin de 100 de mesaje într-o anumită zi. Iar dacă trimiți prin adresele IP partajate ale unei platforme, nu deții adresele respective și nu le poți înregistra.
JMRP, Junk Mail Reporting Program, este bucla de feedback. Înscrie-te prin SNDS, iar Microsoft îți va trimite anumite antete ale mesajelor pe care utilizatorii Outlook.com le-au marcat ca spam, de obicei începând în cel mult 72 de ore. Adaugă adresele IP noi pe măsură ce le introduci în uz.
Microsoft numește rata reclamațiilor de spam „unul dintre factorii principali” ai reputației unui expeditor, iar secțiunea de întrebări frecvente SNDS spune că o rată a reclamațiilor sub 0,3% este „un prag bun de urmărit”. Adresele IP noi au nevoie de timp. Microsoft spune că o adresă nouă poate ajunge la capacitate maximă „în câteva săptămâni sau mai repede, în funcție de volum și de acuratețea listei”. Și nu, nu există nicio listă pe care să poți plăti ca să fii inclus. Pagina de depanare întreabă dacă Outlook.com are o listă de permisiuni în care poate intra un expeditor și răspunde „Nu”.
Ce poate schimba persoana de la celălalt capăt
O parte dintre aceste setări țin de destinatar și este rezonabil să-i ceri cititorului să te ajute. În Outlook.com (Settings, apoi Mail, apoi Junk email), un utilizator poate marca un mesaj ca Not junk sau poate adăuga expeditorul în Safe senders and domains. Lista poate conține până la 10.000 de intrări, iar Microsoft precizează că, de obicei, linkurile și imaginile sunt activate implicit pentru expeditorii din această listă. Un utilizator mai strict poate activa și modul "exclusive", care acceptă mesaje numai de la Contacts și Safe Senders.
Butonul Junk funcționează în sens invers. Microsoft folosește aceste raportări pentru a decide dacă mesajele viitoare de la același expeditor ar trebui blocate. Separat, recomandările sale pentru expeditori cer un link de dezabonare care să fie "clearly visible". Textul Microsoft nu menționează antetele List-Unsubscribe cu un singur clic, cerute de Gmail și Yahoo, dar, deoarece aceeași campanie ajunge la toate cele trei servicii, le-aș adăuga peste tot (cele două antete).
Aplicația desktop are propriul Junk Email Filter. Implicit, acesta este setat la "No Automatic Filtering", iar celelalte opțiuni sunt Low, High și "Safe Lists Only". Ultima tratează ca nedorit orice mesaj care nu provine de la expeditori din listele sigure ale utilizatorului. Listele de expeditori siguri și blocați sunt sincronizate cu serverul și sunt folosite și acolo.
Mai există și Focused Inbox, care împarte inboxul în Focused și Other și, conform formulării Microsoft, "filters out noisy sources like automatically generated or bulk email". Other este o filă a inboxului, iar interpretarea mea este că un newsletter ajuns acolo a trecut deja de filtrarea spamului.
Testarea înainte de trimiterea propriu-zisă
Pagina de depanare Microsoft spune că „îți recomandă insistent să testezi e-mailurile înainte de a trimite comunicări reale”. Acesta este pasul acoperit de Email Spam Tester. Trimiți mesajul efectiv la o adresă generată de pagină, de pe serverul sau platforma pe care le-ai folosi în realitate, iar raportul afișează 42 verificări: SPF, DKIM și DMARC cu aliniere, DNS invers, IP-ul de trimitere în 21 de liste de blocare (de ce contează acestea), anteturile de dezabonare și conținutul. Verificările nereușite includ un plan de remediere și înregistrări DNS pe care le poți copia, iar punctele acordate pentru fiecare remediere provin din tabelul de punctaj.
Dacă adaugi testul de plasare în inbox, același mesaj ajunge și în inboxuri de la Gmail, Outlook, Yahoo și alți furnizori, iar raportul arată unde a ajuns la fiecare, pe baza informațiilor citite direct din căsuța poștală, inclusiv Focused sau Other, acolo unde furnizorul sortează astfel mesajele. Este gratuit și nu necesită înregistrare. Documentația explică fiecare verificare și câte puncte costă.
Dacă următorul pas este să deschizi un tichet de asistență, reține că formularul Microsoft pentru probleme de livrabilitate acceptă doar cazuri referitoare la adrese @outlook.com, @hotmail.com, @live.com și @msn.com, iar pagina cu politici avertizează că, dacă nu respecți cerințele, „este posibil ca echipa noastră de asistență să nu te poată ajuta”.