El reenvío de correo rompe DMARC — Arréglalo con SRS (y otras opciones)

diciembre 7, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 5

¿Te fue útil?

El reenvío de correo se siente como fontanería: conectas A con B y te vas a casa. Hasta que el CEO reenvía una factura de proveedor a su buzón personal, desaparece y pasas la tarde explicando “alineación” a gente que cree que DNS es un departamento.

El reenvío rompe DMARC de formas que no son misteriosas, solo están poco documentadas en los sitios que los operadores ocupados realmente consultan. La buena noticia: puedes arreglar la mayor parte con SRS, además de un par de hábitos operativos aburridos que te mantienen fuera de las revisiones de incidentes.

Por qué el reenvío rompe DMARC (la falla mecánica)

DMARC es simple en concepto y brutal en la práctica. Le pregunta a un sistema receptor:

¿Este mensaje se autentica con SPF y/o DKIM?
¿Los identificadores autenticados están alineados con el dominio del “From:” que ven los usuarios?
Si no, ¿qué indica la política DMARC publicada por el remitente que debo hacer?

El reenvío rompe la primera parte de esa cadena de una manera muy específica: cambia la dirección IP que entrega el mensaje mientras mantiene intacto el encabezado visible “From:”.

SPF pasa en el receptor original, luego falla en el receptor del reenvío

SPF se evalúa contra la IP de conexión y el dominio del remitente en el sobre SMTP (Return-Path). Cuando un reenviador relaya un mensaje, esa IP se convierte en la IP de conexión. A menos que el remitente original haya autorizado las IP del reenviador en su SPF (lo cual no hizo), SPF falla.

A este punto, mucha gente dice “pero existe DKIM”. Sí. Y DKIM puede salvarte —hasta que no lo hace:

Si la firma DKIM sobrevive intacta y está alineada con el dominio From, DMARC puede pasar incluso si SPF falla.
Si el reenviador modifica el mensaje (pie de página, etiquetas en el asunto, ajuste de líneas, re-codificación MIME), DKIM puede romperse.

DMARC solo necesita uno de SPF o DKIM que pase y esté alineado. El reenvío comúnmente provoca que SPF falle. Las listas de correo y algunas pasarelas “serviciales” comúnmente provocan que DKIM falle también. Ese es tu fallo de DMARC.

Alineación: la parte que la gente omite y luego lamenta

Incluso cuando SPF técnicamente pasa, DMARC puede seguir fallando por desalineación. La alineación compara el dominio que autenticó (el dominio SPF o el d= de DKIM) con el dominio en el encabezado From visible.

Si tu reenviador reescribe el remitente del sobre pero lo hace con un dominio que no se alinea con el From, DMARC seguirá fallando a menos que DKIM pase y esté alineado. Por eso a veces se oye “habilitamos SRS pero no ayudó”: SRS corrige el resultado de SPF, pero no la alineación con From, a menos que también asegures la alineación DKIM o aceptes que la alineación SPF será con el dominio del reenviador.

Una verdad seca: DMARC no fue diseñado para facilitar el reenvío. Fue diseñado para hacer que la suplantación sea costosa. El reenvío es daño colateral.

Broma #1: Reenviar correo es como mover el correo de otra persona a mano—eventualmente te acusarán de falsificar la letra.

Hechos y breve historia que explican el desorden actual

Algo de contexto ayuda porque los debates sobre DMARC se vuelven emocionales rápido, como el deporte, la religión y qué formato de configuración de MTA es “legible”. Aquí hay hechos concretos que moldean el problema del reenvío:

SPF comprueba la ruta, no el contenido. Valida de dónde vino el correo (IP de conexión) en relación con el dominio del remitente del sobre.
DKIM comprueba el contenido, no la ruta. Firma cabeceras/cuerpo del mensaje; el reenvío puede preservarlo si no se cambia nada.
DMARC se publicó en 2015 como RFC (7489). Unificó políticas e informes alrededor de SPF/DKIM más alineación.
El reenvío existía antes de SPF/DKIM por décadas. El modelo SMTP original asumía confianza entre operadores. Esa era terminó.
Yahoo y AOL endurecieron políticas DMARC en 2014. Las listas de correo se rompieron ruidosamente; la industria empezó a tomar DMARC en serio porque las bandejas de entrada quedaron vacías.
Muchas pasarelas empresariales modifican correo “por seguridad”. Exenciones, etiquetas DLP y re-encapsulado de contenido invalidan rutinariamente firmas DKIM.
SRS existía antes de que DMARC fuera común. Fue creado para hacer que SPF sobreviva al reenvío reescribiendo el remitente del sobre.
ARC (Authenticated Received Chain) es más reciente. Es una forma para que intermediarios avalen los resultados de autenticación upstream cuando los mensajes se transforman.
La aplicación de DMARC la decide el receptor. Incluso con “p=none”, los receptores pueden aplicar políticas locales; con “quarantine” o “reject”, tu correo reenviado vive peligrosamente.

