Perché Gmail rifiuta un’email anche se SPF e DKIM sono entrambi corretti? La dashboard del tuo tool di emailing mostra “inviato”. Una parte dei tuoi destinatari Gmail però non riceve mai nulla. La spiegazione sta in un codice che pochi sanno leggere: 550 5.7.25.
Errore 550 5.7.25 = l’IP di invio non ha un PTR (reverse DNS) valido oppure questo PTR non ri-risolve verso la stessa IP in senso inverso (forward-confirmed reverse DNS, FCrDNS). Bastano 3 verifiche DNS per isolare quale delle 2 cause ti riguarda. La correzione dipende poi da chi controlla la zona reverse: l’hosting provider su un VPS o un server dedicato, il fornitore su un ESP.
Cosa significa davvero il codice 550 5.7.25
Quando il tuo server contatta Gmail, lo scambio inizia con un EHLO seguito da un MAIL FROM che dichiara il mittente. Gmail verifica in quel momento l’identità di rete dell’IP di origine, ancora prima di leggere il contenuto del messaggio. Il codice 5.7.25 è un Enhanced Status Code. La classe 5.7.x copre i rifiuti legati a sicurezza e autenticazione. Il suffisso .25 indica precisamente un problema di reverse DNS. Questo dettaglio torna utile: un rifiuto generico come l’errore SMTP 554 5.0.0 lascia aperte 5 possibili cause, mentre il 5.7.25 ne indica una sola.
« 550-5.7.25 [IP] The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not match the sending IP. As a policy, Gmail does not accept messages from IPs with missing PTR records. »
Questo è il testo esatto restituito dal server di ricezione. Sono coinvolti 2 record DNS. Il PTR (pointer) traduce un’IP in un nome host: è la ricerca inversa. Il record A (o AAAA in IPv6) fa l’opposto, traduce un nome host in IP. Gmail richiede che i 2 si corrispondano: il PTR della tua IP deve puntare a un hostname e quell’hostname deve ri-risolvere verso la stessa IP. Senza questo ciclo chiuso, il messaggio finisce nel NDR (Non-Delivery Report) del tuo server con il codice 550 5.7.25, ancora prima di essere filtrato come spam.
Perché questo rifiuto è diventato più frequente da dicembre 2025
Il codice 5.7.25 esiste da diversi anni. I rifiuti erano rari prima della fine del 2025. Secondo Spam Resource (dicembre 2025), Google ha inasprito l’applicazione di questa regola: le IP con reverse DNS incompleto o incoerente, che prima passavano tra le maglie del controllo, ora vengono bloccate in modo più sistematico.
Questo inasprimento segue una tendenza avviata a febbraio 2024, quando Gmail e Yahoo hanno iniziato ad applicare requisiti comuni ai mittenti, con una soglia di reclami spam fissata allo 0,3%. Il nostro articolo sull’aumento dei rifiuti SMTP e i requisiti mittente di Gmail approfondisce queste soglie. Il PTR è solo uno dei controlli di questa lista, ma è uno dei pochi che blocca la connessione ancora prima che il contenuto del messaggio venga esaminato.
Diagnosticare il PTR in 3 verifiche
Prima di contattare chiunque, verifica 3 cose in ordine. Ognuna elimina una possibile causa.
- Verifica il PTR IPv4 dell’IP che invia realmente il messaggio, non l’IP del tuo server web ma l’IP SMTP in uscita. Il rimbalzo te la fornisce, appare tra parentesi quadre subito dopo il codice 550-5.7.25. Lancia
dig -x 203.0.113.10 +shortda qualsiasi macchina. Su Windows,nslookup 203.0.113.10restituisce la stessa risposta. Una risposta vuota indica un PTR assente, quindi la causa n°1. - Verifica il PTR IPv6 con
dig -x 2001:db8::25 +shortse il tuo server può trasmettere con questo protocollo. È il punto che la maggior parte delle checklist salta. Un server con connettività IPv6 apre la connessione verso Gmail in IPv6 di default, dato che gli MX di Gmail pubblicano record AAAA. Le linee guida ufficiali di Google per i mittenti sono chiare su questo punto: un errore di autorizzazione IPv6 deriva il più delle volte da un PTR presente solo in IPv4. Un PTR IPv4 impeccabile accompagnato da un PTR IPv6 assente fa quindi rifiutare quelle connessioni, con un 550 5.7.25 oppure con il 550 5.7.1 riservato ai requisiti IPv6 a seconda dei casi. - Verifica il forward match: l’hostname restituito dal PTR deve avere un record A (o AAAA) che ripunta verso la stessa IP di partenza. Riprendi l’hostname del passaggio precedente e lancia
dig A mail.tuodominio.it +short, poidig AAAA mail.tuodominio.it +shortin IPv6. L’IP restituita deve essere esattamente quella di partenza. Uno scarto in questo passaggio, anche minimo, rompe l’FCrDNS.
Il dettaglio passo-passo di queste operazioni, comandi inclusi, è coperto nella nostra guida sul reverse DNS lookup.
Correggere in base a chi controlla il tuo reverse DNS
Un PTR non si modifica mai dal pannello di amministrazione del tuo dominio: appartiene al proprietario del blocco di indirizzi IP. La procedura da seguire cambia a seconda di chi possiede quella zona reverse.
| Tipo di hosting | Chi controlla il PTR | Procedura da seguire | Tempo di propagazione |
|---|---|---|---|
| VPS o server dedicato (OVH, Hetzner, DigitalOcean, AWS EC2) | L’hosting provider, tramite il suo pannello di rete o un ticket di supporto | Rinominare il droplet o l’istanza con l’hostname desiderato (DigitalOcean), richiedere il PTR tramite le impostazioni di IP elastica (AWS) oppure aggiungerlo nella sezione rete del pannello cliente (Hetzner, OVH) | Da pochi minuti a qualche ora |
| Hosting condiviso | Solo l’hosting provider, spesso su un pool di IP condiviso | Aprire un ticket di supporto specificando l’IP in uscita esatta e l’hostname atteso | Variabile, a volte diversi giorni a seconda del fornitore |
| ESP o SaaS di emailing (Brevo, Mailgun, SendGrid, Google Workspace) | Il fornitore, sulle proprie IP | Niente da fare da parte tua sul PTR: verifica piuttosto l’allineamento di SPF, DKIM e DMARC sul dominio di invio | Non applicabile, già gestito |
Su AWS, il PTR si richiede dalla console EC2 (sezione IP elastica) oppure tramite ticket se l’IP non è elastica. Su DigitalOcean, basta rinominare il droplet con l’FQDN desiderato: il PTR si aggiorna automaticamente. Verifica poi con un invio di prova che il ciclo A/PTR sia effettivamente chiuso. Il tempo di propagazione reale si colloca generalmente tra pochi minuti e qualche ora. Prevedi una finestra di 2-4 ore prima di ritestare se la prima verifica fallisce ancora.
La trappola del PTR generico che supera il controllo tecnico
Un caso ricorrente: il PTR esiste e risolve correttamente anche in andata e ritorno. Il rifiuto persiste comunque. La causa più frequente è un PTR generico assegnato automaticamente dall’hosting provider, del tipo 123-45-67-89.provider.com.
Tecnicamente, questo PTR supera il controllo FCrDNS: punta verso un hostname e quell’hostname ripunta verso la stessa IP. Il problema sta altrove. Un’IP servita solo per hosting generico, senza uno storico di invio dedicato né un hostname personalizzato, corrisponde al profilo dei server compromessi usati per spam di massa. Gmail tratta questo segnale come debole, anche quando il ciclo tecnico è chiuso. La correzione consiste nel richiedere un PTR personalizzato che riprenda il nome di dominio o il sottodominio realmente usato per l’invio, ad esempio mail.tuodominio.it invece dell’hostname predefinito del server.
Altra obiezione frequente: “passo da una piattaforma di emailing, questo problema non mi riguarda”. È vero per il PTR in sé: i grandi ESP gestiscono le proprie IP e il proprio reverse DNS. Ma lo stesso sintomo, un rifiuto Gmail mentre tutto sembra configurato correttamente, può derivare da un dominio di invio mal allineato in DKIM, un problema distinto dal PTR. Verificare quale dei due è la causa evita di perdere tempo a contattare l’interlocutore sbagliato. Un rapporto DMARC aggregato mostra quale sorgente di invio fallisce l’allineamento.
Dopo aver corretto il PTR, verificare che il resto non danneggi la tua reputazione mittente
Correggere il PTR risolve il rifiuto SMTP immediato. Non garantisce nulla sul seguito. La reputazione mittente (sender reputation) su Gmail si costruisce su più segnali cumulati: il tasso di hard bounce, il tasso di reclamo (complaint rate) e lo storico di invio dell’IP. La sola conformità DNS non basta.
Su un’IP in pool condiviso, questo cumulo si gioca in più mani: se un altro cliente dello stesso pool genera un tasso di hard bounce elevato, la tua deliverability ne subisce le conseguenze anche con un PTR perfetto. Su un’IP dedicata in fase di IP warm-up, ogni invio verso un indirizzo non valido o inattivo pesa di più sulla curva di fiducia che Gmail costruisce, perché il volume di riferimento è ancora basso.
“Verificare le email prima di inviare costa caro, tanto vale filtrare dopo.” L’ordine conta proprio qui: un hard bounce rilevato da Gmail dopo l’invio danneggia già la reputazione dell’IP nel momento in cui si verifica. Un indirizzo non valido rimosso prima dell’invio non lascia alcuna traccia negativa. Far passare un campione della tua prossima lista attraverso una verifica prima della campagna mostra concretamente la differenza tra i 2 approcci sul tasso di hard bounce reale.
Il postmaster di Gmail (Google Postmaster Tools) resta la fonte più affidabile per monitorare questa reputazione nel tempo, sia a livello di IP che di dominio. La nostra guida sulla reputazione di un indirizzo IP spiega come leggere questi dati e individuare un blacklisting agli esordi.
Domande frequenti sull’errore 550 5.7.25
Il codice 550 5.7.25 blocca tutte le mie email o solo alcune?
Il rifiuto si applica per IP. Può anche limitarsi a un solo protocollo se il PTR IPv4 è corretto ma manca il PTR IPv6. Se la tua infrastruttura invia da più IP, solo i flussi che passano dall’IP in difetto vengono rifiutati e gli altri continuano ad arrivare normalmente.
Le mie email inoltrate a un indirizzo Gmail rimbalzano con 550 5.7.25, perché?
Gmail controlla il PTR della macchina che apre la connessione, non quello del mittente originale. Su un inoltro automatico, ad esempio una casella professionale che reindirizza verso una Gmail personale, è quindi il server che inoltra a dover avere un PTR valido, anche quando il mittente iniziale è configurato in modo impeccabile dal suo lato. Lo stesso meccanismo vale per un relay SMTP secondario o un gateway antispam posto davanti al tuo server. Leggi l’IP tra parentesi quadre nel rimbalzo: è quella di cui va corretto il reverse. Spesso appartiene a una macchina a cui avresti pensato per ultima.
Quanto tempo serve perché la correzione del PTR sia effettiva?
La propagazione si gioca generalmente tra pochi minuti e qualche ora. Attendi una finestra di 2-4 ore prima di ritestare, il tempo che i resolver DNS aggiornino la loro cache.
Passare da un ESP mi protegge automaticamente da questo errore?
Sì, per il PTR in sé: le grandi piattaforme gestiscono il proprio reverse DNS sulle loro IP. Un rifiuto Gmail che persiste nonostante un ESP deriva generalmente da un problema di allineamento DKIM o da un dominio di invio mal configurato, raramente dal PTR in sé.
Un PTR IPv4 è sufficiente se il mio server invia anche in IPv6?
No, vedi la verifica n°2 sopra per diagnosticare questo caso specifico. Se il tuo hosting provider non offre un PTR IPv6, disattivare l’invio in uscita in IPv6 lato server resta una soluzione di ripiego più rapida di un ticket di supporto in attesa di risposta.
