Gmail "550-5.7.1 Message Blocked" — decodifichi il bounce e lo risolva (2026)

Pubblicato 2026-07-08

Dati aggiornati al 2026-06-29 · metodologia v7. Dati censuari aggregati su 261 milioni di domini valutati. Veda come assegniamo i voti.

Gmail restituisce 550-5.7.1 quando blocca un messaggio per motivi di policy anziché per un record mancante: la policy di un dominio mittente o destinatario, una connessione IPv6 senza DNS inverso, o un sospetto di spam. Dei 12.145.313 domini che autorizzano in SPF i server di Google stessa, solo il 18,5% applica DMARC, secondo il censimento Defaults.Exposed su 261 milioni di domini.

550-5.7.1 è il rifiuto generico più vecchio di Gmail, e la soluzione dipende dalla frase che segue il codice nel Suo bounce. Qui sotto: una tabella di decodifica per la formulazione esatta, poi il percorso di correzione per ciascuna variante — rifiuti di policy, server IPv6 senza DNS inverso, blocchi per spam o contenuti — più i codici simili con cui viene confuso, inclusa la famiglia 5.7.26 che Google ora usa per il rifiuto da policy DMARC che i riferimenti più vecchi archiviavano sotto 5.7.1.

Cosa significa davvero il 550-5.7.1 di Gmail?

Nello schema degli enhanced status SMTP (RFC 3463), ogni codice 5.7.x significa “errore permanente, motivi di policy”. Gmail usa 550-5.7.1 come famiglia di policy storica: blocchi da policy del mittente o del destinatario, blocchi per reputazione spam e — la variante che sorprende più amministratori — posta in arrivo su IPv6 da un server privo di record DNS inverso (PTR).

Google ha ricodificato le varianti nel tempo. Il rifiuto da policy DMARC (“not accepted due to domain’s DMARC policy”) oggi sta sotto 550-5.7.26 nel riferimento attuale di Google, anche se bounce più vecchi in circolazione possono ancora mostrarlo come 5.7.1; il blocco di sicurezza sui contenuti è ora codificato 552 5.7.0. Altri due fratelli vengono confusi con 5.7.1: 550-5.7.26, la famiglia dei requisiti di autenticazione (la sua guida dedicata), e 550-5.7.25, il codice del PTR mancante su qualunque versione IP. Qualunque sia il codice, decodifichi il testo qui sotto.

Quale variante di 550-5.7.1 ha davanti?

Confronti la formulazione nel Suo rapporto di mancata consegna (NDR). Google ritocca queste stringhe da un anno all’altro: confronti il senso, non la punteggiatura.

Il Suo bounce assomiglia a…	Cosa significa	Il Suo percorso di correzione
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	Il Suo server ha consegnato via IPv6 senza DNS inverso (o con uno non corrispondente)	Record PTR per l’indirizzo IPv6, oppure relay tramite lo smarthost del Suo provider (sotto)
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	Un blocco di policy — del destinatario, o del Suo stesso dominio	Contatti l’amministratore ricevente; se la policy in gioco è il DMARC del Suo dominio, veda sotto
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	Blocco per spam/reputazione su contenuto, IP o dominio	Postmaster Tools + igiene della lista + disiscrizione con un clic (sotto)
“This message is likely suspicious due to the very low reputation of the sending domain” (oppure “…sending IP address”)	Blocco reputazionale — dominio o IP	Stesso percorso reputazionale (sotto)
“Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — codificato 550-5.7.26 nel riferimento attuale di Google; bounce più vecchi possono ancora mostrare 5.7.1	La Sua stessa policy DMARC ha detto a Gmail di rifiutare un messaggio non autenticato	Individui la sorgente non autenticata — non ammorbidisca la policy per prima cosa (sotto)
“…blocked because its content presents a potential security issue.” — ora codificato 552 5.7.0	Blocco su contenuto/policy (tipo di allegato, reputazione dei link)	Rimuova la classe di contenuto segnalata; controlli link e allegati
Il codice è 550-5.7.25, “the sending IP address doesn’t have a PTR record”	DNS inverso mancante su qualunque versione IP	Stessa correzione rDNS della variante IPv6
Il codice è 550-5.7.26	Famiglia dei requisiti di autenticazione, non 5.7.1	Veda la guida al 550-5.7.26
Il codice è 421-4.7.0, “Try again later, closing connection.”	Rinvio temporaneo — ritmo o reputazione, non un blocco permanente	Rallenti, sistemi autenticazione e tasso di spam; di norma si risolve

