Configuras un reenvío: contact@your-agency.com → you@gmail.com. La prueba funciona. Dos semanas después, no llega un contrato de un cliente empresarial: no aparece ni en spam ni en la bandeja. En los registros encuentras 550 5.7.1 Unauthenticated email, un error que puede tener varias causas. También podrías encontrar 550 5.7.520 Access denied si Microsoft 365 bloquea el reenvío saliente por política. La ausencia del mensaje no demuestra que se haya eliminado en silencio.
El esquema de reescritura del remitente SRS puede resolver parte del problema cuando se configura correctamente. Sin él, SPF puede fallar si el remitente del sobre original no autoriza la IP del reenviador. En 2026, los requisitos de remitentes de Google y Yahoo hacen importante revisar la autenticación, pero no exigen a todos publicar p=reject en DMARC (requisitos de remitentes de Google). Incluso con una política estricta, un DKIM válido y alineado puede mantener DMARC. Esta guía explica SRS a nivel de protocolo, sus límites y los componentes de una configuración adecuada.
Para una visión completa, empieza por la guía de configuración del reenvío de correo y soluciones habituales.
Qué es el esquema de reescritura del remitente (SRS)
SRS reescribe el sobre para reducir los fallos SPF asociados al reenvío. Antes de transmitir el mensaje, cambia la dirección SMTP del sobre (MAIL FROM) para usar el dominio del reenviador en lugar del original. Esa dirección no suele mostrarse en la interfaz del cliente, pero puede consultarse en Return-Path. El destinatario comprueba SPF para el nuevo dominio, que debe autorizar la IP real. Así, la comprobación SPF puede superarse, sin garantizar la entrega ni la alineación DMARC con el From visible. Un fallo SPF por sí solo no demuestra suplantación.
Las dos capas de identidad del correo
Para investigar SRS conviene distinguir dos identidades que a menudo se confunden. SPF evalúa el dominio del sobre; DMARC compara los dominios autenticados por SPF o DKIM con el From visible. El reenvío cambia la conexión y puede afectar estas comprobaciones de forma distinta.
| Capa | RFC | Campo | Comprobado por | ¿Visible para el destinatario? |
|---|---|---|---|---|
| Sobre (P1) | RFC 5321 | MAIL FROM / Return-Path | SPF | No suele mostrarse en la interfaz; sí en los encabezados sin procesar |
| Encabezado (P2) | RFC 5322 | From: | Alineación DMARC | Sí |
El sobre interviene en la transmisión y en las notificaciones de entrega fallida, y su dominio se comprueba con SPF. El From del encabezado aparece en el cliente y sirve como referencia para la alineación DMARC. Una nueva conexión de reenvío puede causar un fallo SPF si la IP no está autorizada, pero no hace fallar necesariamente todos los mecanismos: una firma DKIM válida y alineada puede permitir que DMARC siga superando la comprobación.
El problema del nuevo salto: por qué puede fallar SPF
Al reenviar, el servidor abre una nueva conexión SMTP con el destino. Si el remitente del sobre sigue siendo alice@bank.com, pero la IP es la tuya, SPF comprueba tu IP frente al registro de bank.com. En este ejemplo no está autorizada, por lo que SPF falla. Si bank.com publica DMARC p=reject y no hay DKIM válido y alineado, el destinatario puede rechazar. Un rechazo SMTP puede producir una devolución; no siempre supone una desaparición sin aviso.
| Paso | Acción | Remitente del sobre | IP de conexión | Resultado SPF del ejemplo |
|---|---|---|---|---|
| 1 | Alice → tu servidor | alice@bank.com | IP del banco | PASS |
| 2 | Tu servidor → Gmail | alice@bank.com | IP de tu servidor | FAIL: sin autorización para bank.com |
Este problema puede aparecer aunque la regla esté bien configurada: depende de la autorización del nuevo servidor para el dominio del sobre. No afecta inevitablemente a todos los reenviadores. SRS es una forma de adaptar esa identidad a la nueva conexión.
Cómo reescribe SRS el sobre
SRS cambia la dirección MAIL FROM al dominio del reenviador antes de iniciar la nueva conexión SMTP. El encabezado From: visible permanece como lo escribió el remitente original. El siguiente ejemplo supone que el nuevo dominio autoriza correctamente al servidor:
# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)
# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)El destino comprueba SPF para your-domain.com, que debe autorizar al servidor. En ese caso, la comprobación SPF puede superarse. El destinatario sigue viendo From: alice@bank.com. SRS cambia la identidad evaluada por SPF, pero aún hay que revisar su alineación con el From original.
Cómo interpretar el formato de una dirección SRS
La dirección SRS de Return-Path puede parecer extraña, pero cada segmento tiene una función. Entenderla ayuda a comprobar la reescritura y a investigar los problemas junto con los registros y los resultados de autenticación.
Ejemplo: SRS0=4fac=PM=bank.com=alice@your-domain.com
| Componente | Valor | Función |
|---|---|---|
| Prefijo | SRS0 | Marca de primera reescritura. SRS1 puede usarse en una segunda transferencia para limitar el crecimiento de la dirección, no para garantizar cadenas ilimitadas. |
| Código de autenticación | 4fac | Ejemplo de HMAC con el secreto del servidor. Ayuda a validar direcciones de devolución SRS y a reducir falsificaciones; no elimina todos los riesgos. |
| Marca temporal | PM | Ejemplo de marca temporal cíclica en base32. Limitar su vigencia reduce ciertos abusos de direcciones reutilizadas; el formato y el plazo dependen de la implementación. |
| Origen | bank.com=alice | Datos del remitente original que permiten dirigir las devoluciones a alice@bank.com. |
El segundo problema: la alineación SPF después de SRS
SRS puede permitir que SPF supere la comprobación, pero no conserva necesariamente la alineación con el From original. DMARC requiere comprobación y alineación en al menos una vía, SPF o DKIM. Por eso configurar SRS correctamente no basta para garantizar que la comprobación DMARC se supere.
DMARC requiere que al menos un dominio autenticado esté alineado con el dominio del encabezado visible From:. En el ejemplo con SRS:
- Comprobación SPF: PASS: tu IP está autorizada por el dominio del sobre
your-domain.com - Alineación SPF: FAIL: el sobre
your-domain.com≠ el encabezadobank.com
En ese caso, DMARC puede depender de DKIM. Una firma original válida y alineada puede mantenerse si las partes firmadas no cambian de una forma que altere la verificación según su canonicalización. Añadir avisos de «correo externo», pies antivirus o transformar la codificación MIME de 8 bits a 7 bits puede invalidar la firma si afecta al contenido firmado.
Si SPF no está alineado y las modificaciones invalidan el DKIM alineado, DMARC falla. El destinatario puede rechazar según su política, aunque SRS haya realizado correctamente la reescritura. Eso no significa que todo el correo reenviado se pierda.
ARC: un complemento de SRS
ARC (Authenticated Received Chain, RFC 8617) puede complementar SRS. Mientras SRS adapta el sobre para SPF, ARC permite sellar los resultados de autenticación realmente observados y transmitirlos al siguiente receptor. No certifica que el mensaje esté libre de spam ni garantiza su aceptación.
ARC añade ARC-Authentication-Results, ARC-Message-Signature y ARC-Seal. Los resultados anteriores pueden aportar contexto si DKIM falla después, pero la firma ARC del mensaje también puede verse afectada por cambios posteriores en sus partes firmadas. No todos sus componentes sobreviven a cualquier modificación del cuerpo.
La limitación: el destinatario decide si confía en el sellador y la cadena. En un entorno Microsoft 365 compatible, un administrador autorizado puede configurar selladores de confianza mediante PowerShell (Set-ArcConfig) cuando proceda y no estén ya incluidos. Esa configuración debe seguir la política de la organización. Gmail decide su confianza con sus propios criterios; no puedes imponerla manualmente.
Para producción, evalúa SRS para la comprobación SPF y ARC como contexto adicional cuando DKIM no se conserve. No son requisitos universales de toda entrega ni, juntos, una garantía suficiente de recepción por todos los proveedores. También importan DNS, filtrado, políticas y reputación.
Diagnóstico de problemas SRS: lista de comprobaciones
Si el correo reenviado no llega, esta lista ayuda a distinguir un problema de SRS de un bloqueo previo o de otras causas.
1. Revisa Return-Path
Envía una prueba desde una cuenta externa a través del reenviador e inspecciona los encabezados sin procesar en el destino. Los resultados siguientes ilustran una IP no autorizada antes de SRS y autorizada después; comprueba el resultado real de tu recorrido.
# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)
# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)2. Comprueba los bloqueos de salida de Microsoft 365
Si reenvías desde Microsoft 365 y aparece el bloqueo de política siguiente, el mensaje puede detenerse antes de salir del entorno. SRS no elimina esa restricción.
550 5.7.520 Access denied, Your organization does not allow external forwarding.Un administrador autorizado debe revisar la política de filtro de spam saliente en el portal Defender y decidir si la ruta está permitida. No desactives controles para eludir la política. SRS en el servidor receptor no resuelve este bloqueo.
3. Comprueba los bucles de rutas
Si A reenvía a B y B vuelve a reenviar a A, puede formarse un bucle cuando las reglas permiten repetir el recorrido y las protecciones no lo detienen antes. Busca estos mensajes en los registros:
554 5.4.14 Hop count exceeded
5.4.6 Routing loop detectedDeja de reenviar y utiliza buzones reales
Configurar postsrsd, gestionar secretos HMAC y resolver fallos de alineación DMARC puede añadir trabajo al dirigir correo profesional a bandejas personales para evitar cuotas por buzón. SRS resuelve parte del problema creado por un nuevo salto. Un buzón real puede evitar ese recorrido cuando encaja con tus necesidades.
| Enfoque con reenvío | Alternativa con TrekMail según el plan |
|---|---|
| Reenviar sales@ a Gmail y revisar los fallos SRS | Alojar sales@ como buzón IMAP real con entrega directa |
| Configurar SRS, ARC y secretos HMAC por servidor | Sin ese salto de reenvío, no se necesita SRS para esa ruta |
| DKIM inválido puede causar un fallo DMARC si SPF no está alineado | Sin salto de reenvío, se evita esa fuente de cambios; la autenticación sigue necesitando comprobaciones |
| Mensajes ausentes sin información visible de entrega | Registros y seguimiento de mensajes cuando el plan y la configuración los admiten |
En lugar de reenviar contact@client-domain.com a Gmail y mantener SRS, puedes alojar contact@client-domain.com como buzón IMAP en TrekMail. Accede desde un cliente compatible, incluida una integración admitida de la aplicación Gmail: la entrega llega al buzón sin ese nuevo salto. Esto reduce los problemas del reenvío, sin garantizar autenticación de extremo a extremo o llegada a la bandeja principal. Compara las opciones en la guía para reenviar correo de dominio a Gmail o en el análisis de alias frente a buzón.
¿Gestionas varios dominios de clientes? Centralizar sus buzones en TrekMail puede reducir el trabajo de mantener SRS en distintos servidores. La separación entre buzones requiere permisos y configuración adecuados y no garantiza seguridad ni un tiempo fijo de alta. La guía de alojamiento de correo multidominio explica cómo organizar esta gestión según los límites del plan.
La oferta descrita de TrekMail parte de $3.50 al mes e incluye una prueba gratuita de 14 días. Verifica precios, condiciones y funciones actuales del plan antes de crear buzones reales y sustituir las rutas de reenvío que ya no necesites.