Modos de fallo: qué se rompe y qué sobrevive

Caso 1: Reenvío simple, sin modificaciones

Típico: user@forwarder.example reenvía a user@gmail.com.

SPF en Gmail: falla (la IP del reenviador no está autorizada por el dominio Return-Path original).
DKIM en Gmail: probablemente pasa (mensaje sin cambios).
DMARC: pasa si DKIM está alineado con From.

Por eso algunos reenvíos “funcionan bien” durante años, hasta que un proveedor cambia selectores DKIM o añades un pie de página. Entonces dejan de funcionar.

Caso 2: El reenviador añade un pie de página/disclaimer

Común en correo corporativo: “Este correo puede ser confidencial…” añadido al final.

SPF: falla (misma razón).
DKIM: falla (cuerpo modificado).
DMARC: falla rotundamente, especialmente si el remitente publica “p=reject”.

Caso 3: La lista de correo destruye DKIM y SPF

Las listas de correo a menudo:

reescriben el Subject (por ejemplo, “[list]”),
modifican el cuerpo (pie, info de baja),
reenvían usando servidores de la lista.

Eso rompe DKIM; SPF no se alineará porque los servidores de lista no están en el SPF del dominio original. DMARC falla a menos que la lista haga mitigaciones (reescritura de From, ARC o volver a firmar con DKIM alineado si es posible).

Caso 4: “Preservar From en cabecera, pero cambiar remitente del sobre”

Esto es lo que hace SRS: reescribe MAIL FROM / Return-Path dejando intacto el From del encabezado.

Resultado:

SPF puede pasar porque el reenviador está autorizado para enviar con su propio dominio SRS.
DMARC aún requiere alineación: la alineación SPF será con el dominio SRS (el reenviador), no con el From original.
Por lo tanto: DMARC solo pasará vía SPF si el MAIL FROM reescrito del reenviador se alinea con el header From (normalmente no), así que la alineación DKIM sigue siendo importante.

Este punto se tuerce en reuniones. SRS evita principalmente el rechazo basado en SPF y reduce problemas de backscatter. No hace que la alineación DMARC con el From original ocurra mágicamente. Hace el reenvío menos roto, no perfectamente limpio.

SRS: la solución que realmente encaja con el problema

SRS (Sender Rewriting Scheme) reescribe el remitente del sobre SMTP para que las comprobaciones SPF se evalúen contra el dominio del reenviador. Eso evita que el mensaje reenviado falle SPF debido a la IP del reenviador. También asegura que los rebotes vuelvan al reenviador para que pueda enrutar los DSN correctamente al remitente original, en lugar de crear backscatter.

Qué cambia concretamente SRS

Antes del reenvío:

MAIL FROM: <alice@sender.example>
From: Alice <alice@sender.example>

Después del reenvío con SRS (ejemplo):

MAIL FROM: <SRS0=hash=timestamp=sender.example=alice@forwarder.example>
From: Alice <alice@sender.example> (sin cambio)

Ahora el sistema receptor evalúa SPF para forwarder.example contra la IP de salida del reenviador, y pasa. Ese es el objetivo.

Por qué sigue valiendo la pena implementar SRS

Porque sin ello, SPF está garantizado a fallar en correo reenviado a menos que el dominio original hiciera algo inusual. El fallo SPF no siempre es fatal para DMARC, pero es una gran parte de la historia de autenticación. Con SRS, al menos dejas de romper SPF de formas totalmente previsibles.

SRS no soluciona la rotura de DKIM

Si tu reenviador modifica mensajes (disclaimers, reescritura de enlaces, escaneo de adjuntos que re-codifica), DKIM seguirá fallando. SRS no puede ayudar. La solución allí es: dejar de modificar correo que no posees, o implementar ARC para preservar las aserciones de autenticación upstream, o reescribir From (lo que cambia la identidad visible por el usuario y es políticamente doloroso).

Dónde debe residir SRS en la arquitectura

SRS debe estar en el límite de reenvío: el punto donde aceptas un mensaje y luego lo envías a otro dominio mientras preservas el From original.

