El reenvío de correo no funciona: diagnóstico en 6 pasos

El reenvío de correo no funciona. Faltan mensajes, el remitente no ve un aviso de error y la regla parece correcta en los paneles que has revisado. Sin un error visible, necesitas seguir el recorrido del mensaje y reunir evidencias.

Un reenvío de correo que no funciona puede deberse a la regla, la dirección, una política o la autenticación SPF, DKIM y DMARC. El receptor ve la IP del servidor que reenvía y puede no estar autorizada por el dominio original. Eso puede provocar rechazo, clasificación como spam o pérdida sin aviso visible, según el flujo. No todo mensaje reenviado es indistinguible de una suplantación ni desaparece necesariamente.

Revisa esta lista antes de cambiar DNS. La guía completa de configuración y reparación de reenvíos explica los problemas de SPF y cómo intervienen SRS y ARC. Aquí encontrarás una secuencia de diagnóstico para un fallo que está ocurriendo ahora.

Por qué puede fallar el reenvío sin un error visible

El resultado depende de dónde y cuándo se rechace el mensaje. Un rechazo SMTP puede generar un aviso; si el servidor ya lo aceptó, puede existir una notificación posterior, cuarentena o descarte según la política. El aviso puede dirigirse al remitente de sobre, que no siempre es el remitente visible. Consulta registros y colas: la ausencia de un aviso no demuestra por sí sola un fallo DMARC.

Las cabeceras y los registros ayudan cuando no hay un error visible. La regla puede estar activa aunque el destino filtre el mensaje o el servidor lo tenga pendiente. Estas seis comprobaciones siguen un orden práctico de revisión. Comprobar primero spam evita dedicar, por ejemplo, 45 minutos a DNS que no causaba el problema.

Diagnóstico en 60 segundos: identifica el síntoma

Dedica 60 segundos, como pauta orientativa, a clasificar el fallo antes de modificar la configuración. El síntoma orienta, pero no confirma por sí solo la causa. Estos cuatro patrones permiten elegir la primera comprobación.

Lista de comprobación del reenvío de correo

Empieza por el paso 1 y el paso 2: spam y avisos de no entrega aportan pistas sin modificar DNS. Evita invertir, por ejemplo, 45 minutos en cambios sin evidencias y detente cuando identifiques la causa.

Paso 1: revisa la carpeta de spam del destino

Comprobación inicial  |  Síntoma: no hay correo ni aviso

Si no aparece un aviso, el mensaje podría estar en spam, pero también en cola o cuarentena. Al reenviar de client@gmail.com a you@outlook.com, el receptor puede ver la IP del reenviador donde esperaba una autorizada por SPF del remitente original. Puede fallar SPF; una firma DKIM válida y alineada que se conserve aún puede permitir pasar DMARC. La clasificación depende de las comprobaciones y de la política del receptor.

Acción: entra en el buzón final y revisa spam y correo no deseado.

Corrección: marca como “No es correo no deseado” si el mensaje es legítimo. En el servidor, Sender Rewriting Scheme (SRS) puede reescribir el remitente de sobre para evaluar SPF sobre el reenviador. Eso no garantiza alineación con el From original ni evita todos los futuros filtros. Sin SRS también puede pasar DMARC mediante DKIM alineado.

Paso 2: lee el aviso de no entrega y su código NDR

Comprobación del error  |  Síntoma: aviso de “No se pudo entregar”

Cuando hay un aviso, el código SMTP y su texto acotan la investigación. Lee también el servidor que lo emitió y la dirección afectada. No deduzcas una causa única a partir del asunto o de un código sin contexto.

Paso 3: comprueba la alineación DMARC

Comprobación de autenticación para Gmail, Yahoo y Outlook  |  Síntoma: ausencia o rechazo

DMARC es una causa posible, no una explicación universal. Si el remitente publica p=reject, no implica que el reenvío falle el 100% de las veces sin SRS o ARC: DKIM puede seguir siendo válido y alineado. DMARC pasa si SPF o DKIM valida y su dominio se alinea con el From visible. El receptor aplica su política; SRS no alinea automáticamente el sobre reescrito con el From original.

Consulta la política DMARC del dominio del remitente en un terminal:

dig _dmarc.originalsender.com TXT +short

Encontrar p=reject no demuestra que se haya rechazado ese mensaje. Revisa resultados reales: SPF puede fallar por la IP del reenviador y DKIM puede conservarse o romperse si cambia contenido firmado. La alineación compara los dominios autenticados con el From, no el remitente de sobre con la firma DKIM.

Corrección: evalúa un reenviador de servidor con SRS y soporte ARC cuando proceda. ARC permite validar una cadena de resultados anteriores; el receptor decide si confía en ella y cómo la usa, sin garantía de pasar DMARC o entregar. Los filtros de Gmail, las reglas de Outlook y los redireccionamientos de cPanel tienen implementaciones distintas; cPanel puede reenviar en el servidor. Comprueba capacidades reales en vez de clasificarlos todos como reglas del cliente.

Paso 4: revisa el reenvío saliente de Microsoft 365

Revisión de políticas para Office 365  |  Síntoma: NDR 550 5.7.520

El reenvío de Microsoft 365 puede estar bloqueado deliberadamente por una política contra la salida no autorizada de datos. Una regla del usuario no supera las restricciones de la organización. Antes de habilitar nada, confirma destinatario, necesidad y aprobación. La siguiente ruta es orientativa y puede cambiar; evita modificar el valor predeterminado para todo el tenant.

