Gmail „550-5.7.1 Message Blocked" — Decodificați bounce-ul și reparați-l (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

Gmail returnează 550-5.7.1 când blochează un mesaj din motive de politică mai degrabă decât o înregistrare lipsă: politica unui domeniu de trimitere sau de primire, o conexiune IPv6 fără DNS invers sau spam suspectat. Din cele 12,145,313 domenii care autorizează propriile servere Google în SPF, doar 18.5% aplică DMARC, conform recensământului Defaults.Exposed al 261 milioane de domenii.

550-5.7.1 este cea mai veche respingere omnivă a Gmail, iar remedierea depinde de propoziția de după cod din bounce-ul dvs. Mai jos: un tabel decodificator pentru formularea exactă, apoi calea de remediere per variantă — respingeri de politică, servere IPv6 fără DNS invers, blocaje de spam sau conținut — plus codurile similare cu care oamenii le confundă, inclusiv familia 5.7.26 pe care Google o folosește acum pentru respingerea politicii DMARC pe care referințele mai vechi o clasau sub 5.7.1.

Ce înseamnă de fapt Gmail 550-5.7.1?

În schema de stare îmbunătățită SMTP (RFC 3463), fiecare cod 5.7.x înseamnă „eșec permanent, motive de politică”. Gmail folosește 550-5.7.1 ca familia sa veche de politică: blocaje de politică ale expeditorului sau destinatarului, blocaje de reputație spam și — varianta care surprinde cei mai mulți administratori — e-mail care sosește peste IPv6 de la un server fără înregistrare DNS invers (PTR).

Google a recodificat variantele în timp. Respingerea politicii DMARC (“not accepted due to domain’s DMARC policy”) se află acum sub 550-5.7.26 în referința curentă Google, deși bounce-urile mai vechi în circulație pot arăta totuși 5.7.1; blocajul de securitate a conținutului este acum codat 552 5.7.0. Alte două surori sunt confundate cu 5.7.1: 550-5.7.26, familia cerințelor de autentificare (propriul ghid), și 550-5.7.25, codul PTR lipsă pentru orice versiune IP. Indiferent de cod, decodificați textul de mai jos.

Ce variantă de 550-5.7.1 aveți?

Potriviți formularea din raportul de nelivrare (NDR). Google ajustează aceste șiruri între ani — potriviți esența, nu punctuația.

Bounce-ul dvs. citește…	Ce înseamnă	Calea dvs. de remediere
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	Serverul dvs. a livrat peste IPv6 fără DNS invers (sau cu unul nepotrivit)	Înregistrare PTR pentru adresa IPv6, sau rutare prin smarthost-ul furnizorului (mai jos)
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	Un blocaj de politică — al destinatarului sau al propriului dvs. domeniu	Contactați administratorul receptor; dacă DMARC-ul propriului dvs. domeniu este politica în joc, consultați mai jos
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	Blocaj de spam/reputație pe conținut, IP sau domeniu	Postmaster Tools + igienă listă + dezabonare cu un clic (mai jos)
“This message is likely suspicious due to the very low reputation of the sending domain” (sau “…sending IP address”)	Blocaj de reputație — domeniu sau IP	Aceeași cale de reputație (mai jos)
“Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — codat 550-5.7.26 în referința curentă Google; bounce-urile mai vechi pot arăta totuși 5.7.1	Propria dvs. politică DMARC a spus Gmail să respingă un mesaj neautentificat	Găsiți sursa neautentificată — nu slăbiți mai întâi politica (mai jos)
“…blocked because its content presents a potential security issue.” — acum codat 552 5.7.0	Blocaj de conținut/politică (tip atașament, reputație link)	Eliminați clasa de conținut semnalat; verificați linkuri și atașamente
Codul este 550-5.7.25, “the sending IP address doesn’t have a PTR record”	DNS invers lipsă pentru orice versiune IP	Aceeași remediere rDNS ca varianta IPv6
Codul este 550-5.7.26	Familia cerințelor de autentificare, nu 5.7.1	Consultați ghidul 550-5.7.26
Codul este 421-4.7.0, “Try again later, closing connection.”	Amânare temporară — rată sau reputație, nu un blocaj permanent	Încetiniți, reparați autentificarea și rata de spam; de obicei se clarifică

