Outlook: miért kerül spambe az e-mail, és mi a megoldás?

Az „Outlook” három különböző szűrőt jelent, és a megoldás attól függ, hogy melyik helyezte az e-mailt a Levélszemét mappába. Az Outlook.com a Microsoft lakossági levelezőszolgáltatása, amely a hotmail.com, live.com és msn.com címeket is kezeli. A Microsoft 365 a vállalatok által fizetett üzleti postafiókokat jelenti, ahol a címzett vállalatának rendszergazdája állítja be a levélszemét-szűrési szabályzatot. Emellett ott van a felhasználó számítógépén futó Outlook alkalmazás, amely a kiszolgáló döntésén felül saját levélszemét-szűrőt is használhat. A Microsoft által 2025-ben bejelentett feladói szabályok csak az elsőre vonatkoznak.

Ezért mielőtt egyetlen DNS-rekordot is módosítanék, megnézem a címzett címét. A hotmail.com vagy outlook.com cím azt jelenti, hogy az alábbi lakossági szabályok érvényesek. Ha egy vállalat Microsoft rendszerben kezeli a levelezését, akkor az adott vállalat IT-csapata által meghatározott bérlői szabályzat érvényes.

01Outlook.com és a 2025. májusi szabályok

2025 áprilisában a Microsoft követelményeket jelentett be azon domainek számára, amelyek naponta több mint 5000 e-mailt küldenek a lakossági szolgáltatásába, a Postmaster szabályzatának oldala pedig 2025. május 5-ét jelöli meg a hatálybalépés dátumaként. E mennyiség felett:

• Az SPF-ellenőrzésnek sikeresnek kell lennie a küldő domainnél.
• A DKIM-ellenőrzésnek sikeresnek kell lennie.
• Közzé kell tenni egy DMARC-rekordot „legalább p=none” házirenddel, amely igazodik az SPF-hez vagy a DKIM-hez, „lehetőleg mindkettőhöz”. A szabályzat oldala hozzáteszi, hogy a p=reject ajánlott.

A visszapattanó üzenetről szóló támogatási cikk ezt kissé eltérően fogalmazza meg. A határértékbe 5000 vagy több, a Microsoft lakossági szolgáltatásaiba küldött üzenetet számít bele, amelyek From címében ugyanaz a domain szerepel. Azt is kimondja, hogy az SPF- és a DKIM-ellenőrzésnek egyaránt sikeresnek kell lennie, és amint egy domain eléri ezt a szintet, a Microsoft elvárja, hogy „a domain küldőitől érkező összes üzenet” megfeleljen a szabályoknak, ne csak az a hírlevél, amely miatt a domain átlépte a határt. A DMARC-példája körülbelül a lehető legrövidebb rekord:

Hostname:   _dmarc
TXT value:  v=DMARC1; p=none

Érdemes hozzáadni egy jelentésfogadó címet, például rua=mailto:dmarc@example.com, vagy azt a címet, ahol ténylegesen olvassa a leveleket. Az Outlook.com küld összesített jelentéseket, a Microsoft GYIK-je szerint RUA-jelentéseket küld, RUF-jelentéseket pedig nem tervez küldeni. A DMARC-ellenőrző megmutatja, hogy a megadott cím képes-e fogadni ezeket.

A Google 2024 februárjában ugyanezt a napi 5000-es határt húzta meg a Gmail esetében, majd 2025 novemberében elkezdte fokozatosan szigorítani az érvényesítést, beleértve az elutasításokat is. A Yahoo hasonló követelménylistát alkalmaz, de nem nevez meg küszöbértéket.

A szabály érvényesítési módja már nem sokkal a bejelentés után megváltozott. Az eredeti bejegyzés szerint a nem megfelelő levelek először a levélszemét közé kerülnek, később pedig akár el is utasíthatják őket. Egy április 29-i frissítés szerint a Microsoft ehelyett az elutasítás mellett döntött, ugyanakkor lejjebb ugyanabban a bejegyzésben továbbra is szerepel a korábbi, először levélszemétbe helyezésről szóló bekezdés. Jelenleg az az óvatos értelmezés, hogy 2025. május 5. óta a nem megfelelő levelek a levélszemét közé kerülnek, és az Outlook.com most már ezzel az üzenettel el is utasítja őket:

Nem találtam közzétett dátumot arra vonatkozóan, hogy mikor tértek át az elutasításra. A támogatási cikk egyszerűen jelen időben írja le ezt.

