Gmail „550-5.7.1 Message Blocked" — Dekódolja a visszapattanást, és javítsa (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.

A Gmail 550-5.7.1 visszapattanást ad, ha szabályzati okokból blokkolja az üzenetet, nem hiányzó rekord miatt: egy küldési vagy fogadási domain szabályzata, fordított DNS nélküli IPv6-kapcsolat, vagy feltételezett spam. A 12,145,313 domain közül, amelyek a saját Google-szervereiket engedélyezik az SPF-ben, csupán 18.5% érvényesíti a DMARC-ot a Defaults.Exposed 261 millió domainre kiterjedő népszámlálása szerint.

Az 550-5.7.1 a Gmail legrégibb általános visszautasítása, és a javítás a visszapattanás kódjában szereplő mondattól függ. Az alábbiakban: a pontos szöveg dekódoló táblája, majd a javítási út változatonként — szabályzati visszautasítások, fordított DNS nélküli IPv6-szerverek, spam- vagy tartalomblokkok — plusz az általa összekevert hasonló kódok, beleértve az 5.7.26 kódcsaládot, amelyet a Google most a DMARC-szabályzat visszautasítására használ, amelyet az újabb referenciákban azelőtt az 5.7.1 alá soroltak.

Mit jelent ténylegesen a Gmail 550-5.7.1?

Az SMTP kibővített állapotrendszerben (RFC 3463) minden 5.7.x kód „állandó hibát, szabályzati okokat” jelent. A Gmail a 550-5.7.1-et örökölt szabályzati kódcsaládjaként használja: küldő- vagy fogadósabályzat-blokkok, spam-hírnévblokkok, és — a legtöbb rendszergazdát meglepő változat — IPv6-on érkező levél, amelynek szerverén nincs fordított DNS (PTR) rekord.

A Google idővel újrakódolt egyes változatokat. A DMARC-szabályzat visszautasítása („not accepted due to domain’s DMARC policy”) most a 550-5.7.26 kód alá kerül a Google jelenlegi referenciájában, bár a régebbi visszapattanások még mindig mutathatják 5.7.1-ként; a tartalombiztonsági blokkot most 552 5.7.0 jelzi. Két másik testvér keveredik össze a 5.7.1-gyel: a 550-5.7.26, a hitelesítési követelmények kódcsaládja (saját útmutatóval), és a 550-5.7.25, a hiányzó PTR kódja bármely IP-verzión. A kódtól függetlenül dekódolja az alábbi szöveget.

Melyik 550-5.7.1 változata van?

Hasonlítsa a nem kézbesítési értesítőjében (NDR) szereplő szöveget ezzel a táblával. A Google az évek között módosítja ezeket a karakterláncokat — hasonlítsa az értelmet, nem az írásjeleket.

A visszapattanás így szól…	Mit jelent	A javítási út
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	A szervere IPv6-on keresztül kézbesített, nem (vagy nem egyező) fordított DNS nélkül	PTR-rekord az IPv6-címhez, vagy átirányítás a szolgáltató okos gazdagépén keresztül (alább)
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	Szabályzatblokk — a fogadóé, vagy a saját domainjéé	Vegye fel a kapcsolatot a fogadói rendszergazdával; ha a saját domain DMARC-ja az érvényes szabályzat, lásd alább
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	Spam/hírnévblokk a tartalmon, IP-n vagy domainen	Postmaster Tools + listatisztítás + egyetlen kattintásos leiratkozás (alább)
“This message is likely suspicious due to the very low reputation of the sending domain” (vagy „…sending IP address”)	Hírnévblokk — domain vagy IP	Ugyanaz a hírnév-helyreállítási út (alább)
“Unauthenticated email from sajatdomain is not accepted due to domain’s DMARC policy.” — jelenleg 550-5.7.26-ként kódolva a Google referenciájában; régebbi visszapattanások még 5.7.1-ként mutathatják	A saját DMARC-szabályzata utasította el a hitelesítetlen üzenetet	Keresse meg a nem hitelesített forrást — ne lazítsa el először a szabályzatát (alább)
“…blocked because its content presents a potential security issue.” — most 552 5.7.0-ként kódolva	Tartalom/szabályzatblokk (melléklet-típus, hivatkozás hírneve)	Távolítsa el a megjelölt tartalomtípust; ellenőrizze a hivatkozásokat és mellékleteket
A kód 550-5.7.25, “the sending IP address doesn’t have a PTR record”	Hiányzó fordított DNS bármely IP-verzión	Ugyanaz az rDNS-javítás, mint az IPv6-változatnál
A kód 550-5.7.26	Hitelesítési követelmények kódcsaládja, nem 5.7.1	Lásd a 550-5.7.26 útmutatót
A kód 421-4.7.0, “Try again later, closing connection.”	Átmeneti halasztás — forgalom vagy hírnév, nem végleges blokk	Lassítson, javítsa a hitelesítést és a spam-arányt; általában megoldódik

