Defaults.Exposed › Correzioni › Guides

Gmail 550 5.7.26 "The Sender Is Unauthenticated": la correzione, in ordine di requisito (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.26 quando il Suo messaggio fallisce i controlli di autenticazione SPF e DKIM. Si risolve facendo passare almeno uno tra SPF e DKIM per il Suo dominio mittente — e alla maggior parte dei mittenti manca proprio questo: dei 12.145.313 domini che autorizzano i server di Google via _spf.google.com, solo il 18,5% applica DMARC, secondo il censimento Defaults.Exposed su 261.086.232 domini.

La correzione è lavoro sul DNS, non un ticket di assistenza: confermi che il Suo IP di invio abbia un DNS inverso, faccia passare SPF o DKIM per il dominio che Gmail controlla davvero, poi allinei DKIM al Suo indirizzo From e pubblichi un record DMARC. Qui sotto trova l’ordine completo dei requisiti, più una tabella di decodifica per la famiglia 550 5.7.26 e i suoi codici affini.

Cosa significa l’errore Gmail 550 5.7.26?

Dai requisiti per i mittenti introdotti da Google nel 2024, ogni mittente verso Gmail — non solo i mittenti massivi — deve superare almeno uno tra SPF e DKIM per il dominio mittente. Fallisca entrambi e Gmail rifiuta già in fase SMTP con 550 5.7.26 invece di recapitare nello spam.

La versione attuale a testo completo recita: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” Bounce più vecchi in circolazione possono ancora riportare la formulazione precedente di Google (“This mail is unauthenticated, which poses a security risk…”), ed esiste un fratello legato ai limiti di ritmo — 421 4.7.26 This email has been rate limited because it is unauthenticated — con la stessa causa.

550 5.7.26 non è un messaggio unico ma parte di una famiglia di codici, e la formulazione Le dice quale gamba è caduta: il riferimento attuale di Google mantiene tre stringhe 5.7.26 (non autenticato, SPF hard fail, policy DMARC) e sposta i fallimenti solo-SPF e solo-DKIM dei mittenti massivi su codici propri, 5.7.27 e 5.7.30. Legga il testo esatto prima di toccare il DNS: è la Sua prima diagnosi.

L’ampiezza del divario è il motivo per cui questo bounce è così comune: 12.145.313 domini autorizzano i server di posta di Google nel loro record SPF (su 138.927.207 domini nel mondo che pubblicano SPF), eppure solo il 18,5% ha una policy DMARC vincolante e appena il 8,0% usa SPF strict (-all). La maggior parte dei mittenti ospitati su Google non soddisfa le stesse regole di Google per i mittenti massivi — e Gmail ora applica le basi a tutti.

Quale variante di 550 5.7.26 — o codice affine — ha davanti?

Confronti il testo del bounce che ha ricevuto con questa tabella. I frammenti citati seguono il riferimento attuale di Google agli errori SMTP — li verifichi sempre contro il Suo NDR reale, perché Google rivede periodicamente la formulazione.

Come si risolve 550 5.7.26, in ordine di requisito?

Google non pubblica un “ordine di verifica” letterale — ma i suoi requisiti si impilano logicamente, quindi li affronti in questo ordine di requisito. La maggior parte dei mittenti si sblocca dopo il passo 3; completi comunque la lista, perché i passi successivi sono ciò che La tiene fuori dallo spam una volta uscito dal bounce.

1. Esegua prima la scansione gratuita. Legge la Sua configurazione live di SPF, DKIM, DMARC e DNS e mostra esattamente quale gamba sta fallendo — diagnostichi prima di toccare il DNS.
2. Dia un DNS inverso (PTR) al Suo IP di invio. L’IP di connessione deve avere un record PTR il cui hostname risolva di nuovo nello stesso IP. I provider più diffusi lo gestiscono per Lei; colpisce chi invia dai propri server (ed è l’intera storia dietro il codice affine 550 5.7.25).
3. Faccia passare SPF o DKIM. Prima una regola di sicurezza: i riceventi valutano SPF rispetto al dominio del Return-Path (RFC5321.MailFrom), non all’header From — verifichi a quale dominio la Sua posta rimbalza davvero prima di decidere che SPF “dovrebbe” passare. Aggiunga i Suoi veri servizi di invio al record SPF di quel dominio (percorso SPF completo), oppure abiliti la firma DKIM presso il Suo provider (percorso DKIM completo). Basta che uno dei due passi per sbloccare il blocco base 550 5.7.26.
4. Allinei DKIM al Suo dominio From. Per l’invio massivo — e per DMARC — Gmail vuole l’autenticazione per il dominio del Suo indirizzo From, non per un default del fornitore. Utenti Google Workspace: pubblichino la propria chiave DKIM (configurazione DKIM per Workspace); una firma predefinita gappssmtp.com supera DKIM ma non si allinea — una trappola con la sua guida dedicata. Il DKIM allineato sopravvive anche all’inoltro, cosa che SPF non fa mai.
5. Pubblichi un record DMARC. I requisiti per i mittenti di Google chiedono almeno p=none con un indirizzo di reporting. È una modifica DNS da cinque minuti — veda “DMARC policy not enabled” per il primo passo onesto e per cosa p=none protegge e non protegge.
6. Invii tramite TLS. Qualunque server o provider di posta moderno lo fa di default; se gestisce un Suo MTA, confermi che il TLS in uscita sia attivo — la posta massiva senza ora rimbalza con un codice proprio, 550 5.7.29.
7. Aggiunga la disiscrizione con un clic RFC 8058 (header List-Unsubscribe + List-Unsubscribe-Post) per la posta di marketing e da iscrizione.
8. Mantenga il Suo tasso di spam sotto lo 0,10% in Google Postmaster Tools — e non gli lasci mai raggiungere lo 0,30%. Il tetto vincolante di Google è lo 0,3%; la sua raccomandazione è restare sotto lo 0,10%. Registri lì il Suo dominio: è la pagella che Google stessa Le dà, e la soglia del tasso di spam è il requisito che nessun record DNS può risolvere.

Una cosa che questa lista non farà: toglierLa da una blocklist di terzi. L’autenticazione ferma i rifiuti di Gmail per mancata autenticazione; un IP con uno storico di spam è un problema reputazionale con un percorso di bonifica proprio — sistemare l’autenticazione previene le ricadute, non La cancella dalle liste.

Le regole per i mittenti massivi si applicano se invia meno di 5.000 email al giorno?

La checklist completa — autenticazione allineata, DMARC pubblicato, disiscrizione con un clic, tasso di spam — si applica formalmente da 5.000+ messaggi al giorno verso Gmail, e i codici solo-massivi (5.7.27, 5.7.29, 5.7.30) provengono da quella fascia. Ma le basi dell’autenticazione (SPF o DKIM passante, PTR valido) vengono applicate a tutti, ed è per questo che anche i piccoli mittenti incappano nel 550 5.7.26. Consideri i passi 1–5 obbligatori a qualunque volume, i passi 7–8 obbligatori dal momento in cui invia in massa. L’insieme completo dei requisiti per entrambi i provider è nel nostro articolo dati sui requisiti per i mittenti di Google e Yahoo.

Domande frequenti

550 5.7.26 significa che il mio dominio o IP è in una blocklist? No. È un fallimento di autenticazione, non un giudizio reputazionale — Gmail sta dicendo “dimostri chi è”, non “sappiamo che è uno spammer”. È una buona notizia: si risolve interamente nel DNS. La cattiva notizia è quanto sia normale — sull’intero censimento di 261.086.232 domini (al 2026-06-29), solo il 10,59% ha una policy DMARC vincolante.

Sistemare solo SPF fermerà i bounce? Di solito sì, per la variante base — Gmail richiede almeno uno tra SPF e DKIM. Ma SPF si valuta rispetto al dominio del Return-Path e si rompe con l’inoltro, quindi il DKIM allineato (passo 4) è la correzione duratura. Solo il 8,0% dei 12.145.313 domini mittenti ospitati su Google usa SPF strict (dati al 2026-06-29), quindi in ogni caso sarà davanti al gruppo.

Uso Google Workspace — perché Google respinge la mia stessa posta? Perché Gmail autentica il dominio, non il fornitore delle caselle. Un dominio Workspace senza record SPF e senza chiave DKIM personalizzata invia posta che Google stessa non può verificare — dei 12.145.313 domini che autorizzano i server di Google, solo il 18,5% ha un DMARC vincolante (dati al 2026-06-29). Essere cliente di Google e rispettare le regole di Google sono due cose diverse.

Quanto tempo dopo la correzione DNS Gmail accetterà la mia posta? Non appena i nuovi record sono visibili — tipicamente da minuti a qualche ora, fino a 48 ore con TTL lenti. Le correzioni di autenticazione agiscono subito sul controllo 550 5.7.26; il recupero di tasso di spam e reputazione (421-4.7.0, 5.7.28) richiede da giorni a settimane di invii puliti.

Invii il report al titolare

Se sta risolvendo per un cliente, non chiuda il ticket con “bounce risolti”. Riesegua la scansione gratuita dopo le modifiche DNS e inoltri il report con il voto al titolare dell’azienda. Mostra, in linguaggio semplice, che il suo dominio ora autentica la propria email e dove è ancora carente — le prove che servono per i rinnovi della polizza cyber e per i questionari di sicurezza dei fornitori. Lei ha risolto il bounce; il report lo dimostra.

Controlli il Suo dominio gratis

Veda su quale gamba tra SPF, DKIM e DMARC Gmail La sta bocciando — in privato e visibile solo al titolare.

Controlli il Suo dominio → · Sistemare SPF → · Gmail “550-5.7.1 message blocked” → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.