02Mit mond a visszapattanási kód?

Az Outlook.com visszapattanási üzenete hasznosabb, mint amikor egy üzenet csendben a levélszemét közé kerül, mert megnevezi az okot. A Microsoft hibaelhárítási oldalán megtalálható a kódok táblázata, és az átlagos feladóknál ezek fordulnak elő:

A Microsoft saját kódjai nélküli egyszerű 550 5.7.1 másfajta elutasítás, amelynek értelmezéséről külön oldal olvasható.

03Külső küldők és az SPF-követelmény

Sok domain egyszerre több szolgáltatáson keresztül küld leveleket: hírlevélküldő platformon, CRM-en, ügyfélszolgálati rendszeren és számlázási rendszeren át. Mindegyik az Ön domainjét használja a From sorban, és mindegyiket le kell fedni a rekordokkal. Arra a kérdésre, hogy a szabályok akkor is érvényesek-e, ha egy szolgáltató küld Ön helyett, a Microsoft FAQ ezt válaszolja: „Igen. Még ha ki is szervezi a küldést, a hitelesítés akkor is az Ön domainjéhez kötődik.” A támogatási cikk pontosan leírja, mit kell ellenőrizni: a DKIM az Ön domainjével írja-e alá az üzenetet, valamint az SPF-rekord „tartalmazza-e a szolgáltatás által megkövetelt IP-címet vagy include értékeket”.

Itt válik zavarossá az SPF és a DKIM együttes megkövetelése. Sok platform a saját domainjén adja meg a visszapattanó levelek címét, az SPF pedig valójában ezt a Return-Path értéket ellenőrzi. Az SPF így sikeres lesz a platform domainjére, ami teljesíti a „sikeresnek kell lennie” követelményt, a DMARC-illeszkedést pedig az Ön domainjével végzett DKIM-aláírásnak kell biztosítania. Ha a platform ehelyett a saját domainjével ír alá, két sikeres ellenőrzést kap, de illeszkedést egyet sem, az ezt követő DMARC fail pedig pontosan az, amiről az 5.7.515 szól. A támogatási cikk annak ellenőrzését is kéri, hogy a Return-Path domain illeszkedik-e a From domainhez.két sikeres ellenőrzés, nulla illeszkedés: erről szól az egész 5.7.515

Minden, az SPF-hez hozzáadott szolgáltatás DNS-lekérdezéseket is felhasznál. A Microsoft FAQ így fogalmaz: „Ha túllépi a 10 DNS-lekérdezést, az SPF-ellenőrzés sikertelen lehet.” Az SPF-ellenőrző megszámolja ezeket Önnek, és ha túllépte a korlátot, itt találja, hogyan csökkentheti a számukat tíz alá. A DKIM-ellenőrző minden platform selectoránál elvégzi a megfelelő egyezésvizsgálatot.

04A Microsoft 365 szűrését más szabályzata határozza meg

Egy Microsoft 365-szervezetben a rendszergazdák által beállított levélszemét elleni szabályzatok működnek. Alapértelmezés szerint a levélszemét, a nagy bizonyossággal levélszemétnek minősített üzenetek és a tömeges levelek a Levélszemét mappába kerülnek, az adathalász üzenetek karanténba, a nagy bizonyossággal adathalásznak minősített üzenetek pedig mindig karanténba kerülnek. A feladó szempontjából a karantén a legrosszabb eredmény, mert a címzett egyik mappában sem találja meg az üzenetet, hacsak nem keresi meg külön. Az alapértelmezett szabályzat 15 napig, a Standard és Strict előbeállítások pedig 30 napig tartják ott.

A tömeges levelekhez külön mérőszám tartozik, a tömeges levelek panaszszintje. Az 1 és 3 közötti BCL kevés panasszal rendelkező tömeges feladót, a 8-as vagy 9-es pedig sok panasszal rendelkező feladót jelent. Az alapértelmezett szabályzat BCL 7-től, a Standard előbeállítás 6-tól, a Strict pedig 5-től küldi a tömeges leveleket a Levélszemét mappába. 2026 júliusa óta egy újabb réteg is működik: a promóciós jellegű tömeges levelek a BCL-értéküktől függetlenül Promóciók címkét kapnak, és ahol egy rendszergazda bekapcsolta a "Bulk moves enabled" beállítást, ott a Promóciók mappába kerülnek. Ez nem levélszemét, de nem is a Beérkezett üzenetek mappa. A funkció bevezetése még folyamatban van.