No añadas SRS a todos los caminos de salida de forma indiscriminada. Complica la resolución de problemas y puede confundir el tratamiento de rebotes. Úsalo solo para los flujos de reenvío.

Otras opciones: preservación de DKIM, ARC y “no reenviar”

Opción A: Preservar DKIM no tocando el mensaje

Si puedes reenviar correo sin modificarlo, hazlo. Muchas organizaciones rompen DKIM sin buena razón.

Ejemplos de comportamientos evitables que rompen DKIM:

Añadir disclaimers legales a cada mensaje entrante (no posees el contenido).
Reescribir URLs para seguimiento de clics en correo reenviado (especialmente para remitentes externos).
Convertir estructuras MIME “para normalización”.

Elige ser aburrido. Lo aburrido es fiable.

Opción B: ARC para intermediarios que deben transformar correo

ARC (Authenticated Received Chain) permite a un intermediario registrar los resultados de autenticación que observó al recibir el mensaje y luego firmar ese registro. Un receptor downstream puede decidir confiar en las aserciones ARC del intermediario incluso si DKIM se rompió más tarde.

ARC no es una bala de plata:

Los receptores eligen si confían en tu cadena ARC.
ARC añade complejidad y gestión de claves.
Si tu reenviador se abusa con frecuencia, tu reputación ARC sufrirá.

Usa ARC cuando debas modificar mensajes (listas de correo, pasarelas de seguridad) y tengas la madurez operativa para gestionar claves, monitorizar fallos y mantener tus relés limpios.

Opción C: Reescritura de From (estilo listas de correo)

Las listas de correo suelen reescribir el encabezado From a un dominio que controlan (por ejemplo, “alice vía list.example”). Eso alinea la autenticación con un dominio que la lista puede legítimamente firmar y autorizar.

Técnicamente esto “funciona”. También cambia la identidad visible por el usuario, rompe flujos de respuesta y provoca discusiones políticas con la intensidad normalmente reservada a los planes de asientos en la oficina.

Opción D: Dejar de reenviar; usar acceso delegado correcto

Si la razón empresarial para reenviar es “quiero leer mi correo corporativo en mi cuenta personal”, la solución correcta suele ser el acceso delegado o una configuración de cliente, no el reenvío SMTP.

El reenvío empuja identidad, cumplimiento, retención y respuesta a incidentes a un agujero que no puedes monitorizar. Si eres responsable de sistemas de producción, no construyes puntos ciegos a propósito.

Broma #2: Lo único más persistente que el correo reenviado es la invitación de calendario que lo sigue para siempre.

Guía rápida de diagnóstico

Tienes un informe: “correos reenviados faltan” o “clientes dicen que nunca recibieron el mensaje”. No empieces mirando informes agregados de DMARC por horas. Empieza con un único mensaje que falla y recorre la cadena.

Primero: identifica dónde ocurre la pérdida

¿Fue aceptado por el MTA de entrada del reenviador?
¿Fue retransmitido hacia fuera por el reenviador?
¿Fue rechazado o puesto en cuarentena por el receptor final?

Segundo: revisa resultados de autenticación en el último salto

Resultado SPF (pass/fail/softfail/neutral).
Resultado DKIM (pass/fail, qué dominio d= firmó).
Resultado DMARC (pass/fail, qué identificador se alineó).

Tercero: confirma si el reenviador cambió el contenido

Compara cabeceras y cuerpo antes/después del reenvío si es posible.
Busca disclaimers, etiquetas en el asunto, cambios en los límites MIME.
Comprueba si un dispositivo de seguridad “reescribió enlaces”.

Cuarto: elige la corrección según el fallo

SPF falla, DKIM pasa: puedes desplegar SRS para reducir fragilidad, pero puede que ya estés pasando DMARC vía DKIM. Decide según la frecuencia con que DKIM se rompa en tu entorno.
SPF falla, DKIM falla: necesitas dejar de modificar contenido o implementar ARC o reescribir From. SRS solo no te salvará.
SPF pasa, DMARC falla: problema de alineación—tu dominio autenticado no se alinea con el header From. Corrige la alineación DKIM o ajusta la estrategia de reescritura.

Idea parafraseada (Werner Vogels): “Todo falla; diseña para poder detectarlo rápido y recuperarte automáticamente.” Eso aplica a los flujos de correo más de lo que cualquiera quiere admitir.

Tareas prácticas con comandos, salidas y decisiones

Abajo hay tareas prácticas que puedes ejecutar en un relé de correo Linux típico (ejemplos con Postfix) o desde una estación de administración. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Tarea 1: Confirmar la política DMARC del dominio remitente