1. Accede con autorización a Microsoft 365 Defender
2. Busca Correo electrónico y colaboración → Directivas y reglas → Directivas de amenazas → Antispam
3. Revisa la directiva antispam de salida y su ámbito; usa una excepción específica autorizada en lugar de ampliar Default indiscriminadamente
4. Comprueba Editar configuración de protección
5. Solo dentro del ámbito aprobado, evalúa Reglas de reenvío automático y el valor Activado: el reenvío está habilitado

Una opción deshabilitada puede deberse a permisos o a una política organizativa. Pide la intervención del administrador autorizado; no intentes eludirla con una regla personal. Comprueba después el efecto y conserva la aprobación.

Paso 5: busca bucles de rutas

Comprobación de rutas  |  Síntoma: error 5.4.14 o copias múltiples

Un bucle puede aparecer cuando A reenvía a B y B devuelve a A. El mensaje puede circular hasta que un límite de saltos u otro control lo detenga. Revisa, por ejemplo, un catch-all del dominio A dirigido a B y una regla de B que devuelva algunas direcciones a A.

Busca estas cabeceras en mensajes retrasados o duplicados:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To repetida con la misma dirección

La guía de rutas catch-all de dominio ayuda a diseñar rutas sin ciclos. Un destino final claro facilita la revisión; usar otro alias o reenviador no crea necesariamente un bucle, pero exige comprobar toda la cadena y sus límites.

Paso 6: verifica el destino en Gmail

Comprobación de activación  |  Síntoma: existe la regla, pero no se activa

En Gmail personal, la activación puede estar pendiente de verificar la dirección de destino. Comprueba el estado de la confirmación y que el reenvío esté seleccionado en los ajustes. No basta con que la dirección aparezca guardada.

Acción: busca en el buzón de destino la confirmación de “Gmail Team”, también en spam. Verifica que sea una solicitud legítima y autorizada antes de abrir el enlace. Si falta o ha caducado, revisa Configuración de Gmail → Reenvío y correo POP/IMAP y repite la verificación según el flujo actual.

Leer cabeceras para diagnosticar el reenvío

Un mensaje que llega a spam sí ha llegado al buzón; puede deberse a autenticación, reputación, contenido u otras señales. Authentication-Results aporta resultados de comprobaciones, no la explicación de todo fallo. Interprétalo junto con el servidor que lo añadió y los registros; una cabecera aportada por un origen no fiable no constituye prueba.

Cómo consultar cabeceras, según la versión del cliente:

• Gmail: abre el mensaje → menú de tres puntos → “Mostrar original”
• Outlook: Archivo → Propiedades → Encabezados de Internet en versiones compatibles

Ejemplo ilustrativo de resultados con SRS y ARC. No es una plantilla canónica de cabecera ni una prueba de entrega garantizada; revisa autenticación y alineación reales:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

El prefijo SRS0= de Return-Path indica una forma habitual de reescritura, pero su ausencia no prueba que todos los reenvíos fallen. Comprueba el sobre y la implementación real. Las reglas aplicables a Gmail, Yahoo y Outlook varían; las exigencias de Google para remitentes masivos de 2024 no representan todos los dominios empresariales ni todos los receptores.

Cuando un fallo de reenvío afecta al negocio

Un correo de cliente, contrato o petición de soporte que no llega puede retrasar una relación comercial. A veces el problema solo se descubre cuando alguien pregunta por la falta de respuesta. Los avisos, registros y pruebas ayudan a detectar estos vacíos.

El diagnóstico manual sirve para investigar, pero varios dominios necesitan seguimiento continuo. Un cambio de política o de autenticación puede modificar el resultado. Google Postmaster Tools muestra datos agregados de reputación, spam y otros indicadores para tráfico elegible hacia Gmail personal, sujetos a volumen y retrasos. Un fallo de autenticación no equivale automáticamente a una queja ni afecta necesariamente a todo el correo enviado.

Reduce los fallos recurrentes

Si el reenvío falla repetidamente, evalúa la infraestructura, la conservación de DKIM y el soporte SRS y ARC, además de las reglas. Un diseño adecuado reduce trabajo repetido, pero sigue necesitando supervisión y revisión de políticas.

Gestión dispersa: revisar reglas de Gmail o cPanel, investigar SPF por dominio y solicitar cambios autorizados en M365 cuando cambian los requisitos.

Modelo de TrekMail: definir rutas en el panel y comprobar el tratamiento SRS y ARC del servidor según las funciones disponibles. La entrega sigue dependiendo del receptor y de la configuración.

TrekMail describe reenvío a nivel de Postfix, con reescritura SRS y sellado ARC antes del siguiente envío. Confirma su funcionamiento actual y si las modificaciones conservan las firmas DKIM originales. ARC registra resultados anteriores; no conserva por sí solo una firma válida tras cambiar contenido firmado ni garantiza que Gmail, Outlook o Yahoo acepten el mensaje.

Para una agencia con decenas de dominios, centralizar puede simplificar la gestión. En lugar de entrar, por ejemplo, en 30 paneles, configura y verifica las rutas de cada dominio con los permisos adecuados. La guía de gestión del correo de clientes explica cómo revisar cadenas multidominio sin ciclos A→B→A como los del paso 5.

La descripción histórica sitúa el reenvío con ARC y SRS en Pro por $10/mes (100 dominios, 50GB) y Agency por $23.25/mes (1,000+ dominios), con prueba de 14 días. Verifica funciones, cuotas, alcance de la prueba y requisitos de tarjeta antes de contratar: compara los planes en trekmail.net/pricing.

Reduce las incidencias repetidas con configuración verificada y seguimiento. Consulta el tratamiento de SRS y ARC de TrekMail y comprueba sus funciones actuales.