Hogyan javítja a 550-5.7.1 visszapattanást?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon — az SPF-, DKIM- és DMARC-rekordokat úgy értékeli, ahogy a világ látja, mielőtt hozzányúl a DNS-hez, és megmutatja, hogy a DMARC-változat egyáltalán lehetséges-e az Ön domainjéhez.
Olvassa el a teljes NDR szövegét a dekódoló táblával szemben — a mondat, nem a kód azonosítja az okot.
DMARC-változat: keresse meg, melyik küldési forrás hibásodott meg a hitelesítésben, és javítsa azt a forrást (következő rész).
IPv6/PTR-változat: adjon hozzá egyező fordított DNS-t a szerver IPv6-címéhez, vagy irányítson át a szolgáltatója okos gazdagépén keresztül.
Spam/szabályzat-változat: Postmaster Tools, spam-arány 0,10% alatt (a Google keménykörülhatárolt követelménye 0,30%), listatisztítás, RFC 8058 egyetlen kattintásos leiratkozás.
Küldjön újra egy tesztet egy Gmail-postafiókba, és futtassa újra a vizsgálatot — erősítse meg, hogy a visszapattanás eltűnt és az értékelés ezt tükrözi.

A visszapattanás megemlíti a DMARC-szabályzatát — miért az Ön szabályzata működik

A Google jelenlegi referenciája ezt a szövegláncot 550-5.7.26-ként kódolja, de a régebbi visszapattanások és harmadik féltől származó dokumentumok még 5.7.1 alatt mutatják — mindenesetre a mechanika azonos. Visszafelé olvasva érthetővé válik: a Gmail ellenőrzött egy üzenetet, amely az Ön domainjétől állítja magát, megállapította, hogy sem az SPF, sem a DKIM nem ment át igazítással, megnézte a DMARC-rekordját, és pontosan azt csinálta, amit Ön kért — elutasítás. A kerítése tartott. A kérdés az, mi akadt bele: egy elfelejtett jogszerű küldő (egy CRM, egy számlázóeszköz, egy hírlevélplatform) vagy egy tényleges hamisítás.

Tehát ne lazítsa el először a szabályzatot. Keresse meg a nem hitelesített forrást. Két csapda fedi le az esetek többségét:

Az SPF átmegy, de rossz domainen. A vevők az SPF-et a Return-Path (RFC5321.MailFrom) domain, nem a Feladó fejléc ellen értékelik. Egy SaaS-eszköz, amely „Öntől” küld, általában az önmaga bounce-domainjén megy át az SPF-en, amely nem igazodik a Feladó domainjéhez — tehát a DMARC még mindig megbukik. Útmutató: DMARC megbukik, de az SPF és a DKIM átmegy.
A DKIM átmegy, de az alapértelmezett aláírással. A Google Workspace gappssmtp.com és a Microsoft onmicrosoft.com alapértelmezettje jól ellenőrzi és semmire nem igazodik. Lásd: A DKIM átmegy, de a DMARC még mindig megbukik.

Ez a változat ritkább, mint gondolná: 261,086,232 domainből 27,640,987 — 10.59% — érvényesít karantén vagy elutasítás szintű DMARC-szabályzatot a Defaults.Exposed népszámlálása szerint (2026-06-29). A többi 89.41% soha nem látja ezt a visszapattanást, mert nincs kerítésük, amely tartana. A forrás javítása, nem a szabályzaté, a DMARC javítási útmutatóban teljes körűen le van fedve.

A visszapattanás IPv6 küldési irányelveket említ — a fordított DNS javítása

A modern szerverek sokszor alapértelmezés szerint IPv6-on keresztül csatlakoznak a Gmailhez, és a Google megköveteli, hogy a csatlakozó IPv6-cím rendelkezzen egy PTR-rekorddal, amely egy olyan gépnévre oldódik fel, amely visszaoldódik ugyanarra a címre (forward-confirmed reverse DNS). Ha ez hiányzik, minden üzenet 550-5.7.1-et kap, függetlenül attól, mennyire tiszta az SPF-je.

Három javítás, preferencia-sorrendben:

Állítsa be a PTR-rekordot a szerver IPv6-cím éhez — ott hajtja végre, ahol az IP-cím él (a VPS-gazdagép vagy az ISP vezérlőpanelen, nem a domain DNS-zónájában), egyező AAAA-rekorddal visszamutató.
Irányítson át a szolgáltató okos gazdagépén keresztül. Ha nem tudja irányítani az rDNS-t, irányítsa a kimenő leveleket az e-mail-szolgáltatója vagy ISP-je relén keresztül, amelynek már megfelelő rDNS-e van.
Részesítse előnyben az IPv4-szállítást sürgősségi megoldásként. Ez általában elrejti a tünetet, mert az IPv4-cím rendelkezik PTR-rel — megkerülő megoldás, nem javítás. Állítsa be az IPv6 PTR-jét, amikor tudja.

