Defaults.Exposed › Javítások › Guides

Az Outlook visszautasítja az e-mailjeit: 550 5.7.515, 550 5.7.509 és compauth=fail, magyarázva és javítva (2026)

Közzétéve 2026-07-08

Adatok: 2026-06-29 · 7. módszertan. Összesített népszámlálási adatok 261 millió értékelt domain alapján. Lásd: hogyan értékelünk.

Két különböző Microsoft-rendszer utasítja vissza a leveleket. A fogyasztói Outlook.com visszapattantja a nagy forgalmú küldőket, akik megbuknak a hitelesítésen (550 5.7.515, 2025 márciustól érvényesítve); az Exchange Online visszapattantja azokat a leveleket, amelyek megbuknak a saját DMARC reject szabályzatán (550 5.7.509). Az spf.protection.outlook.com-ot engedélyező 10,205,070 domain közül 85.0%-nak van szigorú SPF-je, de csupán 21.7% érvényesíti a DMARC-ot a Defaults.Exposed 261,086,232 domainre kiterjedő népszámlálása szerint.

A legtöbb „Az Outlook visszautasítja a levelemet” probléma valójában nem visszautasítás — hanem a levél csendesen a Levélszemétbe kerül, a fejlécekben compauth=fail értékkel. Ez az útmutató dekódolja a Microsoft kódjait, megmutatja, hogyan olvassa el az Authentication-Results fejlécet, és végigvezeti a javítást sorban: erősítse meg az SPF-et, engedélyezze a DKIM-et az egyéni domainjéhez, tegye közzé és érvényesítse a DMARC-ot, tesztelje újra.

Melyik Microsoft-hibát kapja ténylegesen?

A Microsoft két különálló fogadási felületen fut, és különböző okokból utasítja vissza. Először azonosítsa a tünetét — a rossz diagnózis egy napot pazarol el.

A pontos NDR-szöveg változik; ellenőrizze az idézett karakterláncokat egy élő visszapattanással szemben, mielőtt rájuk támaszkodik.

Mit jelent az 550 5.7.515?

Ez a fogyasztói Outlook.com/Hotmail követelmény, nem Microsoft 365 bérlői hiba. 2025 márciustól a napi több mint 5 000 üzenetet küldők a fogyasztói Outlook-címekre kötelesek átmenni az SPF-en, átmenni a DKIM-en, és közzétenni egy DMARC-rekordot (legalább p=none értékkel) a Feladó domainjéhez igazítva. Ha ez a szint nem teljesül, a fogyasztói Outlook visszautasítja az alábbi szöveggel:

550 5.7.515 Access denied, sending domain [sajatdomain.hu] does not meet the required authentication level.

Két dolog ez nem: nem 2026-os kötelezettség (ha a levelei most kezdenek visszapattanni, a forgalom vagy a DNS változott, nem a szabály), és nem a fogadó M365-bérlő beállításairól szól. A javítás az alábbi hitelesítési létra — és azok az alkalmi kampánynapok, amelyek átlépik a napi 5 000-et, szintén számítanak.

Mit jelent az 550 5.7.509?

Ez az Exchange Online Protection üzleti bérlőkön fordul elő, és azt jelenti, hogy a saját DMARC-szabályzatát érvényesítik:

550 5.7.509: Access denied, sending domain [sajatdomain.hu] does not pass DMARC verification and has a DMARC policy of reject.

Olvassa el figyelmesen — nem a Microsoft nehézkedik. A domainje p=reject értéket tesz közzé, ez az üzenet megbukott a DMARC-on, és a fogadó pontosan azt tette, amit Ön kért. Ha a visszapattant levél jogszerű, valamelyik küldési forrás (egy hírlevéleszköz, egy CRM, egy szkennelő eszköz) nincs igazítottan hitelesítve. Ne gyengítse a szabályzatot; adjon igazított SPF-et vagy DKIM-et az adott forrásnak — lásd: DMARC javítása és p=none-tól p=reject-ig.

Miért kerüli spambe az Outlook a levelemet compauth=fail értékkel visszapattanás nélkül?