cr0x@server:~$ dig +short TXT _dmarc.sender.example
"v=DMARC1; p=reject; rua=mailto:dmarc@sender.example; adkim=s; aspf=s"

Qué significa: El remitente pide a receptores rechazar mensajes que fallen; alineación estricta para DKIM y SPF.

Decisión: Si reenvías correo desde este dominio, debes preservar la alineación DKIM o esperar rechazo. SRS no alineará SPF con sender.example.

Tarea 2: Comprobar el registro SPF del dominio remitente (para entender por qué el reenvío falla)

cr0x@server:~$ dig +short TXT sender.example
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

Qué significa: Solo el rango IP listado y el proveedor están permitidos. Tu reenviador no lo está.

Decisión: Espera fallo SPF tras el reenvío a menos que apliques SRS (o el remitente añada tu reenviador, lo cual no hará).

Tarea 3: Validar que tu dominio reenviador tiene SPF permitiendo sus propias IPs de salida

cr0x@server:~$ dig +short TXT forwarder.example
"v=spf1 ip4:198.51.100.10 -all"

Qué significa: Tu reenviador puede enviar legítimamente correo usando su propio dominio.

Decisión: SRS puede anclarse en forwarder.example porque SPF pasará para la IP de tu relé de salida.

Tarea 4: Inspeccionar los Authentication-Results de un mensaje (del receptor final)

cr0x@server:~$ grep -iE 'authentication-results|dmarc=|spf=|dkim=' message.eml | head -n 8
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of alice@sender.example does not designate 198.51.100.10 as permitted sender) smtp.mailfrom=alice@sender.example;
       dkim=pass header.i=@sender.example header.s=s1 header.b=abc123;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sender.example

Qué significa: SPF falló por la IP de reenvío, pero DKIM pasó y estuvo alineado, así que DMARC pasó.

Decisión: Si tu cadena de reenvío a veces modifica contenido, estás a un disclaimer de tener cortes. Considera SRS y/o eliminar modificaciones.

Tarea 5: Inspeccionar los registros de Postfix por rechazo en el siguiente salto

cr0x@server:~$ sudo grep -E "status=bounced|reject:|dmarc" /var/log/mail.log | tail -n 10
Jan 03 10:22:11 mx postfix/smtp[24190]: 9C2B81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=1.2, delays=0.1/0.0/0.6/0.5, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 This message does not pass authentication checks (SPF and DKIM both fail) 550-5.7.26 and has a DMARC policy of reject. (in reply to end of DATA command))

Qué significa: Receptor final rechazó por fallo DMARC; tanto SPF como DKIM fallaron.

Decisión: SRS por sí solo no arreglará esto si DKIM falla por modificación. Encuentra qué cambió el mensaje o implementa ARC / deja de transformar.

Tarea 6: Confirmar si estás modificando mensajes (cabecera/cuerpo) en tránsito

cr0x@server:~$ sudo postconf -n | egrep 'header_checks|body_checks|milter|content_filter'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
header_checks = regexp:/etc/postfix/header_checks
content_filter = smtp-amavis:[127.0.0.1]:10024

Qué significa: Milters y filtros de contenido están activos; header checks puede reescribir; amavis puede re-codificar.

Decisión: Asume que DKIM fallará a veces. O bien evita el filtrado para correo reenviado, preserva DKIM, o añade ARC y acepta el coste operativo.

Tarea 7: Comprobar si header_checks añaden disclaimers o etiquetas

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/header_checks
/^Subject:/ PREPEND X-Company-Notice: scanned
/^From:/    PREPEND X-Forwarded-By: forwarder.example

Qué significa: Estás modificando cabeceras. La modificación de cabeceras puede invalidar DKIM si la cabecera alterada está firmada.

Decisión: Deja de hacerlo para correo reenviado, o asegúrate de que las cabeceras modificadas no estén en la lista de cabeceras firmadas por DKIM (a menudo no es posible garantizarlo).

Tarea 8: Confirmar que el flujo de reenvío usa un transporte dedicado (para aplicar SRS selectivamente)

cr0x@server:~$ sudo postconf -n | egrep 'transport_maps|sender_dependent_default_transport_maps'
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo postmap -q user@forwarder.example /etc/postfix/transport
forward-srs:

Qué significa: Este destinatario se enruta vía un transporte personalizado llamado forward-srs.

Decisión: Bien. Puedes aplicar SRS solo en ese transporte, en lugar de reescribir todo y crear nuevos misterios.

