Reenviar correo parece sencillo: configuras una redirección y listo. Pero si no utilizas reenvío con SRS (Sender Rewriting Scheme), SPF puede fallar. Por ejemplo, bank.com envía a una dirección reenviada de tu servidor y este retransmite desde su propia IP. Si conserva bank.com como remitente del sobre y esa IP no está autorizada, SPF falla. Si además no hay DKIM válido y alineado y el dominio publica p=reject, el destinatario puede rechazar. No siempre sucede en silencio: el servidor que entrega puede recibir un error SMTP y generar una devolución.
Esta guía aborda la operación del reenvío con SRS. La guía completa de configuración del reenvío y sus fallos ofrece la visión general. Aquí nos centramos en arquitectura, sintaxis, integración con Postfix y ARC como complemento para transmitir contexto de autenticación, sin garantizar el cumplimiento de DMARC ni la entrega.
Qué hace el reenvío con SRS
SRS reescribe el remitente del sobre cuando el servidor retransmite un mensaje, sustituyendo el dominio original por uno que controlas. La comprobación SPF puede superarse si ese dominio autoriza correctamente la IP del reenviador. El From del encabezado, que muestra el cliente, permanece intacto. La reescritura no garantiza la alineación con ese From ni la aceptación del mensaje.
Sin SRS, un mensaje reenviado puede fallar SPF si la nueva IP no está autorizada. Con SRS puedes adaptar la identidad del sobre a la nueva ruta, pero debes comprobar DNS, DKIM, alineación DMARC y políticas del destinatario. No desaparecen todos los riesgos de autenticación.
Las dos capas de identidad del correo
Para configurar SRS, distingue estos dos campos. SPF comprueba el dominio del sobre, mientras que DMARC toma el From visible como referencia para la alineación.
- Remitente del sobre (RFC 5321 MAIL FROM): dirección de retorno utilizada por los agentes de transferencia para dirigir devoluciones. SPF comprueba si la IP de conexión está autorizada para ese dominio. También puede verse en Return-Path al inspeccionar los encabezados sin procesar.
- From del encabezado (RFC 5322 From): dirección que muestran los clientes. DMARC exige que al menos una vía válida, SPF o DKIM, esté alineada con su dominio. SRS deja este campo sin cambios.
Este ejemplo supone una IP no autorizada antes de SRS y correctamente autorizada después:
| Salto | IP de conexión | Remitente del sobre | Resultado SPF del ejemplo |
|---|---|---|---|
| 1: Alice → tu servidor | Servidor de Alice | alice@client.com | PASS |
| 2: Tu servidor → Gmail (sin SRS) | Tu servidor | alice@client.com (sin cambios) | FAIL |
| 2: Tu servidor → Gmail (con SRS) | Tu servidor | SRS0=Hash=Time=client.com=alice@yourdomain.com | PASS |
SRS coloca un dominio propio en el remitente del sobre. Su SPF debe autorizar el envío real para que la comprobación se supere. Eso no obliga al destinatario a entregar el mensaje. La dirección reescrita no suele aparecer como remitente en la interfaz, pero sigue siendo visible en los encabezados sin procesar.
Sintaxis SRS: qué significan sus componentes
La dirección reescrita puede parecer críptica, pero cada componente tiene una función. Interpretarla ayuda a investigar devoluciones y recorridos con varios saltos.
Una primera reescritura SRS (SRS0) tiene este aspecto:
SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomainSus componentes:
- Hash: código HMAC truncado generado con un secreto local; SHA1 es un ejemplo de algoritmo utilizado en algunas implementaciones. Permite validar direcciones de devolución SRS0 y dificulta su falsificación, sin eliminar todos los riesgos de abuso mediante avisos de no entrega.
- Timestamp: marca temporal, por ejemplo codificada en base32 y con vigencia de 7 a 21 días. El formato y el plazo son configurables según la implementación. Rechazar direcciones vencidas limita ciertos riesgos de reutilización, sin impedir toda repetición maliciosa.
- Origin: datos para reconstruir el remitente original cuando llega una devolución. El servidor recibe el aviso de no entrega, invierte la reescritura y lo dirige al remitente.
- AnchorDomain: dominio bajo tu control. Necesita SPF que autorice al servidor y una ruta operativa para recibir devoluciones, normalmente mediante MX; en ciertos casos SMTP puede utilizar A o AAAA con MX implícito.
En una nueva transferencia, una implementación puede sustituir SRS0 por SRS1:
SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomainSRS1 ayuda a limitar el crecimiento de la parte local, pero sigue siendo necesario comprobar el límite de 64 caracteres de RFC 5321. Si falla una cadena con varios saltos, revisa la longitud junto con autenticación, vigencia, rutas y registros; no es la única causa posible.
Integración con Postfix: configurar PostSRSd
PostSRSd es una opción de integración SRS para Linux y Postfix. Postfix puede consultar su servicio mediante mapas de reescritura, entregándole direcciones del sobre y recibiendo las direcciones transformadas. Los ejemplos siguientes son orientativos: verifica la versión, los paquetes y las rutas antes de adaptarlos, y no los ejecutes sin revisar tu configuración.
Paso 1: requisitos del dominio de reescritura
Antes de editar archivos, prepara el dominio que aparecerá en el remitente del sobre reescrito. Revisa:
- Registros MX: el dominio debe poder recibir avisos de no entrega y devolverlos correctamente al remitente. Un MX explícito es habitual, aunque SMTP admite entrega con MX implícito mediante A o AAAA en determinadas condiciones. Comprueba la ruta real según RFC 5321.
- Registro SPF: el destinatario comprueba la IP del servidor frente a este dominio. Si no está autorizada o el registro tiene errores, la reescritura SRS no basta para superar la comprobación SPF.
- Reputación: retransmitir spam puede afectar al servidor y al dominio de reescritura y contribuir a su inclusión en listas de bloqueo. No es inevitable, y SRS no sustituye al filtrado.
# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"
# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +shortPaso 2: configurar PostSRSd
Según la versión y el paquete, la configuración puede estar en /etc/default/postsrsd (Debian/Ubuntu) o en /etc/postsrsd/postsrsd.conf. Verifica los nombres de parámetros admitidos y el funcionamiento de las exclusiones antes de adaptar este ejemplo. La ausencia de una lista de exclusión no implica por sí sola un bucle:
# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com
# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret
# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.comSi necesitas crear un secreto, ten en cuenta que la redirección siguiente sobrescribe un archivo existente. Haz una copia protegida antes de cualquier cambio, planifica la rotación y la validación de devoluciones entre nodos y conserva permisos restrictivos con el propietario adecuado. Adapta la ruta y ejecuta los comandos solo como un cambio controlado y autorizado:
openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secretPaso 3: integrar con Postfix
La integración se configura en /etc/postfix/main.cf. El ejemplo distingue PostSRSd 2.x con mapas de socket Unix y 1.x con TCP; la sintaxis, el socket y el acceso desde Postfix dependen de la instalación. Comprueba la documentación de tu versión:
# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient
# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipientTras validar la configuración y preparar el cambio, reinicia los servicios cuando proceda:
systemctl restart postsrsd
systemctl restart postfixSRS no basta: el papel de ARC
SRS puede permitir que la comprobación SPF se supere para el nuevo dominio, pero no establece por sí solo la alineación DMARC con el From original. DMARC exige que al menos una vía válida, SPF o DKIM, esté alineada con ese From. Si SPF autentica relay.yourdomain.com y no client.com, en este ejemplo no está alineado. DMARC puede depender entonces de DKIM válido y alineado.
Las modificaciones durante el reenvío pueden invalidar DKIM si alteran partes firmadas según la canonicalización utilizada. Prefijos de «remitente externo» en el asunto, pies con enlaces de baja o cambios MIME no rompen inevitablemente toda firma: depende de qué se haya firmado. Si se pierde el DKIM alineado y SPF tampoco está alineado, DMARC falla y el destino aplica su política.
ARC, Authenticated Received Chain, definido en RFC 8617, permite transmitir los resultados de autenticación realmente observados. Un destinatario que confíe en el sellador y la cadena puede usarlos para su decisión pese a un fallo DMARC. ARC no repara la alineación ni garantiza la entrega.
Una instancia ARC añade tres encabezados:
ARC-Authentication-Results: resultados de las comprobaciones de autenticación observadas por el servidorARC-Message-Signature: firma de partes de los encabezados y del cuerpo en el momento del selladoARC-Seal: enlace criptográfico que conecta la instancia con la cadena a través de los saltos
SRS adapta el remitente del sobre; ARC aporta contexto de autenticación. Pueden complementarse en entornos con políticas estrictas, pero no son siempre necesarios ni suficientes para garantizar la entrega. Si DKIM falla y SPF no está alineado, SRS por sí solo no permite superar la comprobación DMARC.
La referencia normativa de SPF, cuyas dificultades de reenvío aborda SRS, es la RFC 7208.
Problemas de proveedores que conviene conocer
Incluso con SRS y ARC bien configurados, un proveedor puede aplicar políticas que bloqueen el reenvío con independencia de la autenticación. Comprueba su alcance y el entorno donde se aplican antes de atribuir el problema a tu configuración.
| Proveedor | Error o comportamiento | Posible causa | Acción |
|---|---|---|---|
| Microsoft 365 | 550 5.7.520 Access denied | Política de M365 en el entorno de origen que restringe el reenvío externo saliente para reducir la fuga de datos | Un administrador autorizado revisa la política de spam saliente en Defender y permite solo rutas aprobadas con controles adecuados |
| Microsoft 365 | 554 5.4.14 Hop count exceeded | Posible bucle de rutas, por ejemplo si un catch-all reenvía al exterior y el recorrido regresa | Revisar catch-all y las rutas, y eliminar el bucle donde se origina |
| Gmail / Workspace | Mensajes que no llegan; puede no haber NDR | Una detección de bucles puede causar rechazo o descarte; el aviso depende del recorrido y del sistema | Consultar las herramientas de entrega disponibles en Google Admin si tienes acceso autorizado a Workspace; corregir las rutas |
| Gmail / Workspace | Revisión de remitentes de gran volumen | El ejemplo >5,000 mensajes reenviados al día no clasifica automáticamente todo ese tráfico como envío masivo; revisa los criterios vigentes | Evaluar la arquitectura de reenvío de gran volumen y los requisitos realmente aplicables |
Ante el error M365 550 5.7.520, identificar la política correcta puede ahorrarte tiempo: normalmente se refiere al reenvío saliente del entorno de origen, no a una política que debas cambiar en el destino. SRS o ARC no levantan esa restricción. La revisión y cualquier cambio en Defender deben realizarlos administradores autorizados conforme a la política de seguridad.
Cómo verificar el reenvío con SRS
Antes de utilizarlo en producción, envía un mensaje de prueba e inspecciona los encabezados sin procesar en el destino. Un Return-Path con SRS indica una reescritura visible para ese mensaje, no que toda la entrega esté garantizada. Si conserva el remitente original, puede haber una exclusión, una ruta que no consulta SRS o un problema de integración; no demuestra por sí solo que el servicio esté detenido.
1. Comprueba Return-Path
Envía una prueba desde una cuenta externa, por ejemplo ProtonMail, a la dirección reenviada. Busca Return-Path en el origen del mensaje y comprueba también los resultados de autenticación:
Return-Path: <SRS0=...@yourdomain.com>→ se observa una reescritura SRS; aún debes verificar el resultado de autenticaciónReturn-Path: <alice@protonmail.com>→ no se observa reescritura; revisa exclusiones, ruta y servicio
2. Comprueba el DNS del dominio de reescritura
# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short
# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short3. Consulta los registros de Postfix
grep -E "srs_forward|canonical" /var/log/mail.log | tail -50Busca las consultas al servicio SRS y las direcciones devueltas. Una conexión rechazada puede deberse a un servicio detenido, una ruta de socket o puerto incorrecta, permisos o reglas de red. systemctl status postsrsd ayuda a revisar el servicio, pero no descarta las demás causas.
4. Prueba la conexión y TLS
Los fallos de SRS y de conexión pueden producir síntomas parecidos. Esta prueba ayuda a separar la conectividad SMTP y la negociación TLS:
openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtpUn tiempo de espera puede deberse a la red, al puerto o al filtrado, no solo a TLS. Una negociación fallida requiere revisar su respuesta concreta. Investiga estas causas por separado de la reescritura SRS.
Cuándo dejar de reenviar y alojar buzones
SRS, ARC, el dominio de reescritura, los secretos, las exclusiones y la reputación suponen trabajo operativo. A veces esta arquitectura se elige para evitar licencias por buzón. Reenviar sales@ a una bandeja personal evita en un ejemplo una licencia de $6 al mes. Puede tener sentido con una dirección, pero resultar costoso al gestionar diez.
La guía de ventajas y límites de alias y reenvío compara las situaciones en las que esta arquitectura encaja y aquellas en las que añade problemas. La guía para elegir entre alias y buzón ayuda a definir la estructura de direcciones.
| Enfoque anterior: reenviar | Alternativa: alojar en TrekMail según el plan | |
|---|---|---|
| Comprobación SPF | Puede requerir integración SRS y configuración del dominio de reescritura | Gestión del servidor según la configuración; la entrega directa evita ese salto |
| DMARC | DKIM alineado puede bastar; ARC puede aportar contexto | OpenARC en configuraciones admitidas, sin garantizar el paso de DMARC |
| Devoluciones | El dominio de reescritura necesita una ruta de recepción operativa | Gestión por la infraestructura de TrekMail según la ruta y el plan |
| Operación continua | Rotación de secretos, actualización de exclusiones y seguimiento de reputación | Menos mantenimiento del reenvío; siguen siendo necesarios controles de configuración y acceso |
| Almacenamiento | Depende del proveedor de destino, que también puede ofrecer almacenamiento compartido | Almacenamiento compartido entre buzones dentro de los límites del plan |
La oferta descrita de Pro ($10 al mes) incluye 100 dominios y 50GB de almacenamiento compartido. Puedes alojar sales@, support@ e info@ como buzones IMAP reales sin pago por usuario dentro de los límites del plan y evitar esas cadenas de reenvío. Comprueba las condiciones actuales: la entrega directa no garantiza recepción ni conservación indefinida.
Si necesitas reenvío, por ejemplo para reunir varios dominios en un destino, las configuraciones descritas de Pro y Agency contemplan SRS y firmas OpenARC gestionados en el servidor. Verifica su disponibilidad y los requisitos actuales; no garantizan entrega. Nano con SMTP propio no implica acceso automático al reenvío: si tu infraestructura externa admite esa ruta, tendrás que integrar SRS allí y adaptar PostSRSd u otra solución a su versión.
Para el recorrido hacia Gmail, la guía de reenvío del correo de dominio a Gmail detalla sus posibles fallos y las comprobaciones.
En pocas palabras
El reenvío con SRS cambia el remitente del sobre para que SPF evalúe un dominio que autorice la IP real. La comprobación SPF puede superarse sin que por ello se supere DMARC. PostSRSd es una opción para Postfix: verifica dominio y ruta de devoluciones, SPF, secretos, exclusiones y mapas compatibles en main.cf. Evalúa ARC cuando aporte contexto al destinatario si DKIM se pierde y SPF no está alineado.
Comprueba encabezados, autenticación y devoluciones tras cada cambio. Si el mantenimiento supera el ahorro de licencias, considera buzones con entrega directa. Revisa los planes de TrekMail: las condiciones descritas de Nano no requieren tarjeta, pero el alta y las funciones dependen de requisitos y límites actuales. Pro contempla reenvío SRS y ARC gestionados en las configuraciones admitidas.
