Configuras un reenviador y la prueba funciona. Dos semanas después, no aparece el correo con un contrato de un cliente: no está en spam y no ves una devolución. Al consultar los registros encuentras: 550 5.7.1 Unauthenticated email from domain.com.
Una posible causa es un esquema de reescritura del remitente (SRS) ausente o mal configurado, aunque ese código no identifica una causa única. La autenticación comprueba si el servidor está autorizado a enviar para el dominio del sobre. El reenvío puede alterar esa relación. SRS adapta el remitente del sobre, pero en 2026 no basta por sí solo: conocer sus límites importa tanto como entender su función.
Esta guía explica qué hace SRS, cómo puede fallar y qué componentes necesita una configuración de reenvío. Si también investigas problemas de entrega más amplios, como registros MX incorrectos, errores de catch-all o cambios DNS que afectan las rutas, empieza por la guía de configuración y reparación del reenvío de correo.
Por qué SPF puede fallar al reenviar correo
Si el servidor reenvía desde su IP pero mantiene el dominio original en el remitente del sobre, SPF puede fallar cuando ese dominio no autoriza dicha IP. Con DMARC p=reject, el destinatario puede rechazar si tampoco hay DKIM válido y alineado. No es siempre un descarte silencioso: el servidor que entrega puede recibir un error SMTP y generar una notificación de no entrega.
El correo no recorre un conducto continuo: pasa por una cadena de conexiones SMTP, con un nuevo establecimiento de conexión TCP en cada salto. Este ejemplo muestra el posible fallo:
alice@client.comenvía acontact@your-agency.com- Tu servidor acepta el mensaje: la IP que lo entrega está autorizada por el SPF de
client.com - Tu servidor abre una nueva conexión SMTP con Gmail para reenviarlo
- Gmail ve que la conexión procede de tu IP
- El remitente del sobre sigue siendo
alice@client.com - Gmail comprueba el SPF de
client.com: tu IP no está autorizada en este ejemplo - SPF falla. Si
client.compublicap=rejecty no hay DKIM válido y alineado, Gmail puede rechazar el mensaje
La RFC 7208, especificación de SPF, reconoce los problemas que el reenvío puede causar a esta comprobación. Reescribir el sobre permite evaluar un dominio del reenviador sin exigir que cada remitente original autorice su IP.
Dos capas de identidad: el sobre y el encabezado
El correo tiene dos identidades de remitente. El remitente del sobre (RFC 5321, MAIL FROM, P1) sirve para SPF y para dirigir devoluciones; también puede verse en Return-Path al inspeccionar los encabezados sin procesar. El From del encabezado (RFC 5322, P2) es el que muestra el cliente, como Gmail u Outlook. SRS adapta la identidad del sobre al nuevo envío, pero no hace que su dominio coincida necesariamente con el From visible.
| Capa | Nombre técnico | RFC | Función | Visibilidad |
|---|---|---|---|---|
| Remitente del sobre | MAIL FROM / Return-Path | RFC 5321 (P1) | Comprobaciones SPF y ruta de devoluciones | Servidores y lectores de encabezados sin procesar |
| From del encabezado | Encabezado From: | RFC 5322 (P2) | Remitente visible en el cliente | Usuarios finales |
Al reenviar, el From del encabezado sigue siendo alice@client.com. Tu servidor crea una nueva transacción SMTP y SPF evalúa el remitente del sobre en ese salto. El problema aparece si la nueva IP no está autorizada; si SRS cambia el dominio del sobre, hay que evaluar por separado su alineación con el From.
Qué hace realmente SRS
SRS reescribe la dirección del remitente del sobre (P1) antes de abrir la nueva conexión SMTP. El From visible permanece igual. Usar un dominio que autorice al reenviador puede permitir que SPF apruebe en el destino, pero no garantiza ni su resultado ni la entrega, y tampoco establece por sí solo la alineación DMARC con el remitente original.
La analogía postal: recibes una carta de Alice y la vuelves a enviar en otra bolsa, manteniendo su dirección de devolución. El destino ve que tú entregas una carta con la dirección de Alice, lo que puede plantear dudas sobre la autorización. Con SRS sustituyes esa dirección de devolución por la tuya. Así, la dirección corresponde al nuevo envío. Si la bolsa vuelve, llega a ti y puedes encaminar la devolución a Alice.
| Componente | Antes del reenvío | Tras la reescritura SRS |
|---|---|---|
| From del encabezado (P2) | alice@client.com | alice@client.com (sin cambios) |
| Remitente del sobre (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| IP de envío | Tu servidor | Tu servidor |
| Resultado SPF en este ejemplo con autorización correcta | FAIL | PASS |
Cómo interpretar una dirección SRS
SRS convierte el remitente del sobre en una dirección codificada antes del salto de reenvío. El destino evalúa el dominio del reenviador. La dirección incluye un código de autenticación para validar devoluciones, una marca temporal para limitar su vigencia y la dirección original para devolver los avisos al remitente. Son datos estructurados, no caracteres arbitrarios.
Ejemplo de una dirección reescrita con SRS:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: primer salto.
SRS1puede aparecer al reenviar de nuevo y ayuda a limitar el crecimiento de la dirección, sin garantizar una cadena ilimitada - 4fac: ejemplo de un código HMAC-SHA1 en una implementación. Sirve para validar devoluciones entrantes; rechazar códigos inválidos ayuda a reducir el abuso mediante devoluciones no solicitadas. El algoritmo y la longitud dependen de la implementación
- PM: marca temporal. Una ventana de 7 a 21 días es un ejemplo de vigencia, no un plazo universal; rechazar direcciones vencidas reduce ciertos riesgos de reutilización, sin eliminarlos por completo
- client.com=alice: remitente original codificado, utilizado para dirigir las devoluciones a la dirección correcta
Cuándo necesitas SRS
SRS es pertinente al reenviar entre dominios cuando la IP del reenviador no está autorizada por el SPF del remitente original. Sin él puede fallar SPF, aunque DKIM alineado aún permita aprobar DMARC. Una infraestructura multidominio necesita comprobar estas condiciones y supervisar el correo reenviado.
Dominio propio hacia Gmail personal. Tienes cool-startup.com y reenvías todo a founder@gmail.com. SRS puede ser importante para SPF en ese recorrido. Sin él, SPF puede fallar si el remitente original no autoriza al reenviador; una política DMARC estricta no implica rechazo automático cuando DKIM válido y alineado se conserva.
MSP o agencia con un clúster compartido. Alojas 200 dominios de clientes que configuran reenvíos hacia sus proveedores, como Comcast, AT&T u Outlook. Reenviar spam puede afectar a la reputación de tu IP y contribuir a una inclusión en listas como Spamhaus. No es inevitable ni ocurre necesariamente en semanas, y SRS no sustituye al filtrado ni garantiza una buena reputación.
Microsoft 365 con un conector de salida. En M365, el comportamiento de SRS puede variar según la ruta y la configuración. Si utilizas un conector, verifica en la documentación de la versión y el tipo de conector si admite SenderRewritingEnabled y cómo se aplica. Revisa también la política de spam saliente y el bloqueo de reenvío externo 5.7.520, que es una restricción de política, no una prueba de fallo SRS. Cualquier cambio debe estar autorizado por la organización.
Por qué SRS no basta
SRS puede permitir que SPF apruebe para el dominio del reenviador, pero eso no equivale a alineación DMARC. DMARC exige que al menos uno de los dominios autenticados por SPF o DKIM esté alineado con el From visible. Si SRS usa un dominio distinto al original, SPF no está alineado; DMARC puede depender entonces de que sobreviva una firma DKIM válida y alineada.
Estas modificaciones pueden invalidar DKIM si afectan las partes firmadas y alteran el resultado según la canonicalización de la firma:
- Añadir
[EXTERNAL]al asunto puede invalidar DKIM si ese encabezado está firmado - Agregar un pie, como avisos antivirus o enlaces de baja, puede cambiar el contenido cubierto por el hash del cuerpo
- Reescribir MIME, por ejemplo convertir codificación de 8 bits a 7 bits, puede alterar el contenido firmado
Si SPF no está alineado y las modificaciones invalidan el DKIM alineado, DMARC falla. El destinatario aplica su política, que puede incluir el rechazo, con o sin una notificación posterior al remitente.
ARC (Authenticated Received Chain, RFC 8617) puede aportar contexto de autenticación al destinatario, sin reparar la alineación. El reenviador sella los resultados observados antes de continuar la ruta. Se añaden tres encabezados:
ARC-Authentication-Results: registra los resultados SPF, DKIM y DMARC realmente observados, no un éxito supuestoARC-Message-Signature: firma partes del mensaje en el momento del sellado, que no necesariamente coincide con su estado al recibirloARC-Seal: firma criptográfica que enlaza esa instancia con la cadena ARC
Un destinatario como Gmail puede evaluar ARC cuando la autenticación del mensaje reenviado falla. Si confía en el sellador y en la cadena, puede aplicar una excepción a su tratamiento de DMARC. Esa decisión es del destinatario: la reputación puede influir, pero no garantiza confianza ni aceptación.
Cómo comprobar que SRS funciona
Envía un mensaje desde una cuenta externa a la dirección reenviada e inspecciona los encabezados completos en el destino. Return-Path muestra si se observa una reescritura SRS o si permanece la dirección original. Comprueba además los resultados de autenticación: la dirección de retorno por sí sola no determina si SPF ha aprobado.
Paso 1: revisa Return-Path en el destino
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>Paso 2: comprueba el DNS del dominio SRS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comEl dominio SRS necesita una ruta de retorno operativa y un SPF que autorice al servidor. Un MX explícito es la configuración habitual, pero su ausencia no significa siempre que el dominio sea inalcanzable: SMTP puede recurrir a A o AAAA mediante el mecanismo de MX implícito. Comprueba la recepción real de las devoluciones, no solo la existencia del registro.
Paso 3: consulta el registro de correo en Linux
grep "srs_forward" /var/log/mail.logLos mensajes hash mismatch o timestamp expired pueden deberse a secretos desincronizados o rotados, direcciones dañadas o devoluciones tardías; no prueban un intento de reutilización maliciosa. Postfix suele requerir una integración SRS externa; PostSRSd es una opción, no la única. Revisa la configuración compatible con tu versión, incluido SRS_EXCLUDE_DOMAINS cuando corresponda, y las rutas locales para evitar reescrituras innecesarias o posibles bucles.
La alternativa más sencilla: dejar de reenviar
SRS adapta el sobre a una nueva entrega SMTP. Usar un buzón real en tu dominio y acceder por IMAP evita ese salto de reenvío y reduce los problemas asociados a él. No garantiza autenticación de extremo a extremo ni elimina todos los riesgos: la entrega entrante y los controles de acceso siguen siendo importantes.
La popularidad del reenvío también tiene una explicación económica: nadie quiere pagar por usuario por un buzón que recibe cinco mensajes al mes. SRS puede resolver parte de una arquitectura elegida por costes, no solo por necesidades técnicas.
El modelo de TrekMail descrito aquí ofrece planes desde $3.50 al mes, varios dominios y almacenamiento compartido a tarifa fija, sin cobro por usuario dentro de los límites del plan. Puedes usar sales@yourdomain.com como buzón IMAP real en un cliente compatible, como Outlook o una integración admitida de la aplicación Gmail, y prescindir de esa ruta de reenvío. Comprueba las funciones y condiciones vigentes; evitar ese salto no garantiza la ausencia de fallos de autenticación.
Para varios clientes, la guía de alojamiento de correo multidominio explica cómo organizar decenas de dominios y reducir el trabajo de gestión. Si mantienes una configuración híbrida con buzones y reenviadores antiguos, la guía de alias y reenvío de correo aborda la configuración con SRS en el recorrido.
Tanto si mantienes el reenvío como si pasas a buzones, comprende qué hace SRS, comprueba su funcionamiento y evalúa ARC según el destinatario. Una configuración incompleta puede impedir la llegada de correo legítimo: es un problema operativo para tu empresa, no una mera curiosidad técnica.
Empieza con una cuenta gratuita de TrekMail, sin tarjeta ni vencimiento del periodo de prueba en las condiciones descritas, y comprueba las funciones y límites actuales para gestionar correo multidominio sin esa complejidad de reenvío.
