Reenvío de correo del dominio: diagnóstico con SRS y ARC

El reenvío de correo del dominio no consiste solo en pasar un mensaje: el servidor abre otra conexión SMTP al destino. Si conserva el remitente original del sobre, la IP del reenviador puede no estar autorizada por ese dominio. Esto puede afectar a la entrega; la visibilidad de los rebotes depende de la ruta y de los registros disponibles.

Sin una configuración de autenticación adecuada, el correo reenviado puede sufrir filtrado en Gmail, rechazos 550 en Yahoo o bloqueos de políticas en Microsoft 365. No todos los proveedores ni todos los mensajes reaccionan igual, y un fallo no siempre resulta visible en el buzón de destino.

Esta guía explica tres patrones útiles en 2026, ejemplos de errores de los principales proveedores y una lista de comprobaciones que puedes recorrer en menos de diez minutos. Para configurar todo el recorrido, consulta nuestra guía completa de configuración y reparación del reenvío.

Por qué el reenvío de correo del dominio puede fallar SPF

El reenvío puede fallar SPF cuando tu servidor realiza la nueva entrega SMTP pero el Return-Path conserva el dominio original. El destino consulta el registro SPF de ese dominio y comprueba si autoriza la IP de conexión. Si no la autoriza, SPF puede fallar. Una política DMARC p=reject no implica por sí sola que se elimine el mensaje: una firma DKIM válida y alineada con el From original todavía puede permitir que DMARC pase.

Este es un ejemplo de la secuencia de fallo:

1. alice@bank.com escribe a info@yourdomain.com. El registro SPF del banco autoriza sus propios servidores.
2. Tu servidor entrega de nuevo a you@gmail.com. Gmail ve la IP de tu servidor, pero el Return-Path sigue indicando bank.com.
3. Si esa IP no está autorizada por el SPF de bank.com, SPF puede fallar.
4. Si el servidor modifica el cuerpo o una cabecera firmada, DKIM también puede fallar, según la firma y su canonicalización. Si no queda ningún resultado alineado válido, DMARC falla y el receptor puede aplicar su política de rechazo.

Un rebote puede llegar al remitente del sobre o quedar registrado en las colas. Revisa esos registros antes de concluir que el mensaje desapareció sin aviso.

Reenviar un catch-all puede aumentar el riesgo. También envías el spam que recibe desde la IP del reenviador. Ese tráfico puede deteriorar su reputación y hacer que mensajes legítimos se filtren o se rechacen. No es una progresión inevitable ni un comportamiento exclusivo de Gmail.

Si aún estás valorando si esta arquitectura encaja con tu caso, consulta las ventajas y limitaciones del reenvío mediante alias antes de elegir la configuración.

Los 3 patrones de reenvío orientados a la entregabilidad

Estos tres patrones abordan riesgos diferentes. Se pueden combinar según la infraestructura y la política del receptor, pero no son requisitos universales ni garantizan la entrega. Preservar una firma DKIM original válida y alineada es especialmente importante.

1. Sender Rewriting Scheme (SRS)

SRS reescribe el remitente del sobre con el dominio del reenviador. El destino puede entonces evaluar SPF para ese dominio, que debe autorizar la IP de salida. La dirección codificada permite devolver los rebotes al remitente original si la implementación y la ruta están bien configuradas.

Antes de SRS:

MAIL FROM: <alice@bank.com>

Después de SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

La limitación: SRS puede resolver la comprobación SPF del sobre, pero normalmente no aporta alineación SPF con el From original para DMARC. Una firma DKIM válida y alineada puede seguir permitiendo que DMARC pase. Si esa firma deja de ser válida, SRS por sí solo no restaura la alineación.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617) protege un historial de resultados de autenticación a través de intermediarios. El reenviador añade cabeceras firmadas que registran sus comprobaciones; no constituyen por sí solas una prueba de que el remitente sea legítimo.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google y Microsoft pueden considerar una cadena ARC válida procedente de un intermediario de confianza al decidir la entrega. Esto puede ayudar cuando la autenticación final falla, pero la aceptación depende de la política del receptor y no está garantizada.

La confianza es esencial: una firma ARC válida o un dominio nuevo no obtienen automáticamente la confianza del receptor. La reputación y la relación con el intermediario pueden influir.

3. Conducto pasivo: conservación de DKIM

Preservar el mensaje original es una medida importante, con o sin SRS y ARC. Evita añadir pies o reescribir cabeceras firmadas. DKIM firma el cuerpo y determinadas cabeceras según reglas de canonicalización: los cambios relevantes pueden invalidarla, pero no cualquier cambio de un byte rompe todas las firmas.

Los fallos difíciles de diagnosticar pueden venir de una modificación inadvertida. Un filtro añade «Este mensaje fue analizado por MailGuard» al cuerpo y puede invalidar su firma. Los registros de envío quizá no lo indiquen; un dkim=fail (body hash did not verify) en Authentication-Results del destino ofrece una pista, si tienes acceso al mensaje.

Este patrón depende de que una firma DKIM válida y alineada sobreviva a todo el recorrido. Si SPF no está alineado y DKIM deja de ser válido, DMARC puede fallar. El receptor aún decide cómo tratarlo y si considera ARC.

Cómo responden los principales proveedores a los fallos de reenvío

