Reenviar correo a otra dirección: autenticación y diagnóstico

Configuras una regla de reenvío. Envías una prueba. Funciona. Sigues con lo tuyo.

Después, un cliente dice que no recibió tu respuesta. No ves ningún rebote ni informe de no entrega. El mensaje parece haberse perdido entre servidores; los registros pueden aclarar qué ocurrió.

Esto puede ocurrir cuando reenvías correo a otra dirección: tu servidor abre una nueva conexión SMTP con el destino. Este comprueba SPF con tu IP, no la del remitente original. Si esa IP no está autorizada para el dominio del remitente del sobre, SPF puede fallar. Si tampoco queda una firma DKIM válida y alineada, DMARC falla. Con p=reject, el receptor puede rechazar el mensaje según su política; no implica siempre un descarte silencioso ni la ausencia de rebote.

No es necesariamente un error de configuración. Es una fricción entre el reenvío y la autenticación moderna. La guía completa de configuración y solución de problemas de reenvío aborda los escenarios de principio a fin. Este artículo se centra en la autenticación: los modos de fallo, los códigos de error y las medidas que ayudan a corregirlos.

Por qué puede fallar la autenticación al reenviar correo a otra dirección

Al reenviar correo, el MTA receptor comprueba SPF con la IP del servidor que reenvía, no la del remitente original. Cada mensaje tiene dos capas de identidad distintas, que el reenvío puede desalinear. SPF valida el sobre; DMARC exige que SPF o DKIM pasen y estén alineados con el dominio visible del remitente.

La cadena: el servidor A envía al servidor de reenvío B, que abre otra conexión TCP con el destino C. C ve la IP de B. SPF consulta el DNS del dominio del remitente del sobre: "¿Está autorizada esta IP para enviar por tu dominio?" Si el remitente original no autoriza B y se conserva ese sobre, SPF puede fallar. No es un resultado inevitable de todo reenvío.

DMARC solo necesita SPF o DKIM válidos y alineados. Una firma DKIM original que siga siendo válida y esté alineada puede hacer pasar DMARC. Los cambios en las partes firmadas pueden invalidarla, según las cabeceras firmadas y la canonicalización utilizada. Si no queda ningún mecanismo válido y alineado, DMARC falla; p=reject solicita el rechazo, sujeto a la política del receptor.

Tres modos de fallo que conviene prever

Al reenviar correo sin las medidas adecuadas en el servidor, puedes encontrar estos tres patrones. Los códigos de error son ejemplos: dependen del proveedor y no aparecen en todos los fallos. Identificar el patrón ayuda a orientar el diagnóstico.

1. Bloqueo de salida de Microsoft 365 (550 5.7.520)

Microsoft 365 puede bloquear el reenvío externo por considerarlo un riesgo de exfiltración de datos. Si una regla reenvía fuera del tenant y la política efectiva no lo permite, Exchange Online puede bloquearla antes de la salida.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Es un bloqueo de política, no un error de protocolo. Un administrador debe revisar el alcance autorizado:

1. Abre el portal Microsoft 365 Defender.
2. Ve a Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Edita la política de filtro de spam saliente aplicable a los usuarios o grupos autorizados.
4. Establece Automatic forwarding en On - Forwarding is enabled solo para ese alcance aprobado.

Habilitarlo globalmente aumenta la exposición si se compromete una cuenta. Limita la excepción a quienes la necesitan, aplica MFA y supervisa el volumen de correo saliente tras el cambio. Comprueba también otras restricciones de reenvío vigentes.

2. Fallo de los dos mecanismos de DMARC

Este fallo puede ser difícil de detectar desde el buzón. SPF puede fallar por el cambio de IP si se conserva el remitente original del sobre. DKIM todavía puede hacer pasar DMARC si conserva una firma válida y alineada. Una modificación relevante del cuerpo o de una cabecera firmada puede invalidarla; no todo cambio lo hace.

Modificaciones que pueden romper DKIM durante el tránsito:

• Un antivirus añade un pie: "Analizado por [Nombre del producto]"
• La pasarela de destino añade al asunto [EXT] o [EXTERNAL], si esa cabecera está firmada
• Se insertan avisos de "Remitente externo" en el cuerpo HTML
• Una lista de correo reescribe cabeceras firmadas o añade un pie para cancelar la suscripción

