¿Por qué Gmail rechaza un email cuando SPF y DKIM pasan los dos? El panel de tu herramienta de emailing muestra «enviado». Sin embargo, parte de tus destinatarios de Gmail nunca recibe nada. La explicación está en un código que pocos saben leer: 550 5.7.25.
Error 550 5.7.25 = la IP de envío no tiene un PTR (reverse DNS) válido o ese PTR no vuelve a resolver hacia la misma IP en sentido inverso (forward-confirmed reverse DNS, FCrDNS). Con 3 verificaciones DNS basta para aislar cuál de las 2 causas te afecta. La corrección depende después de quién controla la zona reverse: el proveedor de hosting en un VPS o servidor dedicado, el proveedor de servicios en un ESP.
Qué significa realmente el código 550 5.7.25
Cuando tu servidor contacta con Gmail, el intercambio empieza con un EHLO y luego un MAIL FROM que anuncia al remitente. Gmail verifica en ese momento la identidad de red de la IP de origen, antes incluso de leer el contenido del mensaje. El código 5.7.25 es un Enhanced Status Code: la clase 5.7.x cubre los rechazos relacionados con la seguridad y la autenticación, y el sufijo .25 apunta específicamente a un problema de reverse DNS. Esta precisión es una ventaja: un rechazo genérico como el error SMTP 554 5.0.0 deja 5 causas posibles abiertas, mientras que el 5.7.25 señala 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. »
Este es el texto exacto que devuelve el servidor receptor. Hay 2 registros DNS en juego: el PTR (pointer), que traduce una IP en un nombre de host (la búsqueda inversa), y el registro A (o AAAA en IPv6), que hace justo lo contrario y traduce un nombre de host en una IP. Gmail exige que los 2 se correspondan: el PTR de tu IP debe apuntar a un hostname y ese hostname debe volver a resolver hacia la misma IP. Sin este bucle cerrado, el mensaje termina en el NDR (Non-Delivery Report) de tu servidor con el código 550 5.7.25, incluso antes de ser filtrado como spam.
Por qué este rechazo se ha vuelto más frecuente desde diciembre de 2025
El código 5.7.25 existe desde hace varios años. Los rechazos eran poco frecuentes antes de finales de 2025. Según Spam Resource (diciembre de 2025), Google ha endurecido la aplicación de esta regla: las IP con un reverse DNS incompleto o incoherente, que antes se colaban por los agujeros, ahora se bloquean de forma más sistemática.
Este endurecimiento sigue una tendencia que empezó en febrero de 2024, cuando Gmail y Yahoo comenzaron a aplicar requisitos comunes para los remitentes, con un umbral de quejas de spam fijado en el 0,3 %. Nuestro artículo sobre el aumento de los rechazos SMTP y los requisitos para remitentes de Gmail detalla todos estos umbrales. El PTR es solo uno de los controles de esa lista, pero es uno de los pocos que bloquea la conexión incluso antes de que se examine el contenido del mensaje.
Diagnosticar el PTR en 3 verificaciones
Antes de contactar con nadie, comprueba 3 cosas en orden. Cada una descarta una causa posible.
- Comprueba el PTR IPv4 de la IP que envía realmente el mensaje, no la IP de tu servidor web sino la IP SMTP saliente. El rebote te la da, aparece entre corchetes justo después del código 550-5.7.25. Ejecuta
dig -x 203.0.113.10 +shortdesde cualquier máquina. En Windows,nslookup 203.0.113.10da la misma respuesta. Una respuesta vacía indica que falta el PTR, es decir, la causa n.º 1. - Comprueba el PTR IPv6 con
dig -x 2001:db8::25 +shortsi tu servidor puede emitir por ese protocolo. Es el punto que la mayoría de las checklists se saltan. Un servidor con conectividad IPv6 abre la conexión hacia Gmail en IPv6 por defecto, ya que los MX de Gmail publican registros AAAA. Las directrices oficiales de Google para remitentes son explícitas en este punto: un error de autorización IPv6 viene casi siempre de un PTR que solo existe en IPv4. Un PTR IPv4 impecable acompañado de un PTR IPv6 ausente hace que se rechacen esas conexiones, con un 550 5.7.25 o con el 550 5.7.1 reservado a los requisitos IPv6 según el caso. - Comprueba el forward match: el hostname devuelto por el PTR debe tener un registro A (o AAAA) que vuelva a apuntar a la misma IP de partida. Toma el hostname del paso anterior y ejecuta
dig A mail.tudominio.es +short, y luegodig AAAA mail.tudominio.es +shorten IPv6. La IP devuelta debe ser exactamente la de partida. Cualquier desajuste en este paso, por mínimo que sea, rompe el FCrDNS.
El detalle paso a paso de estas operaciones, comandos incluidos, se explica en nuestra guía sobre la búsqueda inversa de DNS.
Corregir según quién controla tu reverse DNS
Un PTR nunca se modifica desde tu panel de administración de dominio: pertenece al propietario del bloque de direcciones IP. El procedimiento cambia por completo según quién sea el dueño de esa zona reverse.
| Tipo de hosting | Quién controla el PTR | Procedimiento | Tiempo de propagación |
|---|---|---|---|
| VPS o servidor dedicado (OVH, Hetzner, DigitalOcean, AWS EC2) | El proveedor de hosting, mediante su panel de red o un ticket de soporte | Renombrar el droplet o la instancia con el hostname deseado (DigitalOcean), solicitar el PTR mediante los parámetros de IP elástica (AWS) o añadirlo en la sección de red del panel de cliente (Hetzner, OVH) | De unos minutos a unas horas |
| Hosting compartido | Solo el proveedor de hosting, normalmente sobre un pool de IP compartido | Abrir un ticket de soporte indicando la IP saliente exacta y el hostname esperado | Variable, a veces varios días según el proveedor |
| ESP o SaaS de emailing (Brevo, Mailgun, SendGrid, Google Workspace) | El proveedor de servicios, sobre sus propias IP | No tienes nada que hacer de tu parte con el PTR: comprueba más bien la alineación de SPF, DKIM y DMARC en el dominio de envío | No aplica, ya está gestionado |
En AWS, el PTR se solicita desde la consola de EC2 (sección de IP elástica) o mediante ticket si la IP no es elástica. En DigitalOcean, basta con renombrar el droplet con el FQDN deseado: el PTR se actualiza automáticamente. Después, comprueba con un envío de prueba que el bucle A/PTR está bien cerrado. El tiempo de propagación real suele situarse entre unos minutos y unas horas. Prevé una ventana de 2 a 4 horas antes de volver a comprobarlo si la primera verificación sigue fallando.
La trampa del PTR genérico que supera el control técnico
Hay un caso que se repite a menudo: el PTR existe e incluso resuelve correctamente en ambos sentidos. Aun así, el rechazo persiste. La causa más frecuente es un PTR genérico asignado automáticamente por el proveedor de hosting, del tipo 123-45-67-89.provider.com.
Técnicamente, este PTR supera el control FCrDNS: apunta a un hostname y ese hostname vuelve a apuntar a la misma IP. El problema está en otro sitio. Una IP que solo ha servido para hosting genérico, sin historial de envío dedicado ni hostname personalizado, encaja con el perfil de los servidores comprometidos que se usan para spam masivo. Gmail interpreta esta señal como débil, incluso cuando el bucle técnico está cerrado. La corrección consiste en solicitar un PTR personalizado que recoja el nombre de dominio o el subdominio realmente usado para el envío, por ejemplo mail.tudominio.es en lugar del hostname por defecto del servidor.
Otra objeción frecuente: «yo uso una plataforma de emailing, este problema no me afecta». Es verdad en cuanto al PTR en sí: los grandes ESP gestionan sus propias IP y su reverse DNS. Pero el mismo síntoma, un rechazo de Gmail cuando todo parece configurado, puede venir de un dominio de envío mal alineado en DKIM, un problema distinto del PTR. Comprobar cuál de los dos es la causa evita perder tiempo contactando con el interlocutor equivocado. Un informe DMARC agregado muestra qué fuente de envío falla en la alineación.
Una vez corregido el PTR, comprueba que el resto no lastra tu reputación de remitente
Corregir el PTR resuelve el rechazo SMTP inmediato. Eso no garantiza nada sobre lo que viene después. La reputación de remitente (sender reputation) en Gmail se construye sobre varias señales acumuladas: la tasa de hard bounce, la tasa de quejas (complaint rate) y el historial de envío de la IP. El cumplimiento DNS por sí solo no basta.
En una IP de pool compartido, esto se juega entre varios: si otro cliente del mismo pool genera una tasa de hard bounce elevada, tu propia deliverability sufre las consecuencias aunque tengas un PTR impecable. En una IP dedicada en fase de IP warm-up, cada envío a una dirección inválida o inactiva pesa más en la curva de confianza que Gmail construye, porque el volumen de referencia todavía es bajo.
«Verificar los emails antes de enviar sale caro, mejor filtrar después». El orden importa precisamente aquí: un hard bounce detectado por Gmail después del envío ya degrada la reputación de la IP en el momento en que ocurre. Una dirección inválida eliminada antes del envío no deja ningún rastro negativo. Pasar una muestra de tu próxima lista por una verificación antes de la campaña muestra de forma concreta la diferencia entre los 2 enfoques en la tasa real de hard bounce.
El postmaster de Gmail (Google Postmaster Tools) sigue siendo la fuente más fiable para seguir esta reputación a lo largo del tiempo, tanto a nivel de IP como de dominio. Nuestra guía sobre la reputación de una dirección IP detalla cómo leer estos datos y detectar un blacklisting incipiente.
Preguntas frecuentes sobre el error 550 5.7.25
¿El código 550 5.7.25 bloquea todos mis emails o solo algunos?
El rechazo se aplica por IP. Incluso puede limitarse a un solo protocolo si el PTR IPv4 es correcto pero falta el PTR IPv6. Si tu infraestructura envía desde varias IP, solo se rechazan los flujos que pasan por la IP con el problema, y el resto sigue llegando con normalidad.
Mis emails reenviados a una dirección de Gmail rebotan con el 550 5.7.25, ¿por qué?
Gmail comprueba el PTR de la máquina que abre la conexión, no el del remitente original. En un reenvío automático, por ejemplo un buzón profesional que redirige a una Gmail personal, es el servidor que hace de relay el que debe tener un PTR válido, incluso cuando el remitente inicial está perfectamente configurado por su parte. El mismo mecanismo se aplica a un relay SMTP secundario o a una pasarela antispam colocada delante de tu servidor. Lee la IP entre corchetes en el rebote: es esa a la que hay que corregir el reverse. A menudo pertenece a una máquina en la que habrías pensado en último lugar.
¿Cuánto tiempo tarda en hacerse efectiva la corrección del PTR?
La propagación suele darse entre unos minutos y unas horas. Espera una ventana de 2 a 4 horas antes de volver a comprobarlo, el tiempo que tardan los resolvers DNS en actualizar su caché.
¿Usar un ESP me protege automáticamente de este error?
Sí, en cuanto al PTR en sí: las grandes plataformas gestionan su propio reverse DNS en sus IP. Un rechazo de Gmail que persiste a pesar de usar un ESP suele venir de un problema de alineación DKIM o de un dominio de envío mal configurado, raramente del PTR en sí.
¿Basta con un PTR IPv4 si mi servidor también envía por IPv6?
No, consulta la verificación n.º 2 más arriba para diagnosticar este caso concreto. Si tu proveedor de hosting no ofrece PTR IPv6, desactivar el envío saliente por IPv6 en el servidor sigue siendo una solución provisional más rápida que esperar la respuesta de un ticket de soporte.
