Imagina una correduría de seguros de nueve personas que pasa sus buzones a Google Workspace un viernes. Para el lunes el correo funciona casi todo. El equipo envía y recibe sin problema. Pero el formulario de cotizaciones del sitio dejó de llegar y, cuando la administradora le escribe a info@ desde su propia cuenta del mismo dominio, el rebote regresa en segundos:
550 5.4.6 mail for example.com loops back to myselfEsa línea no menciona DNS, ni SPF, ni Google, así que la reacción habitual es abrir el editor de DNS y empezar a cambiar registros. Nos han llamado después de tres días de eso. Los registros casi siempre están bien. El problema es una sola opción en el hosting antiguo, que todavía cree que el correo del dominio es suyo.
Qué te está diciendo realmente el rebote
Un rebote por bucle es un callejón sin salida de enrutamiento, no un problema de reputación, ni un filtro de spam, ni una falla de autenticación. Algún servidor aceptó tu mensaje, buscó a dónde debe ir el correo del dominio del destinatario y la respuesta fue él mismo. Luego revisó su propia lista de dominios que entrega localmente, no encontró el dominio o no encontró un buzón para esa dirección, y se quedó sin a dónde pasar el mensaje. El código de estado que lo acompaña, 5.4.6, es el código registrado para bucle de enrutamiento en el RFC 3463.
Dos datos del rebote definen todo lo que sigue. El primero es qué servidor lo generó. El servidor que reporta es el que tiene la idea equivocada y, en una empresa pequeña, casi siempre es el hosting del sitio web y no Google. El segundo es el dominio que aparece en la parte "mail for". Si es tu dominio principal, estás viendo enrutamiento de correo. Si es un nombre como mail.example.com o el nombre completo del servidor, estás viendo correo que el servidor se manda a sí mismo, desde cron o desde un script de monitoreo, y el arreglo va en la configuración de esa máquina, no en el correo de la empresa.
Las tres configuraciones que lo provocan
En la práctica la causa es una de tres, y se distinguen fácil cuando sabes que son problemas distintos.
- El panel de hosting sigue entregando el dominio localmente. Cambiaste los registros MX, pero al servidor que aloja el sitio nadie se lo dijo. Sigue aceptando el correo del dominio, busca un buzón local y no lo encuentra porque los buzones ahora viven en tu proveedor. Es la causa más común y la que rompe los formularios y el correo entre cuentas del mismo dominio mientras todo lo demás se ve sano.
- El DNS todavía apunta a tu propio servidor. Sobrevivió un registro MX antiguo, o un MX con prioridad más baja apunta a la IP del hosting, así que a algunos remitentes se les indica entregar en una máquina que no tiene buzones.
- El servidor de correo tiene el dominio en su lista de destinos propios. En un VPS que administras tú, el dominio quedó en la lista de destinos locales cuando debería relevarse o ignorarse por completo.
Esto se diagnostica mal tan seguido porque el correo externo sigue llegando. Gmail, Outlook y todos los demás leen el DNS público, ven a tu proveedor y entregan ahí. Solo la máquina con la ruta local vieja se equivoca, y el tráfico que pasa por esa máquina es justo el que una empresa nota al final: formularios del sitio, scripts de facturación y correo entre dos direcciones del mismo dominio.
Qué revisamos primero, en orden
Este es el orden con el que trabajamos en el dominio de un cliente, porque cada paso descarta toda una familia de causas.
Primero, lee el DNS público y no la copia que tiene el panel. La ayuda de administración de Google indica un solo registro MX para Workspace: host @ o vacío, prioridad 1, valor smtp.google.com, y algunos registradores piden el punto final o la prioridad y el valor en la misma línea.
dig +short MX example.com
1 smtp.google.com.Lo importante no es cuál juego de registros de Google tienes. Los dominios más antiguos cargan una lista más larga y siguen recibiendo correo. Lo importante es que nada en la respuesta resuelva a tu propio servidor web. Si algo lo hace, arregla el DNS primero y detente ahí, porque ninguna configuración de servidor le gana a un registro MX equivocado. Nuestra guía para cambiar los registros MX a Google Workspace sin perder correo cubre ese corte con calma.
Segundo, identifica el servidor que reporta el rebote y confirma que es el hosting. Tercero, abre el enrutamiento de correo de ese servidor para el dominio. Cuarto, busca restos en la cuenta antigua: un buzón local, un reenvío o un catch-all para la misma dirección mantienen al servidor convencido de que debe entregar localmente. Quinto, manda una prueba desde el formulario del sitio y otra desde una cuenta del dominio hacia otra cuenta del mismo dominio, porque esas dos rutas fallan por razones distintas y una sola prueba te puede engañar.
El arreglo en hosting con cPanel
cPanel tiene una sola opción para esto, en Correo y luego Enrutamiento de correo. Eliges el dominio y le dices al servidor qué es. Las cuatro opciones se comportan distinto, y solo una es correcta cuando los buzones ya se movieron.
| Opción | Qué hace el servidor con el correo del dominio | Cuándo es la correcta |
|---|---|---|
| Remote Mail Exchanger | Deja de aceptar el correo del dominio y lo entrega al MX de prioridad más baja que diga el DNS | Los buzones viven en Google Workspace, Microsoft 365 o cualquier otro proveedor |
| Local Mail Exchanger | Siempre acepta el correo y lo entrega a un buzón de este servidor | Los buzones de verdad viven en esta cuenta de hosting |
| Backup Mail Exchanger | Retiene el correo hasta que un intercambiador con prioridad más baja esté disponible | Un MX de respaldo intencional, que una empresa pequeña casi nunca necesita |
| Automatically Detect Configuration | Lee el archivo de zona local para adivinar entre local y remoto, sin consulta DNS real, y después no vuelve a revisar su conjetura | Casi nunca, y nunca cuando el DNS está alojado fuera de este servidor |
Esa última fila es la trampa. La propia documentación de cPanel es clara en que la detección automática lee las entradas de la zona local en lugar de hacer una consulta DNS real, y que la opción no se actualiza sola después de quedar configurada. Así, un dominio cuyo DNS vive en Cloudflare o en el registrador puede apuntar a Google en el DNS público mientras la zona local del servidor todavía muestra el registro viejo, y el servidor sigue entregando localmente sin inmutarse. Pon la opción explícita en Remote Mail Exchanger y la conjetura deja de importar.
Dos pendientes en la misma cuenta. Borra o renombra cualquier buzón local y cualquier reenvío de direcciones que ahora viven en tu proveedor, porque dejarlos ahí significa dos versiones de la verdad. Y si el panel generó su propio registro DKIM para el dominio, ese registro firma solo el correo que manda el panel, así que no debería ser el registro del que dependa la autenticación de tu proveedor.
Otros paneles tienen el mismo interruptor con otro nombre. El principio no cambia: un servidor que ya no tiene los buzones no debe estar configurado para entregar localmente el correo del dominio.
El arreglo en un servidor que administras tú
En un Postfix normal, el equivalente está en los parámetros de configuración que definen cuáles dominios considera propios la máquina. mydestination es la lista de dominios para los que la máquina es el destino final. Lee los valores actuales antes de cambiar nada:
postconf mydestination relay_domains virtual_mailbox_domains virtual_alias_domainsSi el dominio de la empresa aparece en alguno de ellos mientras los buzones viven en otro lado, ahí está el bucle. Quítalo, recarga, y la máquina resolverá el registro MX y entregará hacia afuera como cualquier otro remitente. Un dominio para el que aceptas correo a propósito en nombre de otro servidor va en relay_domains, no en mydestination. La página de manual postconf(5) es la referencia para el significado exacto de cada parámetro, y vale la pena leerla en vez de adivinar, porque esas listas se traslapan y un dominio puesto en la equivocada produce el mismo bucle.
La parte que todos olvidan: el correo del propio sitio web
Arreglar la ruta hace que el rebote pare. No hace confiable el correo del sitio. Un formulario de contacto que entrega el mensaje al servidor de correo local ahora está mandando correo sin autenticar, desde una IP de hosting compartido que no está en ningún lugar de tu SPF, hacia un buzón en Google. En el mejor caso cae en spam. En el caso común desaparece sin ruido.
El arreglo que dura es que el sitio se autentique y envíe a través de tu proveedor en lugar del servidor web. Google documenta dos rutas para el correo de una aplicación o un dispositivo. El servicio de retransmisión SMTP recibe correo en smtp-relay.gmail.com en los puertos 25, 465 o 587, con TLS, y autentica con credenciales SMTP o por dirección IP, y la autenticación por IP es la única opción cuando no hay TLS. Se configura en la consola de administración en Apps, Google Workspace, Gmail, Enrutamiento y luego Servicio de retransmisión SMTP, y solo la organización de nivel superior puede cambiarlo. La alternativa, smtp.gmail.com, inicia sesión como una sola cuenta y tiene un límite diario más bajo, que suele alcanzar para un formulario de contacto y no para un sistema de facturación. Esos datos salen de las páginas de ayuda de Google, consultadas el 30 de octubre de 2026. Nuestra guía de retransmisión SMTP y Enviar correo como en Google Workspace recorre las dos.
Qué vigilar las próximas dos semanas
Cuando la ruta cambia, el correo que se estaba quedando local empieza a llegar, y eso puede parecer un problema nuevo. Espera una ráfaga corta de envíos de formulario y avisos de scripts que estaban en cola o desaparecidos. Revisa los registros de entrada de tu proveedor para el dominio y confirma que los mensajes ahora entran desde afuera, manda una prueba desde cada remitente automático que tenga la empresa y vigila cualquier cosa que siga usando los nombres de buzón viejos que borraste. Si el sitio ya envía por SMTP autenticado, confirma que la dirección remitente sea una que tu DNS autorice y no una dirección inventada del dominio, o habrás cambiado un rebote por bucle por una falla de autenticación.
Cómo ayuda Guanacos Tech
Casi todo el trabajo aquí es diagnóstico. El cambio en sí es una opción, pero elegir la correcta implica leer el rebote, leer el DNS público y saber cuál de tres máquinas te está mintiendo. Lo hacemos como parte de la consultoría de entregabilidad de correo, normalmente junto a una migración a Workspace o justo después de una que dejó cabos sueltos. Agenda una llamada de 30 minutos y trae un mensaje de rebote con las cabeceras completas; con eso suele bastarnos para decirte cuál servidor hay que cambiar y qué más dejó pendiente la migración.
Fuentes
- Enrutamiento de correo (documentación de cPanel)
- Configuración del enrutamiento de correo (documentación de WHM)
- Configurar registros MX para Google Workspace (Ayuda de administración de Google Workspace)
- Enviar correo desde una app, un dispositivo o una impresora, incluido el servicio de retransmisión SMTP (Ayuda de Google Workspace)
- Parámetros de configuración postconf(5) (documentación de Postfix)
- RFC 3463: Enhanced Mail System Status Codes