Si ni SPF ni DKIM aportan un resultado válido y alineado, DMARC (RFC 7489) falla. Con p=reject, el dominio solicita el rechazo, pero el receptor decide el tratamiento final. Puede haber rechazo SMTP, cuarentena u otra acción local; no se puede asumir un descarte sin rebote. Consulta los registros y los informes disponibles.

3. Bucles de enrutamiento (554 5.4.14)

Un bucle aparece cuando los servidores se devuelven repetidamente un mensaje hasta alcanzar el límite de saltos. Puede producir un informe de no entrega, aunque el momento y el código dependen del sistema. También puede congestionar las colas y retrasar otros mensajes.

Situaciones que conviene revisar:

• El usuario A reenvía a B y B tiene una regla que reenvía a A.
• A reenvía a B, que tiene una respuesta de ausencia. Si las reglas permiten respuestas repetidas y no hay protección suficiente, la respuesta puede volver por el reenvío y crear un bucle; no sucede automáticamente en todos los sistemas.
• Una dirección catch-all reenvía a un buzón que, a su vez, reenvía a una dirección inexistente del mismo dominio y vuelve a entrar en el catch-all.

554 5.4.14 Hop count exceeded - possible mail loop

Comprueba toda la cadena de enrutamiento, incluidas las respuestas automáticas y los destinos catch-all, antes de activar el reenvío en producción.

Medidas: SRS y ARC

Dos mecanismos del servidor pueden mejorar la autenticación del correo reenviado, sin garantizar la entrega. SRS reescribe el remitente del sobre para que SPF pueda pasar con una configuración correcta. ARC conserva una cadena autenticada de resultados que un receptor puede decidir utilizar para superar un fallo DMARC. Ninguno es una simple regla del cliente: requieren soporte en el servidor.

SRS: Sender Rewriting Scheme

SRS reescribe el remitente del sobre (P1) con un dominio que controlas. En lugar de mantener alice@bank.com, cuyo dominio quizá no autorice tu servidor, el reenviador utiliza un Return-Path como este:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF comprueba ahora tu dominio. Puede pasar si su registro SPF autoriza la IP saliente y la evaluación DNS se completa correctamente. Esto no alinea por sí solo ese dominio con el From visible original para DMARC.

El hash y la marca de tiempo permiten validar y encaminar rebotes: un informe dirigido a una dirección SRS válida puede decodificarse para devolverlo a Alice. Estas direcciones tienen vigencia limitada y un propósito concreto. La validación SRS no sustituye los controles de destinatarios y de relay necesarios para evitar un relay abierto.

ARC: Authenticated Received Chain

SRS puede corregir SPF, pero no necesariamente la alineación entre el sobre y la cabecera. ARC (RFC 8617) no cierra esa brecha. El servidor añade un sello criptográfico que conserva los resultados de autenticación observados al recibir el mensaje y permite verificar su cadena.

Google y Microsoft pueden utilizar ARC de intermediarios que consideran fiables, según sus propias políticas. Una cadena ARC válida y una buena reputación no garantizan la aceptación ni la llegada a la bandeja de entrada: el receptor conserva la decisión final.

Piensa en ARC como un registro de cadena de custodia. Cada intermediario participante añade una declaración firmada de la autenticación que observó. Los receptores posteriores pueden verificar la cadena y decidir si confían en ella cuando la alineación SPF o DKIM deja de ser suficiente para DMARC.

Gmail y Microsoft 365 admiten ARC en determinados flujos; comprueba las cabeceras y la configuración efectiva del flujo que utilizas. Si tu servidor no implementa ARC, falta ese contexto adicional, pero DMARC aún puede pasar mediante una firma DKIM original válida y alineada.

Implementación: dos caminos

Para reducir los problemas de autenticación al reenviar correo, puedes gestionar tu propio MTA o elegir un proveedor que confirme soporte SRS y ARC para tu flujo. Ninguna opción elimina todos los riesgos de entrega; ambas necesitan pruebas y supervisión.

Opción A: Postfix + postsrsd (autogestionado)

En un servidor Linux con Postfix, postsrsd puede gestionar SRS. Este ejemplo corresponde a la integración TCP de versiones antiguas. Las versiones modernas usan socketmap, incompatible con estas tablas TCP; consulta la documentación de la versión instalada y adapta y prueba la configuración antes de aplicarla:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Responsabilidades de este enfoque:

• Gestionar las claves secretas SRS. Una filtración permite falsificar direcciones SRS; mantén además controles independientes de relay y destinatarios.
• Configurar las exclusiones de dominios locales según tu topología y versión, para evitar reescrituras indebidas del correo interno.
• Gestionar la reputación de la IP saliente, que influye en la entrega a Gmail y Outlook sin determinarla por sí sola.
• Configurar ARC por separado: postsrsd no basta para firmar ARC.

Es una opción viable si se configura y valida correctamente. También exige mantenimiento continuo, que algunos proveedores pueden asumir en parte.

Opción B: TrekMail (reenvío gestionado)

Si eliges TrekMail, confirma antes el soporte SRS automático y ARC para tu plan y flujo de reenvío. Verifica también qué tráfico usa relays SMTP gestionados. No des por incluidas estas capacidades en todos los planes ni por garantizada la reputación o la entrega.

Para emprendedores independientes: pagar $6/mes por buzón solo para reenviar info@yourdomain.com a una bandeja personal puede resultar costoso por usuario. La referencia de Starter es $3.50/mes para hasta 50 dominios, sin tarifa por usuario; confirma el precio vigente, los límites y si el reenvío externo está incluido. Consulta cómo funciona el reenvío de buzones en TrekMail.

Para agencias que administran el DNS de varios clientes, diagnosticar SPF puede consumir tiempo y margen. Un panel común puede simplificar la gestión, siempre que admita los flujos necesarios. Si estás eligiendo entre alias y reglas de buzón completas, la guía de reenvío mediante alias explica las diferencias.

Lista de comprobación antes de reenviar correo a otra dirección

Revisa estos cuatro puntos antes de activar una regla en producción. Ayudan a reducir los riesgos descritos, pero no sustituyen las pruebas de entrega y la revisión de registros.

1. SRS activo cuando corresponda. Comprueba la cabecera Return-Path de un mensaje de prueba entregado. Si el flujo usa SRS, debe reflejar el dominio de reenvío y un formato SRS válido; comprueba también SPF.
2. Evitar cambios en contenido firmado. Configura las protecciones para que no añadan pies de antivirus, etiquetas al asunto ni avisos de "Remitente externo" que invaliden DKIM. Conserva el análisis de seguridad y protecciones equivalentes, por ejemplo con avisos fuera del contenido firmado. La canonicalización y las cabeceras firmadas determinan qué cambios afectan a la firma.
3. Protección contra bucles. Revisa reglas inversas, respuestas de ausencia, destinos catch-all y límites de saltos. Una respuesta automática no crea necesariamente un bucle, pero debes comprobar el comportamiento efectivo.
4. Política saliente de M365. En Exchange Online, autoriza "Automatic Forwarding" solo para los usuarios o grupos aprobados en la política saliente de Defender. Comprueba las demás restricciones y evita habilitarlo globalmente por defecto.

Cuándo no reenviar correo a otra dirección

A veces conviene prescindir del reenvío externo. Si quieres recibir correo de varios dominios en un buzón del mismo sistema, un alias de dominio puede evitar un salto SMTP externo adicional. Aun así, los dominios necesitan una configuración correcta; no desaparecen todas las responsabilidades SPF/DKIM.

La comparación entre alias de dominio y buzones explica cuándo elegir un alias o una regla de reenvío completa. Si estás migrando de proveedor, comprueba la disponibilidad y los límites de la herramienta de migración IMAP de TrekMail: copiar mensajes existentes desde el servidor de origen no sustituye la transición del correo entrante en directo.

Resumen

Al reenviar correo, el destino ve la IP del reenviador. Si se mantiene el remitente original del sobre y esa IP no está autorizada, SPF puede fallar. DMARC aún puede pasar con DKIM válido y alineado. Si ninguno aporta autenticación alineada, falla; el receptor decide el tratamiento y la existencia de un rebote depende del flujo.

Las medidas son del servidor: SRS reescribe el remitente del sobre con un dominio controlado y puede permitir que SPF pase; ARC aporta contexto autenticado en el que un receptor puede decidir confiar. Ninguno garantiza por sí solo la alineación DMARC ni la entrega. Puedes gestionarlos en Postfix o verificar su disponibilidad en una plataforma.

Si prefieres delegar la gestión de claves SRS, ARC y reputación, confirma qué incluye TrekMail para tu caso. La referencia de Starter es $3.50/mes para hasta 50 dominios, tarifa plana sin coste por usuario; valida el precio, las capacidades y las condiciones vigentes. Consulta todos los planes.