A Microsoft két rendszere nincs elszigetelve egymástól. A Microsoft szerint a Microsoft 365 levélszemétszűrése „tanul az ismert levélszemét- és adathalász fenyegetésekből, valamint a fogyasztói platformunk, az Outlook.com felhasználói visszajelzéseiből”, így amit a hotmail.com olvasói jelentenek, az hatással van az üzleti postafiókok által használt szűrőre is.

A rendszergazdák engedélyezési listára is tehetnek egy feladót, ami a kártevők és a nagy bizonyossággal adathalásznak minősített üzenetek elleni védelem kivételével a legtöbb ellenőrzést megkerüli. Ha egy partnercég továbbra is a Levélszemét mappában kapja meg az Ön számláit, az informatikai csapatuk láthatja a tényleges minősítést.

05Az eredmény értelmezése a fejlécekben

Ha hozzáfér az üzenethez abban a formában, ahogyan azt egy Microsoft 365-postafiók fogadta, a levélszemét elleni fejlécek közvetlenül megadják a döntést. Az X-Forefront-Antispam-Report több olyan mezőt tartalmaz, amelyet érdemes ismerni:

• Az SFV:SPM azt jelenti, hogy a levélszemétszűrés spamként jelölte meg az üzenetet, az SFV:NSPM azt, hogy nem spamként, az SFV:SFE pedig azt, hogy a szűrés kimaradt, mert a feladó szerepel a felhasználó Safe Senders listáján.
• A CAT az alkalmazott házirend kategóriáját adja meg: SPM, HSPM (nagy megbízhatósággal spam), BULK, PHSH, SPOOF.
• Az SCL egy szám, amelynek értéke -1 vagy 0 és 9 közötti lehet. A régebbi útmutatók ezt tekintik az eredménynek. A Microsoft jelenlegi SCL-oldala szerint az érték "doesn't determine whether spam filtering identifies a message as Spam or High confidence spam", ezért először a CAT értékét nézze meg.

A fejlécek a compauth mezőt is tartalmazzák, amely a Microsoft SPF, DKIM, DMARC és az üzenet más részei alapján összeállított összesített eredménye. A 001-es okkód azt jelenti, hogy az implicit hitelesítés sikertelen volt, jellemzően azért, mert a küldő tartományhoz nem tettek közzé hitelesítési rekordokat, vagy csak gyenge házirendet állítottak be.

06SNDS és JMRP, mostantól a Postmaster webhelyen

A Smart Network Data Services, vagyis az SNDS, mostantól az új Postmaster webhelyen érhető el, és leváltja a sendersupport.olc.protection.outlook.com régi webhelyet. IP-címenként készít jelentést, ezért igazolnia kell, hogy az adott IP-tartomány az Öné, mielőtt bármilyen adatot megjelenít. Az adatok tartalmazzák a forgalom mennyiségét, a panaszok arányát, valamint egy színjelzést arról, hogy a szűrő a forgalom mekkora részét minősítette spamnek: 10% alatt zöld, 10% és 90% között sárga, 90% felett piros. A hozzáférés mostantól 10 hónappal a jóváhagyás vagy az áttelepítés után lejár, és meg kell újítani.

Kis mennyiségű levelet küldő feladóknál előfordulhat, hogy az SNDS egyáltalán nem jelenít meg adatokat, mert kihagyhatja azokat az IP-címeket, amelyek egy adott napon 100-nál kevesebb üzenetet küldtek. Ha pedig egy platform megosztott IP-címein keresztül küld, ezek a címek nem az Ön tulajdonában vannak, ezért nem regisztrálhatja őket.

A JMRP, vagyis a Junk Mail Reporting Program, a visszajelzési hurok. Regisztráljon az SNDS-en keresztül, és a Microsoft elküldi Önnek azoknak az üzeneteknek bizonyos fejléceit, amelyeket az Outlook.com felhasználói levélszemétként jelöltek meg. Ez jellemzően 72 órán belül elkezdődik. Az új IP-címeket hozzáadásukkor a JMRP-hez is adja hozzá.

A Microsoft a levélszeméttel kapcsolatos panaszok arányát a feladó hírnevét meghatározó „egyik legfontosabb tényezőnek” nevezi, az SNDS GYIK pedig a 0,3% alatti panaszarányt „jó célértéknek” tartja. Az új IP-címeknek időre van szükségük. A Microsoft szerint egy új IP-cím várhatóan „néhány héten belül vagy akár hamarabb, a mennyiségtől és a lista pontosságától függően” éri el a teljes küldési kapacitást. És nem, nincs olyan lista, amelyre pénzért felkerülhet. A hibaelhárítási oldal felteszi a kérdést, hogy az Outlook.com működtet-e olyan engedélyezési listát, amelyre egy feladó felkerülhet, majd ezt válaszolja: „Nem.”