Tarea 9: Instalar y habilitar soporte SRS (ejemplo: postsrsd)

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y postsrsd
...output...
Setting up postsrsd (1.10-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/postsrsd.service → /lib/systemd/system/postsrsd.service.

Qué significa: postsrsd está instalado y habilitado como servicio del sistema.

Decisión: Procede a configurar Postfix para llamar al daemon SRS, pero solo para los caminos de reenvío si puedes.

Tarea 10: Comprobar que postsrsd está activo y escuchando

cr0x@server:~$ systemctl status postsrsd --no-pager
● postsrsd.service - PostSRSd
     Loaded: loaded (/lib/systemd/system/postsrsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-03 10:12:44 UTC; 8min ago
   Main PID: 1827 (postsrsd)
     Tasks: 1
     Memory: 1.2M
     CGroup: /system.slice/postsrsd.service
             └─1827 /usr/sbin/postsrsd -d -p 10001 -s forwarder.example

Qué significa: El daemon está en ejecución y configurado con el dominio SRS forwarder.example, escuchando en el puerto 10001.

Decisión: Ahora puedes apuntar Postfix sender_canonical_maps o un servicio de limpieza dedicado hacia él.

Tarea 11: Configurar Postfix para usar SRS en la reescritura del remitente del sobre (ejemplo patrón)

cr0x@server:~$ sudo postconf -n | egrep 'sender_canonical_maps|sender_canonical_classes|recipient_canonical_maps'
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:127.0.0.1:10001

Qué significa: Postfix reescribirá el remitente del sobre a través del map TCP (postsrsd) para todo el correo que use sender_canonical_maps.

Decisión: Si esto es demasiado amplio, retrocede y delimítalo: aplícalo mediante un transporte o servicio dedicado, no por defecto global.

Tarea 12: Recargar Postfix y confirmar la saneidad de la configuración

cr0x@server:~$ sudo postfix check
...output...
cr0x@server:~$ sudo systemctl reload postfix
...output...

Qué significa: Postfix aceptó la configuración.

Decisión: Procede a una prueba controlada: reenvía un mensaje firmado desde un dominio con DMARC estricto e inspecciona el Return-Path y los resultados de autenticación resultantes.

Tarea 13: Enviar un mensaje de prueba y confirmar que ocurrió la reescritura SRS

cr0x@server:~$ sudo grep -E "from=<|to=<|srs" /var/log/mail.log | tail -n 20
Jan 03 10:28:01 mx postfix/cleanup[25102]: 1A2B312345: message-id=<test-170428@sender.example>
Jan 03 10:28:01 mx postfix/qmgr[901]: 1A2B312345: from=<SRS0=HHH=TT=sender.example=alice@forwarder.example>, size=18234, nrcpt=1 (queue active)
Jan 03 10:28:02 mx postfix/smtp[25106]: 1A2B312345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, dsn=2.0.0, status=sent (250 2.0.0 OK ...)

Qué significa: El remitente del sobre fue reescrito a SRS0=…@forwarder.example y el mensaje fue aceptado por Gmail.

Decisión: Has reducido la rotura relacionada con SPF. Ahora verifica el resultado DMARC en el receptor; si DKIM falla por modificaciones, SRS no te salvará.

Tarea 14: Verificar que no estás creando condiciones de relay abierto mientras “arreglas el reenvío”

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_recipient_restrictions|mynetworks|smtpd_relay_restrictions'
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Qué significa: El relé está limitado a redes de confianza y usuarios autenticados; destinos no autorizados son pospuestos.

Decisión: Mantén esto así. SRS añade legitimidad a tu correo saliente; no quieres que atacantes tomen prestada esa legitimidad.

Tarea 15: Buscar señales de que DKIM se rompe por aparatos de transformación

cr0x@server:~$ grep -iE 'amavis|altered|footer|disclaimer|repack|mime' /var/log/mail.log | tail -n 15
Jan 03 10:25:33 mx amavis[2201]: (02201-11) Passed CLEAN, but modified headers: added X-Virus-Scanned
Jan 03 10:25:33 mx amavis[2201]: (02201-11) body modified: appended disclaimer

Qué significa: El contenido está siendo cambiado. Las firmas DKIM de remitentes externos probablemente fallarán después de este punto.

Decisión: Para flujos de reenvío, omite las modificaciones o implementa ARC. Si tu equipo de seguridad se niega, sé honesto: parte del correo reenviado será rechazado, y no es un error, es política.

Tarea 16: Verificar que estén presentes cabeceras ARC (si implementas ARC)

cr0x@server:~$ grep -iE '^ARC-Seal:|^ARC-Message-Signature:|^ARC-Authentication-Results:' message.eml | head -n 10
ARC-Authentication-Results: i=1; mx.forwarder.example; spf=pass smtp.mailfrom=alice@sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...

Qué significa: El reenviador está afirmando lo que vio en el momento de la recepción y firmando esa aserción.

Decisión: Confirma si los receptores downstream que te importan realmente usan las señales ARC. Si no, ARC puede no mejorar la entregabilidad lo suficiente para justificar la complejidad.

Tres mini-historias corporativas (dolor, arrepentimiento y una victoria)

Mini-historia 1: El incidente causado por una suposición errónea

La empresa tenía una regla “simple” de reenvío: todo el correo a acquisitions@corp.example se reenviaba a una dirección del equipo de negociación alojada en otro proveedor. Había funcionado durante años. Todos asumían que estaba bien porque no había tickets.

Entonces un socio importante mejoró su postura de autenticación: DMARC pasó de p=none a p=reject con alineación estricta. El reenviador seguía relayando el correo exactamente como antes. SPF fallaba en el nuevo proveedor (como siempre). DKIM lo habría salvado—excepto que la pasarela corporativa añadió un disclaimer de cumplimiento a todo el correo saliente, incluido el reenviado. DKIM se rompió.

El primer síntoma no fue un rebote. Fue el silencio. El equipo de compras del socio creyó que la empresa los estaba ignorando. La gente interna culpó “al filtro de spam del proveedor”, luego “a nuestro proveedor”, luego se culparon entre ellos, que es el orden tradicional de operaciones.

La solución fue humillante: deshabilitar la inyección de disclaimers para el transporte de reenvío, desplegar SRS para reescritura del remitente del sobre y añadir una regla: cualquier cosa que reenvíe externamente no debe mutarse a menos que el negocio acepte el riesgo. No hubo un “interruptor mágico de DMARC”. Solo decisiones específicas de fontanería.

Mini-historia 2: La optimización que salió mal

Otra organización quería reducir latencia y dependencias externas. Consolidaron varios MTAs pequeños en un “relay inteligente” que realizaba escaneo antivirus, etiquetado DLP, reescritura de URL y normalización de cabeceras. Era una caja elegante: menos sistemas, menos alertas, un panel que parecía confiado.

Luego activaron la reescritura agresiva de URLs por protección contra amenazas. Eso cambió rutinariamente los cuerpos de mensaje. Las firmas DKIM de remitentes externos empezaron a fallar. La mayoría de las entregas directas sobrevivieron porque SPF se alineaba y pasaba. Los mensajes reenviados no: SPF fallaba después del reenvío, DKIM fallaba por la reescritura, DMARC fallaba y remitentes estrictos eran rechazados.

La optimización “funcionó” según sus métricas—menos servidores, menos partes móviles—mientras degradaba silenciosamente la entregabilidad para un conjunto específico de flujos críticos para el negocio: correo reenviado, notificaciones de sistemas de tickets a cuentas personales y algunos feeds de proveedores externos.

Recuperaron terreno construyendo un carril de omisión: mensajes identificados como reenvíos puros (basado en enrutamiento y clase de destinatario) evitaban la modificación de cuerpos y la reescritura de URLs. Seguridad no estaba encantada, pero lo aceptaron tras ver que la alternativa era la no entrega sin recurso para el usuario. El mejor control de seguridad es el que permite que el negocio funcione.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros tenía una regla: cualquier cambio en el manejo de correo debía probarse con un conjunto conocido de dominios externos que publican políticas DMARC estrictas. Mantenían un pequeño corpus de mensajes de prueba (firmados con DKIM, con varios tipos MIME) y los pasaban por sus relés antes y después de los cambios.

Un día actualizaron un paquete milter. Las notas de la versión eran vagas pero el cambio parecía menor. Su suite de pruebas antes del cambio mostró inmediatamente fallos DKIM en mensajes reenviados; el milter había empezado a reenvolver líneas largas y normalizar espacios en blanco. SPF ya fallaba en correo reenviado, así que DMARC ahora fallaba también.

Como lo detectaron antes del despliegue en producción, tuvieron opciones: fijar la versión del milter, ajustar la configuración para evitar cambios de canonicalización y aplicar SRS donde fuera necesario. Sin incidente. Sin escalada ejecutiva. Sin “el correo está caído” en el chat.

La práctica era aburrida: un arnés de pruebas, una lista de verificación y un poco de paranoia. Les salvó de aprender la lección en público.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: El correo reenviado desaparece, sin rebote

Causa raíz: El receptor final pone en cuarentena o rechaza silenciosamente basado en DMARC; los rebotes pueden ir a Return-Path reescrito o inválido, o se suprimen.

Solución: Inspecciona los registros de Postfix por DSN 5.7.26/5.7.1. Añade un buzón monitorizado para rebotes y asegúrate de que SRS está configurado para que los DSN vuelvan a ti. Si DKIM se está modificando, deja de modificar o adopta ARC.

2) Síntoma: SPF falla en cada mensaje reenviado

Causa raíz: Comportamiento normal. La IP del reenviador no está autorizada por el SPF del remitente original.

Solución: Implementa SRS en el límite del reenviador. No pidas a terceros que añadan tus IPs al SPF; así no funciona el mundo.

3) Síntoma: DKIM falla solo después de habilitar “disclaimer legal”