Come si risolve un bounce 550-5.7.1?

Esegua la scansione gratuita su defaults.exposed — valuta SPF, DKIM e DMARC come li vede il mondo, prima che Lei tocchi il DNS, e mostra se la variante DMARC è anche solo possibile per il Suo dominio.
Legga il testo completo dell’NDR confrontandolo con la tabella di decodifica: è la frase, non il codice, a identificare la causa.
Variante DMARC: individui quale sorgente di invio ha fallito l’autenticazione e sistemi quella sorgente (sezione seguente).
Variante IPv6/PTR: aggiunga un DNS inverso corrispondente per l’indirizzo IPv6 del server, oppure faccia transitare la posta dallo smarthost del Suo provider.
Variante spam/policy: Postmaster Tools, tasso di spam sotto lo 0,10% (il tetto vincolante di Google è lo 0,30%), igiene della lista, disiscrizione con un clic RFC 8058.
Reinvii un test a una casella Gmail e riesegua la scansione — confermi che il bounce è sparito e che il voto lo riflette.

Il bounce menziona la Sua policy DMARC — ecco perché è la Sua policy che funziona

Il riferimento attuale di Google codifica questa stringa come 550-5.7.26, ma bounce più vecchi e documentazione di terzi la mostrano ancora sotto 5.7.1 — in entrambi i casi la meccanica è identica. Sembra assurdo finché non lo si vede: Gmail ha controllato un messaggio che dichiarava di provenire dal Suo dominio, ha rilevato che né SPF né DKIM sono passati con allineamento, ha consultato il Suo record DMARC e ha fatto esattamente ciò che Lei ha chiesto — rifiutare. Il Suo recinto ha tenuto. La domanda è cosa ci è rimasto impigliato: un mittente legittimo dimenticato (un CRM, uno strumento di fatturazione, una piattaforma newsletter) o un vero spoofing.

Quindi non ammorbidisca la policy come primo passo. Individui la sorgente non autenticata. Due trappole coprono la maggior parte dei casi:

SPF passa, ma sul dominio sbagliato. I riceventi valutano SPF rispetto al dominio del Return-Path (RFC5321.MailFrom), non all’header From. Uno strumento SaaS che invia “a Suo nome” di solito supera SPF sul proprio dominio di bounce, che non si allinea con il Suo dominio From — quindi DMARC fallisce comunque. Il percorso completo: DMARC fallisce ma SPF e DKIM passano.
DKIM passa, ma con la firma predefinita. I default gappssmtp.com di Google Workspace e onmicrosoft.com di Microsoft si verificano senza problemi e non si allineano con nulla. Veda DKIM passa ma DMARC fallisce comunque.

Questa variante è più rara di quanto si pensi: 27.640.987 domini su 261.086.232 — il 10,59% — applicano una policy DMARC di quarantine o reject, secondo il censimento Defaults.Exposed (2026-06-29). L’altro 89,41% non vede mai questo bounce perché non ha alcun recinto che possa tenere. Sistemare la sorgente, non la policy, è trattato da cima a fondo nella guida alla correzione DMARC.

Il bounce menziona le linee guida di invio IPv6 — la correzione del DNS inverso

I server moderni spesso si connettono a Gmail via IPv6 per impostazione predefinita, e Google richiede che l’indirizzo IPv6 di connessione abbia un record PTR che risolve in un hostname che a sua volta risolve nello stesso indirizzo (DNS inverso a conferma diretta). Manchi questo, e ogni messaggio riceve 550-5.7.1 a prescindere da quanto sia pulito il Suo SPF.

Tre correzioni, in ordine di preferenza:

Imposti il record PTR per l’indirizzo IPv6 del Suo server — si fa dove vive l’IP (il pannello di controllo del Suo host VPS o ISP, non la zona DNS del Suo dominio), con un record AAAA corrispondente che punta indietro.
Faccia relay tramite lo smarthost del Suo provider. Se non può controllare l’rDNS, instradi la posta in uscita attraverso il relay del Suo provider email o ISP, che ha già un rDNS corretto.
Preferisca il trasporto IPv4 come tampone. Di solito nasconde il sintomo perché il Suo indirizzo IPv4 un PTR ce l’ha — un espediente, non una correzione. Imposti il PTR IPv6 appena può.

Il bounce dice “likely unsolicited email” — il percorso reputazionale

Qui l’autenticazione può essere a posto, ma i filtri di Gmail non si fidano della posta. L’autenticazione è il pavimento, non il soffitto — tra i 12.145.313 domini che autorizzano _spf.google.com, solo il 8,0% blinda SPF con un -all rigido, quindi un controllo superato dice poco da solo. (Confronto completo: quale provider email offre i default SPF più solidi.)

La checklist reputazionale:

Si registri in Google Postmaster Tools e tenga d’occhio il pannello del tasso di spam: lo mantenga sotto lo 0,10%, e non gli lasci mai raggiungere il tetto dello 0,30% che le linee guida di Google per i mittenti massivi fissano come requisito vincolante.
Pulisca la Sua lista. Elimini chi non interagisce e tutto ciò che è stato comprato o raccolto automaticamente; invii solo a chi lo ha chiesto.
Implementi la disiscrizione con un clic RFC 8058 sulla posta massiva — richiesta dalle regole di Google, e ogni disiscrizione che non è un clic su “spam” protegge il Suo tasso.
Mantenga l’autenticazione allineata (SPF e DKIM sul Suo dominio) così la reputazione si accumula su un dominio che controlla Lei.

Domande frequenti

550-5.7.1 è la stessa cosa di 550-5.7.26? No. 550-5.7.26 è la famiglia dei requisiti di autenticazione di Gmail (SPF/DKIM mancanti o falliti) — e il riferimento attuale di Google vi archivia anche il rifiuto da policy DMARC. 550-5.7.1 è la famiglia di policy più vecchia: blocchi da policy di destinatario e mittente, IPv6 senza PTR, blocchi per spam e reputazione. È il testo del bounce, non il numero, a dirLe quale correzione si applica (al 2026-06-29 e secondo le attuali linee guida di Google).

Devo riportare la mia policy DMARC a p=none per far cessare i bounce? Li fa cessare abbattendo il recinto. Solo il 10,59% dei 261.086.232 domini nel censimento Defaults.Exposed (2026-06-29) applica DMARC in modo vincolante; se Lei è tra questi, lo mantenga e sistemi la sorgente non autenticata — ammorbidire la policy riapre lo spoofing del dominio esatto.

Perché Gmail blocca la mia posta se il mio record SPF supera ogni strumento di verifica? Gli strumenti verificano il record; Gmail verifica il messaggio. SPF si valuta rispetto al dominio del Return-Path, non all’indirizzo From visibile, quindi un pass sul dominio di bounce di un fornitore non fa nulla per il Suo allineamento DMARC — e i blocchi reputazionali ignorano del tutto SPF. La scansione gratuita mostra quale livello sta davvero fallendo.

550-5.7.1 significa che il mio IP è in una blacklist? Non necessariamente. Gmail gestisce un proprio sistema di reputazione; può essere bloccato da Google senza figurare in alcuna blocklist pubblica. Controlli in Postmaster Tools il punto di vista di Google — e tenga presente che sistemare l’autenticazione previene danni futuri ma da sola non azzera una cattiva reputazione di invio.

Invii il report al titolare

Una volta risolto il bounce, riesegua la scansione e inoltri il report con il voto al titolare dell’azienda o al cliente la cui posta rimbalzava. Mostra, in linguaggio semplice, cosa era rotto, cosa ha sistemato Lei e dove si colloca ora il dominio rispetto alla base di 261 milioni di domini — esattamente ciò che serve per il rinnovo assicurativo o per il questionario di sicurezza del cliente che chiede “autenticate la vostra email?”. Un bounce risolto in silenzio è lavoro invisibile; un report prima-e-dopo è una prova.

Controlli il Suo dominio → · Gmail 550-5.7.26 — la correzione in ordine di requisito → · Sistemare DMARC → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.