A legtöbb Microsoft kézbesítési fájdalom soha nem hoz létre visszapattanást. Az üzenet elfogadva, pontozva és spambe téve — az egyetlen bizonyíték az Authentication-Results fejléc. A fogadó postafiókban (vagy saját outlook.com tesztelési postafiókban) nyissa meg az üzenetet, válassza a Forrás megtekintése lehetőséget, és keresse a sort:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

A compauth a Microsoft kompozit hitelesítési ítélete: még ha egy domain nem tesz közzé DMARC-rekordot, a Microsoft implicit, DMARC-szerű ellenőrzéseket alkalmaz. Általánosan látott értékek:

• compauth=fail reason=000 — az üzenet megbukott az explicit hitelesítésen: a domainje DMARC-szabályzata karantén/elutasítás, és az üzenet megbukott rajta.
• compauth=fail reason=001 — az üzenet megbukott az implicit hitelesítésen: a domainje nem tesz közzé (vagy nem elegendő) hitelesítési rekordot, és az üzenet nem tűnt úgy, mintha Öntől jött volna. A klasszikus „soha nem állítottuk be a DKIM-et/DMARC-ot” aláírás.
• compauth=fail reason=6xx — implicit hitelesítési hiba változatok; a 601 különösen azt jelenti, hogy a küldési domain a szervezet saját elfogadott domainjei egyike (szervezeten belüli hamisítás, önmagától önmagának).

A tanulság: a Microsoftnál olvassa el a fejlécet, ne csak az NDR-t. Ugyanazon sorban az spf=, dkim= és dmarc= ítéletek pontosan megmondják, melyik igazítást kell javítani.

Hogyan javítja az Outlook-visszautasításokat és a spambe kerülést?

1. Futtassa először az ingyenes vizsgálatot. Egyetlen futással értékeli az SPF-et, a DKIM-et és a DMARC-ot, és megmutatja, melyik igazítás hibázik, mielőtt hozzányúl a DNS-hez.
2. Erősítse meg az SPF-et — általában már rendben van a Microsoft 365-ön. A szabványos rekord: v=spf1 include:spf.protection.outlook.com -all, és az M365 beállítás oda helyezi: az spf.protection.outlook.com-ot engedélyező 10,205,070 domain 85.0%-a már szigorú -all-ra végződik (adatok: 2026-06-29). Egy korlát: a vevők az SPF-et a Return-Path (RFC5321.MailFrom) domain, nem a Feladó fejléc ellen értékelik — tehát egy hírlevéleszköz átmehet az SPF-en saját bounce-domainjén, miközben az Önéért semmit sem tesz. Ezért fontosabb a 3. és 4. lépés.
3. Engedélyezze a DKIM-et az egyéni domainjéhez — két selector CNAME. Az M365 egy nem igazított onmicrosoft.com alapértelmezéssel ír alá, amíg nem kapcsolja be az egyéni domainre szóló aláírást: tegye közzé a selector1._domainkey és selector2._domainkey CNAME-eket, amelyek a bérlő kulcsaira mutatnak, majd engedélyezze az aláírást a Defender-portálon. Teljes kattintási útmutató: DKIM beállítása Microsoft 365-ön. Ha a DKIM „pass”-t mutat, de a DMARC még mindig megbukik, az alapértelmezett aláírás csapdájában van.
4. Tegye közzé a DMARC-ot, majd érvényesítse. Kezdje v=DMARC1; p=none; rua=mailto:... értékkel a jelentések fogadásához, javítsa minden jogszerű forrást, amelyet feltárnak, majd lépjen p=quarantine-ra és p=reject-re — a szakaszos elv a DMARC javításában van. Ez az a lépés, amelyet a legtöbb Microsoft-üzlet kihagyja: az M365-küldő domaineknek csupán 21.7%-a érvényesíti a DMARC-ot.
5. Tesztelje újra a fejléc elolvasásával. Küldjön egy fogyasztói outlook.com postafiókba, nyissa meg az üzenet forrását, és erősítse meg az spf=pass, dkim=pass, dmarc=pass és compauth=pass értékeket.
6. Nagy forgalmú küldők: felelje meg a fogyasztói Outlook követelményeit. Napi 5 000 felett érvényes, felügyelt Feladó/válaszcím, működő leiratkozás és tiszta listák is kellenek — a hitelesítés félresöpri az 5.7.515-öt; a panaszarány tartja ki az S3140/S3150 IP-blokkokból. Ha már IP-ban blokkolt, az SPF/DKIM/DMARC javítása nem oldja fel a blokkot: kérjen feloldást a Microsoft küldői támogatásán keresztül, és kezelje a hitelesítést annak okaként, hogy nem fog visszatérni.

