Configuras un reenvío: contact@yourdomain.com dirige el correo a Gmail. Funciona durante una semana y después faltan mensajes de clientes. Puede que no hayas recibido una notificación, aunque un rechazo SMTP también puede generar un aviso de no entrega. Los registros muestran 550 5.7.1 Unauthenticated email o 550 5.7.26 This message does not have authentication information. Estos errores no identifican por sí solos una causa, pero el reenvío de correo con SRS aborda un problema habitual: al reenviar, el servidor abre otra conexión SMTP y conserva en el sobre el dominio del remitente original. Si ese dominio no autoriza la nueva IP, SPF puede fallar. Con p=reject en DMARC, el destinatario puede rechazar el mensaje si tampoco pasa DKIM con alineación; el resultado depende de su política.
Activar SRS no resuelve todos los problemas. Incluso con una configuración correcta, la alineación DMARC y las firmas DKIM pueden seguir causando dificultades. Para conocer otros fallos y diagnosticarlos, consulta nuestra guía de configuración y solución de problemas de reenvío.
¿Qué es el reenvío de correo con SRS?
El reenvío de correo con SRS, Sender Rewriting Scheme, modifica la dirección del remitente del sobre cuando un servidor entrega de nuevo un mensaje a otro destino. Sustituye el dominio original por el del reenviador en la dirección técnica de retorno. SPF puede entonces pasar si el DNS de ese dominio autoriza la IP de reenvío. El From visible conserva al remitente original. SRS modifica MAIL FROM, no cifra el mensaje ni oculta identidades: los usuarios pueden consultar los encabezados técnicos.
Existen integraciones para Postfix mediante el servicio postsrsd, configuraciones compatibles de Microsoft 365 y algunas plataformas gestionadas. Comprueba versión, soporte y configuración actuales. SRS ayuda a adaptar el reenvío SMTP a la validación SPF, pero no garantiza la entrega ni el cumplimiento de DMARC.
Por qué puede fallar el reenvío: el nuevo salto SMTP
El reenvío crea un nuevo salto SMTP cuya IP puede no estar autorizada por el dominio original. El correo tiene dos identidades. Header From (RFC 5322) es la que suele mostrar el cliente: From: alice@client.com. Envelope Sender (RFC 5321, MAIL FROM) es la dirección de retorno utilizada para SPF y los avisos de no entrega. Aunque normalmente no aparece en la interfaz, puede verse en encabezados como Return-Path.
Esta secuencia ilustra un fallo posible, no un resultado inevitable:
- Alice envía desde
alice@client.com. Su registro SPF autoriza su servidor y SPF pasa al llegar a tu servidor. - Tu servidor abre una nueva conexión SMTP a
you@gmail.com. En este salto, la IP emisora es la tuya. - Envelope Sender sigue siendo
alice@client.com, pero el registro SPF de client.com no autoriza la IP de tu servidor en este ejemplo. - Gmail comprueba SPF para
client.com. Al no encontrar autorización para esa IP, SPF falla. - Si
client.compublicap=rejecty no hay un resultado DKIM válido y alineado, DMARC falla. Gmail puede rechazar el mensaje según su política; el servidor que lo reenvía puede recibir el rechazo y generar un aviso.
Cómo ayuda SRS a pasar la comprobación SPF
El reenvío de correo con SRS modifica Envelope Sender antes de la nueva entrega y utiliza el dominio del reenviador. El destinatario comprueba SPF contra ese dominio, por lo que necesita un registro válido que autorice la IP real de salida. Header From no cambia y el destinatario sigue viendo al remitente original. Los avisos de no entrega pasan por el dominio del reenviador, que puede recuperar la dirección original conforme a su implementación y controles.
Cómo interpretar la sintaxis SRS
Con SRS, la dirección de retorno puede adoptar una estructura como esta, con un código de autenticación, no una dirección cifrada:
Antes de SRS:MAIL FROM: <alice@client.com>
Después de SRS:MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>
| Componente | Ejemplo | Función |
|---|---|---|
SRS0 | Prefijo | Identifica la primera reescritura. Un reenvío posterior puede utilizar SRS1. |
4fac | Código de autenticación | Ejemplo de HMAC truncado con SHA1 y un secreto local compartido. Reduce el riesgo de avisos falsificados; el algoritmo depende de la implementación. |
PM | Marca temporal | Ejemplo de marca temporal cíclica en Base32. Su validación limita la reutilización de direcciones antiguas, sin impedir todos los ataques de repetición ni el backscatter. |
client.com | Dominio original | Conserva el dominio original para encaminar los avisos de no entrega. |
alice | Usuario original | Parte local de la dirección original. |
@yourdomain.com | Dominio de reescritura | Dominio que realiza la reescritura. Necesita un registro SPF válido que autorice la IP de reenvío. |
Si el mensaje se reenvía de nuevo (A → B → C), una implementación SRS puede usar SRS1 para limitar el crecimiento de la dirección SRS0. La encapsulación concreta no se reduce necesariamente al código y la marca temporal. Comprueba que la parte local siga dentro del límite de 64 caracteres de RFC 5321: la reescritura no lo garantiza para cualquier dirección.
Por qué SRS no basta: la alineación DMARC
Muchos administradores activan el reenvío de correo con SRS y dan el trabajo por terminado, pero los mensajes aún pueden acabar en spam. SRS puede permitir que SPF pase sin conservar la alineación DMARC original. DMARC requiere un resultado válido y alineado de SPF o DKIM respecto al dominio de Header From. Tras la reescritura, SPF autentica yourdomain.com, mientras Header From sigue siendo client.com. En este ejemplo no están alineados; otros casos pueden alinearse según la relación entre dominios y el modo de alineación.
Cuando SPF no está alineado, DMARC depende de una firma DKIM válida y alineada. Algunas modificaciones del reenviador pueden invalidarla si afectan a partes firmadas y no quedan cubiertas por la canonicalización:
- Añadir
[EXTERNAL]al asunto - Insertar pies de antivirus o avisos legales
- Convertir la codificación de 8 bits a 7 bits
- Modificar los delimitadores MIME
Estas modificaciones no invalidan necesariamente cualquier firma, pero deben probarse. Sin SPF válido y alineado ni DKIM válido y alineado, DMARC falla. El destinatario puede rechazar o filtrar el mensaje según su política, aunque SRS haya funcionado correctamente.
El papel de ARC (Authenticated Received Chain)
ARC (RFC 8617) permite al reenviador registrar los resultados de autenticación que realmente observó y sellar el mensaje. Añade tres encabezados:
- ARC-Authentication-Results: Registra los resultados SPF/DKIM/DMARC observados por el intermediario
- ARC-Message-Signature: Firma los encabezados y el cuerpo en el momento del sellado
- ARC-Seal: Firma que vincula el conjunto ARC con la cadena anterior
Si el destinatario valida la cadena y confía en el sellador ARC, puede tenerla en cuenta para aceptar un mensaje pese al fallo DMARC posterior. No convierte ese fallo en un resultado DMARC válido ni garantiza la entrega. Gmail evalúa ARC en producción desde 2019.
Al planificar el reenvío en 2026, considera el reenvío de correo con SRS para SPF, la conservación de las partes firmadas por DKIM y ARC cuando resulte compatible y útil. No son tres requisitos universales ni una combinación suficiente para garantizar la entrega.
Configurar SRS según la plataforma
La configuración varía: Postfix puede integrarse con un servicio externo, Microsoft 365 combina funciones y políticas del entorno, y Google Workspace aplica sus propios controles. Comprueba qué está disponible y activado actualmente; no supongas los mismos valores predeterminados en todas las instalaciones.
Postfix (Linux autogestionado)
Una opción de integración SRS con Postfix es el servicio postsrsd. La siguiente orden es un ejemplo que debe contrastarse con tu distribución y versión:
apt-get install postsrsdEste ejemplo heredado utiliza mapas TCP en /etc/postfix/main.cf. Antes de un cambio autorizado, guarda la configuración, integra los mapas existentes y verifica los sockets, rutas y formatos admitidos por tu versión de postsrsd:
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipientImportante: Verifica cómo configura tu versión las exclusiones; el ejemplo usa SRS_EXCLUDE_DOMAINS en /etc/default/postsrsd para los dominios locales. Una selección incorrecta puede reescribir correo propio o contribuir a bucles en combinación con las reglas de encaminamiento. No es un efecto inevitable de omitir una opción: prueba las rutas de entrada, salida y retorno antes de aplicar cambios.
Microsoft 365
Microsoft 365 admite SRS en determinados flujos; comprueba el comportamiento actual de los grupos de salida, entornos híbridos y conectores. Un bloqueo como 550 5.7.520 Access denied, Your organization does not allow external forwarding indica una restricción de reenvío saliente del entorno emisor, no por sí solo un fallo SRS.
Revisa la política de correo no deseado saliente en la interfaz administrativa vigente. Solo habilita reenvíos legítimos para destinatarios y usuarios autorizados tras una revisión de seguridad, sin desactivar indiscriminadamente la protección. La orden siguiente no es universal: su parámetro puede no estar disponible. Verifica el cmdlet, la versión y la documentación aplicables antes de cualquier cambio:
Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $trueGoogle Workspace
Google aplica mecanismos y controles propios. Examina, entre otros, estos riesgos, que no son exclusivos de Workspace:
- Límites de volumen: Un catch-all que reenvía a Gmail puede superar las cuotas aplicables. Una avalancha de spam puede activar restricciones; comprueba los límites actuales y el estado de la cuenta, sin asumir una suspensión automática.
- Bucles y mensajes ausentes: Las reglas y la detección de bucles pueden impedir determinados reenvíos. Revisa los registros disponibles, los avisos SMTP y las herramientas de seguimiento; no presupongas que siempre se descarta el mensaje sin rastro.
Diagnosticar problemas de reenvío con SRS
Los encabezados completos pueden aportar pistas, pero no siempre están disponibles ni bastan para identificar la causa. Envía una prueba desde ProtonMail al reenviador y examina lo recibido en el destino final. Completa la revisión con registros SMTP, configuración y seguimiento de mensajes cuando estén disponibles.
Comprobación 1: Return-Path
Sin reescritura SRS visible:Return-Path: <original@protonmail.com>
Con reescritura SRS visible:Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>
Si Return-Path conserva el dominio original, revisa si esa ruta necesita SRS y si está excluida o evita los mapas configurados. También puede haber un servicio detenido o una integración incorrecta, pero el encabezado por sí solo no lo demuestra.
Comprobación 2: Authentication-Results
Busca spf=pass asociado al dominio reescrito en encabezados de autenticación fiables del destinatario. Un dmarc=fail pese a SPF válido puede deberse a falta de alineación SPF y a DKIM ausente, inválido o no alineado. Investiga las firmas y los cambios de asunto o cuerpo, no solo si existe una firma.
Comprobación 3: DNS
dig yourdomain.com TXT +shortConfirma que el dominio SRS tenga SPF válido para la IP de salida y una ruta de retorno accesible. Un registro MX no basta para demostrarlo y su ausencia no impide siempre recibir correo: puede existir una ruta MX implícita mediante A/AAAA. Prueba la dirección de retorno y revisa los errores reales del destinatario.
Comprobación 4: registros de Postfix
grep "srs_forward" /var/log/mail.logLos errores hash mismatch o timestamp expired pueden indicar secretos distintos entre nodos, rotación de claves, diferencias horarias, configuración incorrecta o direcciones antiguas. También pueden aparecer durante intentos de repetición; no demuestran un ataque por sí solos.
Cuándo optar por un buzón en lugar de reenvío SRS
El reenvío de correo con SRS responde a un desajuste de identidad creado por un salto intermedio. SRS, la conservación de DKIM y, cuando proceda, ARC añaden dependencias operativas. El reenvío puede parecer más barato por las licencias por usuario, pero conviene incluir el tiempo de mantenimiento y diagnóstico antes de decidir.
Compara ambos enfoques:
| Reenvío de correo con SRS | Buzón alojado (TrekMail) | |
|---|---|---|
| Alineación SPF | Puede perderse respecto al From original | Posible con una ruta de salida autorizada y alineada |
| DKIM | Los cambios en partes firmadas pueden invalidarlo | Firma según el proveedor y la configuración de salida |
| DMARC | Necesita SPF o DKIM válido y alineado; ARC puede influir en la política | Requiere configuración y pruebas de alineación |
| Complejidad | Integración postsrsd, conservación de firmas y ARC si corresponde | Asistente de dominio según funciones disponibles |
| Coste por usuario | $0 más el tiempo de diagnóstico en este ejemplo | Precio fijo y almacenamiento compartido según el plan |
| Varios dominios | Configuración del servidor y sus rutas | Hasta 1,000+ dominios en la oferta descrita, según el plan actual |
TrekMail describe planes de precio fijo con almacenamiento compartido entre buzones y dominios, no capacidad ilimitada ni una tarifa basada únicamente en almacenamiento. Comprueba límites y condiciones actuales. Para agencias, compara este modelo con una configuración habitual de reenvío a Gmail o consulta la guía de ventajas y límites del reenvío mediante alias. Si aún dudas entre alias y buzones, revisa la comparación entre alias de dominio y buzón.
Alojar directamente el buzón en TrekMail elimina ese salto de reenvío y puede evitar la necesidad de SRS o ARC para esa ruta. El asistente puede ayudar a preparar SPF, DKIM y DMARC, pero debes autorizar y probar cada ruta de salida, incluido un proveedor SMTP externo compatible con el plan y sus credenciales. Ser el servidor MX del dominio no autoriza automáticamente el envío SMTP ni garantiza la autenticación.
Prueba TrekMail: la oferta descrita incluye Nano sin tarjeta y una prueba de 14 días en Starter desde $3.50/mo con SMTP gestionado. Comprueba disponibilidad, requisitos, funciones y precios actuales.
Resumen
El reenvío de correo con SRS es una herramienta útil en las arquitecturas de reenvío de 2025-2026, no una obligación universal para todo reenviador. Sin SRS, SPF puede fallar si el dominio original no autoriza la nueva IP. Con SRS, la comprobación SPF puede tener éxito si la autorización es correcta, pero puede faltar alineación con el From original. DMARC necesita SPF o DKIM válido y alineado.
En Postfix, comprueba la versión de postsrsd, los mapas de main.cf y las exclusiones. En Microsoft 365, revisa las políticas autorizadas y las funciones realmente disponibles, sin aplicar una orden no compatible. En Workspace, examina cuotas, reglas, registros y estado de las cuentas.
Combina SRS cuando sea necesario, conservación de las firmas DKIM y ARC cuando el destinatario lo admita y confíe en la cadena. No garantiza la entrega. Otra opción es alojar el buzón en el destino real, manteniendo la configuración y las pruebas de autenticación necesarias.
