Rebote "554 5.4.6 Hop count exceeded - possible mail loop": cómo solucionarlo

Qué significa

Cada vez que un email pasa por un servidor, ese servidor añade una línea Received a las cabeceras. Eso es un "salto" (hop). Si un mensaje acumula demasiados saltos, los servidores suponen que está dando vueltas en círculo (un bucle de correo) y lo detienen con un rebote. Suele tener este aspecto:

554 5.4.6 Hop count exceeded - possible mail loop

Microsoft 365 usa 554 5.4.14 Hop count exceeded - possible mail loop, a veces seguido de ATTR1 o ATTR34. Según Microsoft, 5.4.14 viene de Exchange Online y 5.4.6 suele venir de un servidor Exchange local. Postfix también usa el estado 5.4.6, por ejemplo con el texto mail for yourdomain.com loops back to myself o mail forwarding loop for user@yourdomain.com.

Por qué ocurre

• Reenvíos en círculo. La dirección A reenvía a B, y B reenvía de vuelta a A (o pasando por C). Es frecuente después de configurar reenvíos tanto en un buzón antiguo como en uno nuevo.
• El MX apunta a un servidor que no conoce el dominio. El servidor recibe el correo, no se considera el destino final, consulta el MX y se lo envía… a sí mismo. En Postfix, ocurre cuando el dominio falta en mydestination o en la configuración de dominios virtuales.
• Dos sistemas creen que el otro tiene el buzón. Típico en Exchange híbrido o durante una migración: el servidor local envía a la nube y la nube lo devuelve al servidor local.
• Conectores o pasarelas mal configurados. Una pasarela de filtrado envía el correo a Microsoft 365, y un conector o una regla lo devuelve a la pasarela.
• Dominio aceptado configurado como relay. En Exchange Online, un dominio configurado como "internal relay" reenvía los destinatarios desconocidos a otro servidor, que los devuelve.
• Respuestas automáticas y reglas de reenvío que se responden entre sí.

Cómo comprobarlo

1. Abre el rebote y lee las cabeceras del mensaje devuelto. Lee las líneas Received de abajo arriba. Verás los mismos dos o tres nombres de servidor repitiéndose: forman el bucle. Nuestra guía para leer las cabeceras de un email explica cada línea.
2. Comprueba los registros MX del dominio del destinatario en el escáner de dominios, o con dig MX yourdomain.com +short. Deben apuntar al servidor o servicio que aloja realmente los buzones. Consulta también registro MX que apunta a un CNAME o a una IP.
3. En Postfix, comprueba que el dominio está declarado como local o virtual:

   postconf mydestination virtual_mailbox_domains relay_domains
   postconf -n | grep -i transport

4. En Microsoft 365, en Exchange Online PowerShell:

   Get-AcceptedDomain | Format-Table Name,DomainType
   Get-Mailbox user@yourdomain.com | Format-List ForwardingAddress,ForwardingSmtpAddress
   Get-InboxRule -Mailbox user@yourdomain.com
   Get-InboundConnector; Get-OutboundConnector

   El seguimiento de mensajes (message trace) del centro de administración de Exchange también muestra el camino que siguió un mensaje.

Cómo solucionarlo

1. Rompe los círculos de reenvío. Mantén el reenvío en un solo sentido y quítalo del buzón antiguo cuando termine la migración.
2. Haz que un único servidor sea el responsable. En Postfix, añade el dominio a mydestination (usuarios locales) o a virtual_mailbox_domains (usuarios virtuales), nunca a los dos, y luego systemctl reload postfix. En Exchange Online, configura el dominio como Authoritative salvo que algunos buzones estén realmente en otro sitio.
3. Corrige el MX para que apunte al sistema que aloja los buzones. Tras un cambio de proveedor, actualízalo en tu proveedor DNS y elimina las entradas antiguas.
4. Corrige el enrutamiento híbrido. Asegúrate de que cada buzón existe en un solo sitio (un buzón en la nube debe ser un "remote mailbox" en local, no un segundo buzón) y de que los conectores solo envían al otro lado para los destinatarios que realmente están allí.
5. Revisa las pasarelas. Si hay un servicio de filtrado delante de tus buzones, el camino de entrada (pasarela → buzón) y el de salida (buzón → pasarela → internet) no deben devolver el mismo mensaje.
6. Acaba con las guerras de respuestas automáticas con reglas que no respondan a los mensajes automáticos.

Comprueba que está solucionado

Envía un mensaje nuevo a la dirección que entraba en bucle y comprueba que llega con solo unas pocas líneas Received. Si cambiaste el DNS, deja tiempo para la propagación. Después envía una prueba desde ese dominio a la dirección de la página de inicio de Delivmail para confirmar que el correo saliente y la autenticación también funcionan tras el cambio de enrutamiento.