Cum reparați un bounce 550-5.7.1?

Rulați scanarea gratuită la defaults.exposed — clasifică SPF, DKIM și DMARC cum le vede lumea, înainte de a atinge DNS-ul, și arată dacă varianta DMARC este posibilă pentru domeniul dvs.
Citiți textul complet al NDR față de tabelul decodificator — propoziția, nu codul, identifică cauza.
Varianta DMARC: găsiți ce sursă de trimitere a eșuat autentificarea și reparați acea sursă (secțiunea următoare).
Varianta IPv6/PTR: adăugați DNS invers corespunzător pentru adresa IPv6 a serverului sau rutați prin smarthost-ul furnizorului dvs.
Varianta spam/politică: Postmaster Tools, rata de spam sub 0,10% (plafonul greu al cerințelor Google este 0,30%), igienă listă, dezabonare cu un clic RFC 8058.
Re-trimiteți un test la o căsuță poștală Gmail și re-scanați — confirmați că bounce-ul a dispărut și că calificativul îl reflectă.

Bounce-ul menționează politica DMARC — de ce aceasta este politica dvs. care funcționează

Referința curentă Google codifică acest șir ca 550-5.7.26, dar bounce-urile mai vechi și documentele terțe îl arată încă sub 5.7.1 — oricum mecanica este identică. Se citește invers până îl vedeți: Gmail a verificat un mesaj care pretindea că vine de la domeniul dvs., a constatat că nici SPF nici DKIM nu au trecut cu aliniere, a căutat înregistrarea dvs. DMARC și a făcut exact ce ați cerut — respingere. Gardul dvs. a ținut. Întrebarea este ce s-a prins în el: un expeditor legitim uitat (un CRM, un instrument de facturare, o platformă de newsletter) sau o falsificare reală.

Deci nu slăbiți mai întâi politica. Găsiți sursa neautentificată. Două capcane explică cele mai multe cazuri:

SPF trece, dar pe domeniul greșit. Receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom), nu antetul From. Un instrument SaaS care trimite „de la” dvs. trece de obicei SPF pe propriul domeniu de bounce, care nu se aliniază cu domeniul dvs. From — deci DMARC eșuează totuși. Ghid: DMARC eșuează dar SPF și DKIM trec.
DKIM trece, dar cu semnătura implicită. gappssmtp.com al Google Workspace și onmicrosoft.com al Microsoft se verifică bine și nu se aliniază cu nimic. Consultați DKIM trece dar DMARC tot eșuează.

Această variantă este mai rară decât ați crede: 27,640,987 din 261,086,232 domenii — 10.59% — aplică o politică DMARC de carantină sau respingere, conform recensământului Defaults.Exposed (2026-06-29). Ceilalți 89.41% nu văd niciodată acest bounce deoarece nu au niciun gard de ținut. Repararea sursei, nu a politicii, este acoperită de la cap la coadă în ghidul de reparare DMARC.

Bounce-ul menționează ghidurile de trimitere IPv6 — remedierea DNS invers

Serverele moderne se conectează adesea la Gmail prin IPv6 implicit, iar Google cere adresei IPv6 de conectare să aibă o înregistrare PTR care să se rezolve la un hostname care se rezolvă înapoi la aceeași adresă (DNS invers confirmat înainte). Ratați asta și fiecare mesaj primește 550-5.7.1 indiferent cât de curat este SPF-ul dvs.

Trei remedieri, în ordinea preferinței:

Setați înregistrarea PTR pentru adresa IPv6 a serverului dvs. — făcut acolo unde trăiește IP-ul (panoul de control al gazdei VPS sau ISP-ului, nu zona DNS a domeniului dvs.), cu o înregistrare AAAA corespunzătoare care pointează înapoi.
Rutați prin smarthost-ul furnizorului dvs. Dacă nu puteți controla rDNS, rutați e-mailul de ieșire prin releul furnizorului de e-mail sau al ISP-ului dvs., care are deja rDNS corespunzător.
Preferați transportul IPv4 ca soluție temporară. De obicei ascunde simptomul deoarece adresa dvs. IPv4 are un PTR — o soluție de lucru, nu o remediere. Setați PTR-ul IPv6 când puteți.