Causa raíz: La inyección de pie de página modifica el cuerpo; la firma DKIM ya no coincide.

Solución: Deshabilita la inyección de pie de página para correo reenviado y correo de listas, o aplícala solo al correo que origines. Si debes añadir avisos, hazlo en la capa de cliente/UI, no en la carga SMTP.

4) Síntoma: DMARC falla aunque SPF pasa

Causa raíz: SPF pasa para un dominio que no se alinea con el header From (por ejemplo, usando un dominio de rebote o dominio de un relay tercero).

Solución: Asegura que el dominio usado para la autenticación SPF se alinee con el header From (alineación organizacional relajada/estricta depende de la política del remitente). Si no, confía en DKIM alineado.

5) Síntoma: Algunos proveedores aceptan correo reenviado, otros lo rechazan

Causa raíz: Los receptores ponderan DKIM/SPF/ARC de forma distinta; algunos aplican DMARC más estricto o tienen políticas anti-abuso locales.

Solución: Diseña para receptores estrictos: preserva DKIM, evita transformaciones y despliega SRS. Trata “funciona en el Proveedor A” como anécdota, no como validación.

6) Síntoma: Tormentas de rebotes o backscatter tras reenvío

Causa raíz: El reenviador mantiene MAIL FROM original, así los DSN van al remitente original incluso cuando el reenviador causó el problema, o a remitentes falsificados cuando se trata de spam.