Microsoft, Google y Yahoo pueden bloquear el reenvío por políticas, rechazar correo durante SMTP con un código 550 o filtrarlo después. La reputación y la autenticación influyen. Los códigos siguientes son ejemplos: interpreta siempre el diagnóstico completo, la etapa de entrega y los registros, sin asumir una respuesta universal.

Microsoft 365 (Exchange Online)

Una política antispam saliente de Defender puede bloquear el reenvío externo automático. Si el bloqueo se produce en el tenant de origen, el mensaje puede no llegar a tu reenviador. Comprueba la política efectiva antes de modificar la autenticación.

Un aviso 5.7.520 puede dirigirse al remitente del sobre y no al buzón de destino. Revisa el seguimiento del mensaje y los registros pertinentes; no presupongas que nunca podrás ver el rebote.

Google Workspace / Gmail

Un ejemplo de rechazo explícito es 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Puede aparecer si DMARC falla para un dominio con p=reject. La ausencia de SRS o ARC no basta para predecirlo: DKIM original válido y alineado puede permitir que DMARC pase, y SRS solo no aporta esa alineación.

Reenviar spam desde un catch-all puede perjudicar la reputación de la IP. El resultado puede ser filtrado o rechazo, con señales diferentes en las respuestas SMTP y en los registros. No implica necesariamente una pérdida silenciosa y progresiva de todo el correo.

Yahoo / AOL

Yahoo puede rechazar con un código 550 correo reenviado que no cumpla sus políticas de autenticación. Añadir [FWD] o [External] a un asunto firmado puede invalidar DKIM; si tampoco hay SPF alineado, DMARC puede fallar. No significa que se rechace el 100% de esos mensajes ni que toda instalación sin SRS/ARC pierda el correo: importan la firma conservada, la política y el diagnóstico completo.

Lista de diagnóstico del reenvío

Cuando falle el reenvío de correo del dominio, sigue esta secuencia antes de cambiar la configuración:

1. Lee Authentication-Results en el destino («Mostrar original» en Gmail; origen del mensaje en Outlook), si el mensaje está disponible.

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → comprueba el dominio del sobre, la IP y SRS; el resultado no identifica por sí solo la causa.
   dkim=fail (body hash) → investiga cambios del cuerpo y problemas de firma.
   Ambos fallos pueden causar un fallo DMARC si no queda otro resultado alineado válido; el rechazo depende del receptor.
2. Busca bucles de enrutamiento. 5.4.14 Hop count exceeded orienta hacia un exceso de saltos. Traza toda la ruta y busca ciclos como A→B→C→A.
3. Prueba Reply-To. La respuesta suele ir a Reply-To si existe, y al From si no. Comprueba el destino previsto y ambas cabeceras antes de atribuir una respuesta al reenviador a una reescritura del From.
4. Audita todos los componentes que tocan el mensaje. Filtros antispam, antivirus, listas y herramientas antiphishing pueden modificar contenido firmado. Revisa sus transformaciones y los registros de cada salto.
5. Comprueba el volumen del catch-all. Un volumen alto de spam reenviado puede deteriorar la reputación y la entrega, aunque algunos mensajes pasen las comprobaciones de autenticación.

Si dudas entre reenvío y enrutamiento por dirección, compara los alias de dominio con los buzones. Resuelven necesidades distintas y cambian los riesgos que debes gestionar.

La infraestructura de reenvío de TrekMail

En Postfix autogestionado, una arquitectura puede incluir postsrsd para SRS, OpenARC para ARC, rotación de claves RSA y conservación del contenido firmado. Son componentes independientes que conviene probar por separado; no todos resultan necesarios en cada arquitectura.

Una firma DKIM adicional del reenviador puede formar parte de su diseño, pero no es un requisito universal de ARC. No sustituye la firma original alineada ni restaura la alineación con el From original si firma otro dominio. Verifica la conservación de DKIM, la cadena ARC y la política del receptor en lugar de atribuir cualquier fallo a la ausencia de una nueva firma.

El diseño descrito para TrekMail combina OpenARC, firma DKIM adicional y reescritura SRS, con un recorrido que conserva el contenido. Comprueba la implementación vigente y las cabeceras de mensajes de prueba. Configura el destino en los ajustes de reenvío del buzón; la entrega sigue dependiendo también del receptor.

La oferta descrita incluye reenvío en Pro ($10/mes) y Agency ($23.25/mes), con una prueba gratuita de 14 días y tarjeta obligatoria para iniciarla. Nano ($0, 10 dominios, SMTP propio) y Starter ($3.50/mes, 50 dominios) se describen sin reenvío. Confirma precios, límites y disponibilidad vigentes en la comparación completa de planes de trekmail.net/pricing.

Conclusión

La entregabilidad del reenvío de correo del dominio en 2026 exige cuidar la autenticación y el recorrido. SRS puede resolver SPF del sobre sin alinear el From original; ARC ofrece un historial protegido que el receptor puede valorar; conservar DKIM original válido y alineado ayuda a que DMARC pase. Combina las medidas que corresponden a tu arquitectura, sin tratar ninguna como garantía de entrega.

Empieza por Authentication-Results al diagnosticar. Interpreta los resultados junto con las cabeceras y los registros de cada salto: una sola cabecera no siempre reconstruye toda la ruta.

Si prefieres no administrar Postfix, configurar correo profesional en tu dominio con TrekMail puede llevar unos 15 minutos, según los requisitos previos. Verifica las funciones de reenvío vigentes y prueba la entrega a tus destinos.