Bounce-ul spune „likely unsolicited email” — calea reputației

Aici autentificarea poate fi în regulă, dar filtrele Gmail nu au încredere în e-mail. Autentificarea este podeaua, nu tavanul — dintre cele 12,145,313 domenii care autorizează _spf.google.com, doar 8.0% blochează SPF cu un -all strict, deci un check care trece nu spune mare lucru în sine. (Comparație completă: care furnizor de e-mail oferă cele mai puternice valori implicite SPF.)

Lista de verificare a reputației:

Înregistrați-vă în Google Postmaster Tools și urmăriți tabloul de bord al ratei de spam — păstrați-l sub 0,10% și nu lăsați niciodată să ajungă la plafonul de 0,30% pe care ghidurile Google pentru expeditorii de masă îl setează ca cerință strictă.
Curățați lista. Eliminați cei care nu interacționează și orice cumpărat sau scraped; trimiteți doar la persoanele care au cerut.
Implementați dezabonarea cu un clic RFC 8058 la e-mailul de masă — cerut de regulile Google, și fiecare dezabonare care nu este un clic pe „spam” vă protejează rata.
Păstrați autentificarea aliniată (SPF și DKIM pe propriul dvs. domeniu) astfel încât reputația să se acumuleze la un domeniu pe care îl controlați.

Întrebări frecvente

Este 550-5.7.1 același lucru cu 550-5.7.26? Nu. 550-5.7.26 este familia cerințelor de autentificare Gmail (SPF/DKIM lipsă sau eșuând) — și referința curentă Google clasează acolo și respingerea politicii DMARC. 550-5.7.1 este familia veche de politică: blocaje de politică ale destinatarului și expeditorului, IPv6-fără-PTR, spam și blocaje de reputație. Textul bounce-ului, nu numărul, vă spune ce remediere se aplică (din 2026-06-29 și ghidurile curente Google).

Ar trebui să setez politica DMARC înapoi la p=none pentru a opri bounce-urile? Asta le oprește demolând gardul. Doar 10.59% din cele 261,086,232 domenii din recensământul Defaults.Exposed (2026-06-29) aplică DMARC deloc; dacă sunteți unul dintre ele, păstrați-l și reparați sursa neautentificată — slăbirea politicii re-deschide falsificarea domeniului exact.

De ce Gmail blochează e-mailul meu când înregistrarea SPF trece fiecare verificator? Verificatoarele testează înregistrarea; Gmail testează mesajul. SPF este evaluat față de domeniul Return-Path, nu adresa From vizibilă, deci un pass pe domeniul de bounce al unui vendor nu face nimic pentru alinierea DMARC — iar blocajele de reputație ignoră SPF complet. Scanarea gratuită arată ce strat eșuează de fapt.

550-5.7.1 înseamnă că IP-ul meu este pe o listă neagră? Nu neapărat. Gmail rulează propriul sistem de reputație; puteți fi blocat de Google în timp ce nu vă aflați pe nicio listă de blocare publică. Verificați Postmaster Tools pentru viziunea Google — și notați că repararea autentificării previne daunele viitoare dar nu resetează în sine o reputație de trimitere slabă.

Trimiteți proprietarului raportul

Odată ce bounce-ul este reparat, re-rulați scanarea și trimiteți raportul clasificat proprietarului afacerii sau clientului al cărui e-mail era respins. Arată, în limbaj simplu, ce era stricat, ce ați reparat și unde se află acum domeniul față de linia de bază de 261 milioane de domenii — exact ce au nevoie pentru reînnoirea asigurării sau chestionarul de securitate al clienților care întreabă „vă autentificați e-mailul?”. Un bounce reparat în tăcere este muncă invizibilă; un raport înainte-și-după este dovadă.

Verificați domeniul → · Gmail 550-5.7.26 — remedierea în ordinea cerințelor → · Corectați DMARC → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.