Un mismo número, tres problemas distintos
Imagina un estudio de diseño de nueve personas que envía propuestas desde su propio dominio. Un lunes por la mañana nada llega a los clientes que usan Gmail, y la persona de administración te reenvía un mensaje devuelto con un 550 adentro. Ese número solo no dice casi nada: significa que Gmail rechazó el mensaje de forma definitiva y no lo va a reintentar. Lo útil es el código de estado que viene después, y la frase que Gmail le pegó a ese código.
Tres códigos explican casi todos los rechazos de Gmail que nos tocan. 5.7.1 es un veredicto de reputación. 5.7.26 es un veredicto de autenticación. 5.7.25 habla de la máquina que abrió la conexión, no de tu dominio. En el cliente de correo se ven igual, y detrás hay trabajos completamente distintos. Por eso lo primero que hacemos en estos casos es leer el rebote con calma, antes de que alguien abra el panel de DNS.
Lee el rebote: las tres líneas que importan
Pide el mensaje devuelto completo, no una captura de la primera línea. En Gmail el texto completo está detrás del enlace de detalles del error, o en Mostrar original. En Outlook está en el informe de entrega. Tres cosas definen todo lo que sigue.
- El código de estado. Los dígitos justo después del
550:5.7.1,5.7.26o5.7.25. Gmail corta las explicaciones largas, así que verás el código repetido al inicio de cada línea como550-5.7.26. Ese guion indica que la línea continúa, no que sea otro código. - La frase que Gmail le puso. Dos rechazos pueden compartir código y necesitar arreglos distintos. Es justo lo que pasa con 5.7.26. Copia la frase textual antes de que alguien la resuma.
- Qué nombra esa frase. Un dominio, una dirección IP, o las dos. "The sending domain" y "the sending IP address" apuntan a responsables distintos, y muchas veces a empresas distintas.
Un rebote 5.7.26 del primer tipo se ve parecido a esto:
550-5.7.26 This mail is unauthenticated, which poses a security risk to
550-5.7.26 the sender and Gmail users, and has been blocked. The sender
550-5.7.26 must authenticate with at least one of SPF or DKIM.Y un 5.7.1 se ve más bien así:
550-5.7.1 Gmail has detected that this message is likely suspicious
550-5.7.1 due to the very low reputation of the sending domain.Los mismos tres dígitos adelante, dos proyectos sin relación atrás.
5.7.1 es reputación, 5.7.26 es autenticación, 5.7.25 es el servidor que envía
5.7.26, autenticación. Gmail no pudo ligar el mensaje con el dominio que aparece en el De. O no pasó nada, o lo que pasó corresponde a otro dominio distinto al que ve quien recibe. Es un problema de configuración y DNS, y es el más rápido de cerrar de los tres.5.7.1, reputación. Gmail sí evaluó el mensaje y el historial del remitente no le gustó. Lee bien la frase: "very low reputation of the sending domain" habla de tu dominio; "very low reputation of the sending IP address" habla de la máquina o del grupo de IPs por donde sales, que en hosting barato compartes con desconocidos. Ninguno de los dos se arregla editando un registro.5.7.25, el DNS del servidor que envía. La IP pública que se conectó no tiene DNS inverso utilizable. Las guías para remitentes de Google piden que la IP de envío tenga un registro PTR que resuelva a un nombre de host, y que ese nombre tenga un registro A o AAAA que resuelva de regreso a la misma IP. Solo quien es dueño de la IP puede publicarlo, y casi nunca eres tú.
Vale la pena separar desde ya las dos frases que comparten el código 5.7.26, porque te mandan a lugares distintos. La citada arriba, "must authenticate with at least one of SPF or DKIM", significa que no pasó nada. La otra, "Unauthenticated email from ejemplo.com is not accepted due to domain's DMARC policy", significa que tu propia política publicada le dijo a Gmail que rechazara el mensaje, porque lo que sí autenticó no estaba alineado con el dominio del De. La segunda versión aparece sobre todo en empresas que pasaron a p=reject antes de terminar el inventario de sistemas que envían con su dominio.
Si el tuyo es 5.7.26: primero autenticar, luego alinear
Hazlo en este orden. Cada paso se puede comprobar, y eso importa cuando hay tres personas adivinando al mismo tiempo.
- Identifica qué sistema envió el mensaje. No "nuestro correo". El servidor de correo, el CRM, el sistema de facturación, el formulario del sitio, el escáner del pasillo. Cada uno autentica por su cuenta, y el que falló suele ser el que nadie recuerda haber activado.
- Revisa con qué identidad tiene permiso de enviar. Si sale por tu proveedor de correo con un buzón real y su contraseña, normalmente ya está cubierto. Si se conecta a Gmail desde sus propios servidores, necesita un include de SPF que los nombre o su propia llave DKIM publicada en tu dominio.
- Busca alineación, no solo un pase. Para mensajes que van directo a cuentas personales de Gmail, Google pide que el dominio organizacional del encabezado De coincida con el dominio de SPF o con el de DKIM. Con uno de los dos basta. Un proveedor que firma con su propio dominio y pasa SPF en su propia ruta de retorno igual puede producir un 5.7.26 en tu De, y su soporte te dirá que la autenticación está bien, porque desde donde ellos miran lo está.
- Envía un mensaje real y lee los encabezados. Una herramienta de consulta te dice qué dice tu registro hoy. Los encabezados de un mensaje que Gmail aceptó te dicen qué hizo Gmail con él. Esa es la comprobación que cierra el caso.
El recorrido completo, con la variante de la política DMARC, está en nuestra guía de 5.7.26. Una advertencia antes de agregar un include: el RFC 7208 limita SPF a diez consultas DNS, y un proveedor más puede empujar un registro largo a PermError, que tumba la autenticación de todos los mensajes a la vez. Cuenta primero las consultas.
Si el tuyo es 5.7.1: reputación, y ningún registro lo resuelve
Este es el lento. Hay gente que pierde semanas tratándolo como problema de DNS, publicando un registro nuevo cada día y viendo que nada cambia. La reputación es un promedio de cómo reacciona la gente a tu correo, así que se mueve al ritmo de Gmail.
- Define si es el dominio o la IP. El rebote lo dice. Si nombra la IP y sales por hosting compartido, estás cargando el comportamiento de otros, y el arreglo real es dejar de enviar por ahí.
- Verifica el dominio en Postmaster Tools y léelo. Los paneles muestran reputación de dominio y de IP junto con tasas de autenticación y de errores de entrega para el dominio que verificaste. Es la única vista de lo que piensa Gmail que no es adivinanza. Nuestra guía de configuración explica para qué sirve cada panel.
- Deja la autenticación impecable de todos modos. En un dominio que todavía falla SPF o DKIM la recuperación ni siquiera empieza. Autenticar es el piso, no el arreglo.
- Corta lo que lo causó. Un salto de volumen, una lista comprada, un formulario sin confirmación, un buzón comprometido enviando de madrugada. Google pide mantener la tasa de spam reportada en Postmaster Tools por debajo de 0.1 por ciento y nunca llegar a 0.30 por ciento, guía que revisamos el 23 de septiembre de 2026. Las quejas a ese nivel no se promedian rápido.
- Después reconstruye despacio. Volúmenes chicos hacia gente que responde, sostenidos durante semanas. No hay botón, y quien te ofrezca uno te está vendiendo algo.
La guía de 5.7.1 tiene el orden que seguimos en un caso de reputación en curso, incluido qué hacer cuando la IP no es tuya.
Si el tuyo es 5.7.25: el arreglo es de alguien más
El DNS inverso lo publica quien es dueño de la IP, así que el panel del registrador es el lugar equivocado. Si envías por Google Workspace, Microsoft 365 o una plataforma de correo normal, sus direcciones ya tienen PTR, y un 5.7.25 suele significar que hay algo más retransmitiendo: un servidor viejo de la oficina, un VPS con el formulario de contacto del sitio, un equipo con una configuración SMTP de otra década. Busca la IP en el rebote, averigua quién la opera y pídele un PTR que resuelva a un nombre de host cuyo registro A o AAAA apunte de regreso a la misma dirección. En un VPS eso es un ticket de soporte. En una máquina debajo de un escritorio suele ser razón suficiente para dejar de enviar directo y retransmitir por el proveedor de correo.
Qué hacer mientras el cambio se propaga
Las horas siguientes al cambio son donde se arruina el buen trabajo.
- No sueltes la cola atorada de golpe. Unos cientos de reintentos contra un proveedor que te acaba de rechazar se leen exactamente como se ven.
- Espera a que pase el TTL del registro antes de probar. Si el TTL era de cuatro horas, la respuesta que obtienes en cinco minutos es la vieja.
- Prueba con un solo mensaje a una dirección de Gmail tuya y lee sus encabezados. Que llegue a tu bandeja no alcanza como prueba.
- Llama a quien está esperando algo urgente. Una llamada corta gana contra una propuesta detenida en una cola.
- No registres un dominio nuevo para escapar del problema. Un dominio recién creado no tiene reputación, uno parecido al tuyo genera más sospecha, y los dos dejan el original roto.
Cómo ayuda Guanacos Tech
Casi todos estos casos llegan con una sola frase: nuestro correo está rebotando. Una hora después suelen ser tres cosas distintas, y una de ellas venía fallando en silencio desde hace meses. Leemos el rebote, listamos cada sistema que envía con el dominio, arreglamos la autenticación remitente por remitente, comprobamos con mensajes reales y no con herramientas de consulta, y nos quedamos con los reportes DMARC el tiempo suficiente para saber que aguantó. Si ya tienes un rebote en la mano, nuestra consultoría de entregabilidad de correo empieza ahí. Lleva el mensaje devuelto a una llamada de 30 minutos y sales sabiendo cuál de los tres problemas tienes y qué va a costar cerrarlo.