07Mit változtathat a címzett

Ennek egy része a címzetten múlik, ezért nyugodtan megkérheti az olvasót, hogy segítsen. Az Outlook.com szolgáltatásban (Settings, majd Mail, aztán Junk email) a felhasználó Not junk jelöléssel láthatja el az üzenetet, vagy hozzáadhatja a feladót a Safe senders and domains listához. A lista legfeljebb 10 000 bejegyzést tartalmazhat, és a Microsoft szerint az ezen szereplő feladók hivatkozásai és képei általában alapértelmezés szerint engedélyezve vannak. A szigorúbb felhasználók bekapcsolhatják az „exclusive” módot is, amely csak a Contacts és a Safe Senders listán szereplőktől fogad leveleket.

A Junk gomb éppen ellenkezőleg működik. A Microsoft e jelentések alapján dönti el, hogy a jövőben blokkolja-e az ugyanattól a feladótól érkező leveleket. Ettől függetlenül a feladóknak szóló ajánlásaiban olyan leiratkozási hivatkozást kér, amely „jól látható”. A Microsoft szövege nem említi az egykattintásos leiratkozást lehetővé tevő List-Unsubscribe fejléceket, amelyeket a Gmail és a Yahoo megkövetel, de mivel ugyanaz a kampány mindhárom szolgáltatóhoz eljut, én mindenhol hozzáadnám őket (a két fejléc).

Az asztali alkalmazás saját Junk Email Filter funkcióval rendelkezik. Alapértelmezés szerint a „No Automatic Filtering” beállítást használja, ezen felül pedig a Low, High és „Safe Lists Only” lehetőség érhető el. Az utóbbi minden olyan levelet levélszemétként kezel, amely nem a felhasználó biztonságos listáin szereplő feladóktól érkezik. A biztonságos és blokkolt feladók listái szinkronizálódnak a szerverrel, és ott is használatban vannak.

Ott van továbbá a Focused Inbox, amely Focused és Other részre osztja a beérkező leveleket, és a Microsoft megfogalmazása szerint „kiszűri a zajos forrásokat, például az automatikusan létrehozott vagy tömeges e-maileket”. Az Other a beérkező levelek egyik lapja, és értelmezésem szerint az oda kerülő hírlevél már átment a spamszűrésen.

08Tesztelés a tényleges küldés előtt

A Microsoft saját hibaelhárítási oldala szerint „nyomatékosan javasolja, hogy az éles kommunikáció kiküldése előtt végezzen e-mail-tesztelést”. Ezt a lépést fedi le az Email Spam Tester. Küldje el a tényleges üzenetet az oldal által létrehozott címre arról a szerverről vagy platformról, amelyet valóban használna. A jelentés 42 ellenőrzés eredményét sorolja fel: SPF, DKIM és DMARC az igazítással együtt, fordított DNS, a küldő IP ellenőrzése 21 tiltólistán (miért fontosak ezek), a leiratkozási fejlécek és a tartalom. A sikertelen ellenőrzésekhez javítási terv és másolható DNS-rekordok tartoznak, az egyes javításokért járó pontszám pedig a pontozási táblázatból származik.

Ha hozzáadja a beérkezési tesztet, ugyanaz az üzenet a Gmail, Outlook, Yahoo és más szolgáltatók postafiókjaiba is megérkezik. A jelentés közvetlenül a postafiókból olvassa ki, hogy az üzenet az egyes szolgáltatóknál hová került, beleértve a Focused és Other kategóriákat is, ahol a szolgáltató így rendezi az üzeneteket. Ingyenes, és nem igényel regisztrációt. A dokumentáció minden ellenőrzést és annak pontértékét ismerteti.

Ha a következő lépés egy támogatási jegy beküldése, vegye figyelembe, hogy a Microsoft kézbesíthetőségi űrlapja csak az @outlook.com, @hotmail.com, @live.com és @msn.com címekkel kapcsolatos eseteket fogadja. A szabályzatot ismertető oldal arra is figyelmeztet, hogy ha Ön nem felel meg az előírásoknak, „előfordulhat, hogy támogatási csapatunk nem tud segíteni Önnek”.