Solución: SRS. También asegúrate de rechazar correo no autenticado en tiempo SMTP cuando sea posible para evitar generar DSN por basura.

7) Síntoma: ARC añadido, pero nada mejoró

Causa raíz: Los receptores no confían en tu cadena ARC (reputación), o no estás sellando correctamente, o tus modificaciones son demasiado extremas.

Solución: Valida firmas ARC, mantiene tus relés limpios y no asumas que ARC es universalmente respetado. Si puedes evitar modificaciones, haz eso en su lugar.

Listas de verificación / plan paso a paso

Plan A: Gestionas un reenviador y quieres que el reenvío “funcione mayormente”

Inventario de rutas de reenvío. Lista todas las reglas, alias y reenvíos a nivel de buzón que envían externamente.
Separa el tráfico de reenvío. Usa un transporte Postfix dedicado o una instancia separada para reenvíos.
Despliega SRS en ese camino. Asegura que tu dominio de reenvío tiene SPF autorizando las IPs de envío.
Deja de modificar el correo reenviado. No footers, no etiquetas de asunto, no reescritura de URLs. Si seguridad necesita escaneo, hazlo de forma que preserve los bytes del mensaje.
Prueba con dominios DMARC estrictos. Usa un conjunto repetible de mensajes de prueba y valida Authentication-Results en los receptores finales.
Monitoriza rechazos por códigos DSN. Alerta sobre picos en 5.7.26, 5.7.1 y “DMARC policy of reject”.
Mantén un rollback. SRS y filtros tocan comportamiento central del correo. Hazlo reversible sin heroísmos.

Plan B: Operas una lista de correo o pasarela que debe modificar mensajes

Decide la estrategia de identidad. O reescribes From (funciona pero es visible para usuarios) o inviertes en ARC y esperas que los receptores confíen en ti.
Si usas ARC: gestiona claves, rota de forma segura, monitoriza validación. Trátalo como operaciones de certificados TLS: aburrido, programado, documentado.
Minimiza modificaciones igualmente. Cada transformación es un boleto de lotería para romper DKIM.
Proporciona orientación a usuarios. Para dominios estrictos, explica que la suscripción directa o la inclusión en listas blancas puede ser necesaria.