Miért buksz meg még mindig annyi Microsoft 365 domain?

Mert az alapértelmezés elvégzi az első lépést Önért, és a többi egyikét sem. Az spf.protection.outlook.com-ot engedélyező 10,205,070 domain között 85.0% rendelkezik szigorú SPF-fel — az M365 által a beállítás során adott rekorddal —, de csupán 21.7% érvényesíti a DMARC-ot a Defaults.Exposed 261,086,232 domainre kiterjedő népszámlálása szerint. Az M365 alapértelmezés szerint szigorú SPF-et ad, majd a legtöbb bérlő ott megáll — pontosan az a populáció, amelynek a compauth lefogására tervezték (bár még mindig megelőzi az összes értékelt domain 10.59%-os DMARC-érvényesítési arányát). Teljes szolgáltatói összehasonlítás: e-mail-szolgáltatói SPF-bajnoki táblázatunk.

Gyakran ismételt kérdések

Az 550 5.7.515 Microsoft 365 hiba? Nem. A fogyasztói Outlook.com/Hotmailről érkezik, és napi >5 000 üzenetet küldőket céloz, amelyet 2025 márciustól érvényesítenek. Az üzleti Exchange Online visszautasítások más kódokat használnak — leggyakrabban 550 5.7.509 (a DMARC reject szabályzat) vagy 5.7.511 (tiltott küldő).

550 5.7.509-et kaptunk, de a levél jogszerű volt — el kell vetnünk a p=reject értéket? Nem — a szabályzata elkapott egy hitelesítetlen forrást, ami azt jelenti, hogy működik. Keresse meg a forrást a fejlécben vagy a DMARC-jelentésekben, és adjon neki igazított DKIM-et (vagy igazított SPF-et). A p=none-ra való gyengítés újra megnyitja a pontos domainhamisítást mindenki előtt.

A compauth=fail azt jelenti, hogy valaki hamisít minket? Nem feltétlenül. A reason=001 általában azt jelenti, hogy a saját levele nem tudja bizonyítani, hogy Öntől való — nincs igazított DKIM, nincs DMARC. Az 10,205,070 M365-küldő domain csupán 21.7%-a érvényesíti a DMARC-ot (adatok: 2026-06-29), tehát a Microsoft implicit ellenőrzéseket alkalmaz mindenkire másra, és a hitelesítetlen jogszerű levelek is megbuknak.

Naponta 5 000-nél kevesebb e-mailt külök — figyelmen kívül hagyhatom ezt? Megússza az 550 5.7.515-öt, de nem a Levélszemet mappát: a compauth bármely kötetben érvényes. A Gmail ugyanezt csinálja — lásd a Gmail 550 5.7.26 útmutatót. A javítások ingyenesek; a korlát a tudatosság, nem a költség.

Küldje el a tulajdonosnak a jelentést

Ha valaki másért — ügyfélért, főnökért, a vállalatért, amelynek számlái visszapattantak — javít e-mailt, fejezze be a munkát bizonyítékkal. Futtassa újra az ingyenes vizsgálatot a DNS stabilizálódása után, és küldje el az értékelt jelentést. Egyszerű üzleti nyelven mutatja, hogy az SPF, DKIM és DMARC zölddé válik, amelyet egy vállalkozás tulajdonosa el tud olvasni, és ez az a dokumentum, amelyre szükségük lesz a következő kibervédelmi biztosítás megújításakor vagy az ügyfél biztonsági kérdőívénél, amely megkérdezi, hitelesítik-e az e-mailjüket. A javítás jó; a bizonyíthatóan javított az, amiért fizetnek és amiért ők biztosítva vannak.

Ellenőrizze a domainjét ingyen

Lássa, melyik igazításon buksz meg a Microsoftnál — SPF, DKIM, DMARC —, privát módon és csak a tulajdonosra vonatkozóan.

Ellenőrizze a domainjét → · DMARC javítása → · DKIM átmegy, de DMARC megbukik → · Hogyan értékelünk → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.