A visszapattanás azt mondja: „likely unsolicited email” — a hírnév-helyreállítási út

Itt a hitelesítés esetleg rendben van, de a Gmail szűrői nem bíznak a levélben. A hitelesítés a padló, nem a mennyezet — a _spf.google.com-ot engedélyező 12,145,313 domain között csak 8.0% zárja le az SPF-et szigorú -all-lal, tehát egy átmenő ellenőrzés önmagában keveset mond. (Teljes összehasonlítás: melyik e-mail-szolgáltató ad a legerősebb SPF alapértelmezést.)

A hírnév-helyreállítási ellenőrzőlista:

Regisztráljon a Google Postmaster Tools-ban, és figyelje a spam-arány irányítópultot — tartsa 0,10% alatt, és soha ne hagyja elérni a 0,30%-os plafont, amelyet a Google tömeges küldői irányelvei keménykörülhatárolnak.
Tisztítsa meg a listát. Hagyja ki a nem érdeklődőket és a megvásárolt vagy lekutatott adatokat; csak azoknak küldjön, akik kérték.
Vezessen be RFC 8058 egyetlen kattintásos leiratkozást a tömeges leveleken — a Google szabályai megkövetelik, és minden leiratkozás, ami nem „spam” kattintás, védi az arányát.
Tartsa az igazítást igazítva (SPF és DKIM a saját domainjén), hogy a hírnév egy általa irányított domainen halmozódjon.

Gyakran ismételt kérdések

Az 550-5.7.1 ugyanaz, mint az 550-5.7.26? Nem. Az 550-5.7.26 a Gmail hitelesítési követelmények kódcsaládja (SPF/DKIM hiányzik vagy megbukik) — és a Google jelenlegi referenciája a DMARC-szabályzat visszautasítását is ott sorolja be. Az 550-5.7.1 a régebbi szabályzati kódcsalád: fogadói és küldői szabályzatblokkok, IPv6-PTR-nélkül, spam és hírnévblokkok. A visszapattanás szövege, nem a szám, mondja meg, melyik javítás vonatkozik (a 2026-06-29 és a jelenlegi Google irányelvek szerint).

Vissza kell-e állítanom a DMARC-szabályzatot p=none értékre a visszapattanások megállításához? Ez azzal állítja meg, hogy lebontja a kerítést. A Defaults.Exposed népszámlálás (2026-06-29) 261,086,232 domainjéből mindössze 10.59% érvényesíti egyáltalán a DMARC-ot; ha Ön közülük való, tartsa fenn, és javítsa a nem hitelesített forrást — a szabályzat lazítása újra megnyitja a pontos domainhamisítást.

Miért blokkolja a Gmail a levelemet, ha az SPF-rekordom átmegy minden ellenőrzőn? Az ellenőrzők a rekordot tesztelik; a Gmail az üzenetet teszteli. Az SPF-et a Return-Path domain ellen értékelik, nem a látható Feladó-cím ellen, tehát egy szállítói bounce-domainen való átmenet semmit sem tesz a DMARC-igazítás érdekében — és a hírnévblokkok teljesen figyelmen kívül hagyják az SPF-et. Az ingyenes vizsgálat megmutatja, melyik réteg hibázik ténylegesen.

Az 550-5.7.1 azt jelenti, hogy az IP-m blokklistán van? Nem feltétlenül. A Gmail a saját hírnévrendszerét futtatja; letilthatja Önt, miközben egyetlen nyilvános blokklista sem sorol. Ellenőrizze a Postmaster Tools-ban a Google nézőpontját — és vegye figyelembe, hogy a hitelesítés javítása megakadályozza a jövőbeli károkat, de önmagában nem állítja vissza a rossz küldési hírnevet.

Küldje el a tulajdonosnak a jelentést

Amint a visszapattanást javította, futtassa újra a vizsgálatot, és küldje el az értékelt jelentést a vállalkozás tulajdonosának vagy ügyfelének, akinek a levele visszapattant. Egyszerű magyar nyelven megmutatja, mi volt elromlva, mit javított, és hol áll most a domain a 261 milliós alaptól — pontosan az, amire szükségük van a biztosítás megújításakor vagy az ügyfél biztonsági kérdőívéhez, amely azt kérdezi: „Hitelesíti az e-mailjeit?”. A csendesen javított visszapattanás láthatatlan munka; az előtte-utána jelentés bizonyíték.

Ellenőrizze a domainjét → · Gmail 550-5.7.26 — a javítás követelmény-sorrendben → · DMARC javítása → · Hogyan értékelünk → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.