Plan C: Eres equipo de TI corporativo y la gente quiere reenviar correo a cuentas personales

No lo hagas por defecto. El reenvío es exfiltración más riesgo de entregabilidad disfrazado de conveniencia.
Ofrece alternativas soportadas. Gestión de dispositivos móviles, acceso delegado, webmail seguro o configuraciones de cliente gestionadas.
Si debes permitirlo: exige MFA, aplica SRS y prohíbe la modificación de mensajes en ese carril de reenvío.
Hazlo visible. Registra y audita reglas de reenvío externas. Trátalas como controles de salida de datos, porque eso es lo que son.

Preguntas frecuentes (FAQ)

1) ¿SRS “arregla DMARC” para correo reenviado?

No. SRS arregla la supervivencia de SPF durante el reenvío reescribiendo el remitente del sobre. DMARC aún puede fallar si DKIM falla y la alineación SPF no coincide con el From visible.

2) Si DKIM pasa, ¿aún necesito SRS?

A menudo sí, para resiliencia y manejo de rebotes. DKIM puede ser frágil cuando el correo se modifica por pasarelas. SRS además reduce backscatter y hace tu comportamiento de reenvío más conforme a estándares.

3) ¿Por qué el remitente original no puede “permitir” mi reenviador en SPF?

Porque SPF es un mecanismo de autorización publicado para los remitentes legítimos de un dominio. Añadir reenviadores aleatorios sería operativamente imposible y aumenta la superficie de abuso.

4) ¿Qué pasa con el reenvío dentro del mismo proveedor?

Depende. Algunos proveedores implementan reenvío interno que preserva el contexto de autenticación, a veces usando mecanismos propietarios. Pero una vez que cruzas límites administrativos y nuevas IPs de salida, SPF morderá.

5) ¿Puedo volver a firmar DKIM en el reenviador para que DMARC pase?

Puedes firmar con tu propio dominio, pero eso no se alineará con el From original a menos que también reescribas From. Re-firmar puede ayudar a los receptores a evaluar integridad, pero no soluciona la alineación por sí solo.

6) ¿Está ARC ampliamente soportado?

Lo soportan los principales proveedores de buzones en distintos grados, pero no lo bastante consistente como para considerarlo garantizado. ARC se ve mejor como una señal que ayuda a algunos receptores en ciertos casos.

7) ¿Cuál es el mayor riesgo operativo de SRS?

Escoparlo mal. Si reescribes remitentes del sobre para correo que no debería reescribirse, puedes romper el procesamiento de rebotes y complicar la resolución de problemas. Aplícalo en caminos de reenvío.

8) ¿Cómo sé si mi sistema está rompiendo DKIM?

Busca transformaciones: disclaimers, reescritura de URLs, normalización MIME, etiquetas en el asunto. Luego confirma comparando Authentication-Results en la recepción vs después del relay, o observando DKIM=fail downstream.

9) Si dejo de modificar correo, ¿el reenvío siempre funcionará?

No siempre. DKIM puede estar ausente, mal configurado o usar una canonicalización frágil. Pero dejar de modificar elimina un modo de fallo auto-infligido importante y mejora significativamente las probabilidades.

10) ¿Qué le digo al negocio cuando el correo reenviado de remitentes estrictos aún falla?

Diles la verdad: las políticas modernas anti-suplantación tratan el reenvío como riesgoso a menos que preserves DKIM o uses mitigaciones soportadas. Ofrece alternativas al reenvío para flujos críticos.

Próximos pasos que puedes hacer esta semana

Si gestionas reenvío en producción, trátalo como cualquier otra superficie de fiabilidad: mídelo, aíslalo y deja de hacer “pequeños cambios inocuos” en la carga del mensaje.

Elige un mensaje que falla y trázalo de extremo a extremo. Confirma si SPF, DKIM o la alineación es el fallo real.
Elimina la mutación de contenido en los flujos reenviados. Los disclaimers en el correo de otra persona no son una ganancia de cumplimiento; son una deuda de entregabilidad.
Despliega SRS en el límite de reenvío para prevenir fallos SPF previsibles y domesticar el comportamiento de rebotes.
Decide si ARC vale la pena para flujos que deben transformar correo. Si puedes evitar la transformación, hazlo.
Escribe tu política: qué reenvíos se soportan, cuáles están prohibidos y qué deben hacer los usuarios en su lugar.

El reenvío no empeoró; el ecosistema se volvió menos tolerante con la identidad ambigua. Eso es progreso. Solo significa que la fontanería ahora necesita ingeniería real.