El reenvío de correo es probablemente una de las primeras funciones que configuras al tener un dominio. Y con frecuencia también es la primera que deja de funcionar sin avisar.
A primera vista parece trivial: tomar el correo enviado a info@yourdomain.com y redirigirlo a tu cuenta @gmail.com. En la práctica, el reenvío es una operación de intermediación que entra en conflicto directo con los principales modelos de confianza de Internet moderno: SPF, DKIM y DMARC. Si se configura mal, el correo no rebota con un error llamativo. Simplemente desaparece.
Para quien funda una empresa, un reenvío averiado puede significar perder mensajes de inversores. Para un MSP que administra 50 dominios de clientes, puede provocar una avalancha de solicitudes de soporte un lunes por la mañana.
Esta guía explica cómo funciona realmente el reenvío de correo en el nivel de protocolo, por qué falla de maneras previsibles y cómo crear una configuración capaz de convivir con políticas DMARC estrictas en 2026.
El modelo mental: por qué el reenvío de correo es más complejo de lo que parece
Antes de corregir un reenvío averiado, debes entender qué sucede en la capa SMTP. No se trata de pasar una nota, sino de volver a enviar una carta, y esa distinción es fundamental.
Cuando el servidor A envía un correo a tu servidor (el servidor B, que actúa como reenviador) y el servidor B lo retransmite al destino final (el servidor C), se produce un cambio de identidad crucial. El servidor de destino ve la dirección IP del servidor B, no la del servidor A. Esa es la causa de casi todos los fallos de reenvío.
Sobre SMTP y cabecera: las dos identidades de un correo
Cada correo tiene dos capas de identidad independientes, y el reenvío las desincroniza:
- El sobre (P1): lo que utilizan los servidores para enrutar físicamente el mensaje. Contiene el
Return-Path. SPF valida esta capa. - La cabecera (P2): lo que el cliente de correo muestra como dirección «De». Las comprobaciones de alineación de DKIM y DMARC utilizan esta capa.
Esto es lo que falla. Cuando tu servidor reenvía un mensaje, abre una conexión SMTP nueva con el destino. SPF comprueba la IP emisora frente al registro SPF del remitente original, pero la IP del reenviador no está autorizada allí. SPF falla. Si el remitente original aplica una política DMARC estricta (p=reject) y no has implementado SRS, el servidor de destino rechaza directamente el mensaje.
Una analogía concreta: Alicia envía una carta a Roberto. Roberto mete la carta de Alicia en un sobre nuevo con su propia dirección de remitente y la envía a Carolina. Carolina consulta con Alicia si la mandó desde la dirección de Roberto. Alicia responde que no. Eso es un fallo de DMARC, y el servidor de correo de Carolina actúa en consecuencia.
Comprender esta separación entre sobre y cabecera es la base. Todas las soluciones de esta guía parten de ella.
Reenvío de correo, alias y catch-all: conoce la diferencia
Los operadores confunden constantemente estos tres métodos de enrutamiento. Elegir el incorrecto es la vía más rápida hacia una incidencia de «correo perdido» que lleva tres horas diagnosticar.
Reenvío de correo
Toma un correo enviado a una dirección y lo entrega a un servidor completamente distinto, por ejemplo, contact@startup.com → founder@gmail.com. Hay un salto de red. Las cadenas de autenticación se rompen si no se gestionan de forma explícita. Es idóneo para consolidar varios dominios en una bandeja de entrada. Riesgo: alto sin una gestión adecuada de SRS/ARC. Consulta nuestro análisis detallado sobre las ventajas y desventajas de combinar alias y reenvío.
Alias de correo
Es otro nombre para un buzón existente en el mismo servidor. support@company.com entrega en el mismo buzón que admin@company.com, sin salto de red ni cambio de autenticación. Es idóneo cuando una persona desempeña varias funciones. Riesgo: bajo. Para comparar con más detalle cuándo dejan de ser suficientes los alias y cuándo hace falta un buzón completo, consulta nuestra guía para decidir entre alias y buzón.
Catch-all (enrutamiento comodín)
Acepta cualquier correo enviado a una dirección inexistente de tu dominio, *@domain.com. Resulta útil para capturar errores tipográficos o direcciones de campañas puntuales. Riesgo: crítico si apunta directamente a Gmail. Todo el spam dirigido a tu dominio llegará a tu bandeja y, con el tiempo, Gmail puede tratar tu servidor de reenvío como una fuente de spam. Si usas catch-all, aíslalo. Abordamos todas las ventajas y desventajas en nuestra guía para configurar el correo empresarial.
| Método | ¿Salto de red? | Riesgo de autenticación | Uso recomendado |
|---|---|---|---|
| Reenvío | Sí | Alto (se rompen SPF/DMARC) | Enrutamiento entre dominios o proveedores |
| Alias | No | Ninguno | Varias funciones, mismo buzón |
| Catch-all | Depende de la configuración | Crítico (atrae spam) | Capturar errores y direcciones desechables |
Patrones de configuración: el bueno, el malo y el que no funciona
Hay tres formas de configurar el reenvío de correo. Dos pueden darte problemas. Una suele funcionar de manera fiable en producción.
1. Enrutamiento del lado del proveedor (la forma correcta)
Se realiza en el nivel del MTA antes de que el mensaje llegue a un buzón. El servidor recibe el correo, reescribe el sobre mediante SRS y lo retransmite de inmediato. No requiere una licencia de buzón de pago. No consume almacenamiento. SPF y ARC se gestionan en la capa de infraestructura.
Este es el enfoque sobre el que conviene construir. Las rutas de reenvío de TrekMail funcionan así: defines el destino y la infraestructura gestiona las cabeceras de autenticación. Consulta la guía para configurar el reenvío de buzones para conocer los pasos exactos.
2. Reglas de buzón (la forma antigua)
Creas una cuenta de usuario completa, pagando $6-$30/month por una licencia que en realidad no necesitas, inicias sesión y añades una regla de bandeja de entrada: «Si llega un mensaje, reenviarlo a X».
Hay casos límite en los que tiene sentido: reenvío condicional («reenviar solo facturas»), requisitos de auditoría o situaciones en las que necesitas almacenar el mensaje localmente antes de retransmitirlo. Pero en la mayoría de las configuraciones pagas un puesto solo para enrutar correo. También rompe DMARC igual que cualquier otro reenvío, y Microsoft 365 bloquea el reenvío automático de forma predeterminada (más información en la sección sobre modos de fallo).
3. Reenvío del lado del cliente (evítalo por completo)
Es una regla configurada en Outlook Desktop o Apple Mail en tu equipo local. El portátil debe estar encendido, activo y conectado a Internet para que se produzca el reenvío. No funciona mientras viajas. No funciona durante un reinicio. No funciona a las 2am cuando llega el correo importante.
No hay un escenario de producción en el que sea la opción correcta. Si dependes actualmente de este método, conviene corregirlo cuanto antes.
Lista de comprobación para una configuración segura
Antes de activar una ruta de reenvío, realiza estas cuatro comprobaciones. Omitir cualquiera de ellas puede causarte problemas más adelante.
1. Prueba de bucle
Confirma que la dirección de destino no reenvíe de vuelta a la de origen. A→B→A es un bucle infinito. Los servidores modernos lo detectan mediante límites de saltos y devuelven un NDR 5.4.14 hop count exceeded, pero para entonces ya puedes haber perjudicado la reputación de envío. Traza tus rutas antes de activarlas.
2. Prueba de inspección de cabeceras
Envía una prueba desde una cuenta externa (Gmail personal, Yahoo o cualquier servicio ajeno a tu dominio) a la dirección reenviada. En el destino, abre las cabeceras completas y busca Authentication-Results. Lo deseable es ver spf=pass (gracias a la reescritura SRS) o dkim=pass. Si aparece dmarc=fail, la configuración de reenvío aún no está lista para producción.
3. Prueba de Reply-To
Responde a un mensaje reenviado. ¿La respuesta va al remitente original o a la dirección del reenviador? Debe ir al remitente original. Si va al reenviador, la configuración del sobre es incorrecta y generará un historial de conversación confuso para todos los implicados.
4. Comprobación de la política de salida
Si utilizas Microsoft 365 o Google Workspace como destino de retransmisión, comprueba que el reenvío automático esté permitido en la configuración del filtro de spam saliente. M365 lo bloquea de forma predeterminada. Si no se configura correctamente, los reenvíos pueden descartarse sin notificar al remitente original.
Modos de fallo habituales
Cuando falla el reenvío de correo, casi siempre lo hace de una de estas maneras concretas. Reconocer el patrón evita una hora de revisar cabeceras sin rumbo.
1. Descarte silencioso por DMARC
Es una de las causas más habituales de desaparición de correo en 2026 y no deja señales visibles: ni NDR, ni error, ni aviso. El mensaje simplemente no llega.
El escenario: un banco, un procesador de pagos o un proveedor SaaS envía correo con una política DMARC estricta p=reject a tu dominio. Lo reenvías a Gmail. La IP del reenviador rompe SPF. Si tu servidor también modifica el cuerpo (añadiendo un aviso) o el asunto (añadiendo [External]), también rompe DKIM. Fallo de SPF + fallo de DKIM = fallo de DMARC. Gmail lo rechaza.
La solución consiste en implementar SRS en el servidor de reenvío para que SPF pase y evitar modificaciones de contenido para conservar DKIM. Si no controlas la infraestructura, necesitas un proveedor de reenvío que se encargue de ello. Para profundizar en cómo se producen los fallos de DMARC específicamente en las cadenas de reenvío, consulta nuestro análisis de DMARC y correo seguro.
2. Bloqueo 550 5.7.520 de Microsoft
Síntoma: el remitente original recibe un NDR con el código 550 5.7.520 Access denied, your organization does not allow external forwarding.
Es el filtro de spam saliente de M365 haciendo precisamente aquello para lo que fue diseñado: bloquear el reenvío automático a direcciones externas. Para corregirlo, hay que ir al portal de Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → establecer «Automatic forwarding rules» en «On: forwarding is enabled».
No es intuitivo y Microsoft lo sitúa en una ruta poco evidente. Sin embargo, ese código de error ofrece un diagnóstico preciso: cuando lo ves, sabes exactamente dónde acudir.
3. Bucle de respuesta automática
El usuario A reenvía al usuario B. El usuario B configura una respuesta automática. El usuario A escribe al usuario B. La respuesta automática de B vuelve a A. El servidor de A reenvía esa respuesta a B. El servidor de B vuelve a responder.
Los servidores modernos utilizan cabeceras como X-Loop y X-Auto-Response-Suppress para detectar y detener esta situación. Las configuraciones antiguas o incorrectas todavía pueden generar miles de mensajes en pocos minutos. Revisa las respuestas automáticas al configurar reenvíos entre cuentas.
4. Ruptura de DKIM por modificación
DKIM firma un hash criptográfico del contenido del mensaje. En cuanto cambia algo en la parte firmada, incluso al añadir un pie de una línea, la firma deja de ser válida. Muchos sistemas corporativos agregan avisos legales a todos los mensajes salientes. Si el aviso se añade después de crear la firma DKIM, esta será inválida en el destino.
Si ves dkim=fail (body hash did not verify) en las cabeceras de un mensaje reenviado, esta suele ser la causa.
Flujo de diagnóstico: síntoma → solución
| Síntoma | Causa probable | Paso de diagnóstico |
|---|---|---|
El remitente recibe un NDR 5.7.1 |
SPF / retransmisión denegada | Comprueba si la IP del reenviador está en una lista de bloqueo. Verifica la autenticación SPF en las cabeceras. |
El remitente recibe un NDR 5.4.14 |
Bucle de enrutamiento | Audita todas las reglas de reenvío para detectar rutas circulares (A → B → A). |
| No hay correo ni NDR (descarte silencioso) | Rechazo DMARC / filtro de spam | Revisa la carpeta de spam o correo no deseado del destino. Inspecciona las cabeceras en busca de dmarc=fail. |
550 5.7.520 Access denied |
Bloqueo de la política saliente de M365 | Edita la política de spam saliente de M365 Defender: habilita el reenvío automático. |
| El correo llega, pero se ve dañado | Fallo del hash del cuerpo DKIM | Busca dkim=fail (body hash did not verify) en las cabeceras. Desactiva la inserción de pies de página o avisos. |
| La respuesta va al reenviador, no al remitente original | Configuración incorrecta de Reply-To / sobre | Verifica que el reenvío conserve la cabecera Reply-To del remitente original. |
Por qué falla el reenvío en producción (explicación de SRS y ARC)
Las reglas de reenvío simples no bastan para un entorno de producción. Necesitas una infraestructura que entienda SRS y ARC. Veamos exactamente qué hace cada mecanismo y por qué ambos son importantes.
SRS: Sender Rewriting Scheme
SRS corrige el fallo de SPF causado por el salto de red. Tu servidor de reenvío reescribe la dirección del remitente del sobre para que el destino pueda validar SPF frente a tu dominio en lugar del dominio del remitente original.
Antes de SRS:
MAIL FROM: alice@bank.comDespués de la reescritura SRS:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comEl servidor de destino ejecuta SPF para forwarder.com, que pasa porque tu servidor está autorizado. Los mensajes de rebote siguen volviendo a alice@bank.com mediante la dirección codificada. SPF se satisface sin romper la ruta de rebote.
SRS es esencial. Sin él, todos los mensajes reenviados cuyo remitente aplique un SPF estricto fallarán la autenticación en el destino. Para entender por completo cómo funciona SRS en las cadenas de reenvío, consulta nuestra guía detallada para configurar correo con tu dominio. Si vas a enrutar específicamente a una bandeja de Gmail, consulta nuestra guía paso a paso para reenviar correo de dominio a Gmail de forma segura con SRS y «Enviar como» configurados.
ARC: Authenticated Received Chain
SRS corrige SPF, pero no resuelve por completo la alineación DMARC. Ahí interviene ARC. ARC permite que el servidor de reenvío firme criptográficamente el mensaje con un sello que declara: «Verifiqué la autenticación de este mensaje al recibirlo y era válida».
Google y Microsoft reconocen los sellos ARC de servidores intermedios de confianza. Cuando hay un sello ARC fiable, estos proveedores pueden aceptar el mensaje aunque las comprobaciones originales de SPF/DMARC fallen por el salto del reenvío. En esencia, constituye un registro de cadena de custodia para la autenticación del correo.
ARC se define en RFC 8617 y es el estándar actual para conservar la autenticación en escenarios legítimos de reenvío. Sin ARC, una política DMARC estricta p=reject del remitente original puede hacer que los grandes proveedores descarten los mensajes reenviados, incluso con SRS implementado.
La zona de peligro del catch-all
El reenvío se combina a menudo con una configuración catch-all, y esa combinación merece una advertencia específica. Si apuntas un comodín catch-all a Gmail, cada mensaje de spam dirigido a direcciones aleatorias de tu dominio acaba en Gmail, y Gmail ve tu servidor de reenvío como origen. Puedes acumular rápidamente quejas de spam contra tu IP, perjudicando también la reputación de envío del correo legítimo del dominio.
Si necesitas catch-all, aíslalo en un buzón dedicado con filtrado de spam en el servidor, no en un reenvío a una bandeja personal. El patrón de configuración completo se explica en nuestra guía para configurar el correo en tu dominio.
Qué papel desempeña TrekMail
El método tradicional para gestionar el reenvío exigía crear tu propio MTA con compatibilidad con SRS y ARC, o pagar licencias por usuario solo para enrutar correo. Ninguna opción resultaba práctica para operadores que administraban más de unos pocos dominios.
Pagar a Google o Microsoft $6/user/month, necesitar 10 direcciones de reenvío y quizá pagar por 10 puestos que no utilizas, o alcanzar los límites de alias y empezar a encadenar soluciones provisionales. Es un impuesto sobre el enrutamiento.
El enfoque de TrekMail es un alojamiento con tarifa plana. Pagas un plan, no puestos. Las rutas de reenvío, los alias y la configuración catch-all están incluidos y se gestionan en el servidor, con reenvío compatible con SRS integrado en la infraestructura. Tú defines la ruta; la plataforma gestiona las cabeceras de autenticación, la aplicación de TLS y la entrega. Sin tarifas por dirección ni necesidad de lidiar con políticas de spam saliente para acceder a funciones básicas.
Para una persona que emprende en solitario, eso significa enrutar hello@yourdomain.com a Gmail de forma fiable en menos de cinco minutos, sin configurar un servidor completo. Para un equipo, significa gestionar cada cambio de ruta desde el panel, sin arqueología de DNS. Para una agencia que administra 100+ dominios de clientes, significa gestionar las reglas de forma centralizada y coherente, evitando fallos de autenticación que terminan en incidencias de soporte a las 6pm de un viernes.
El plan Pro ($10/month, o $8/month con pago anual) incluye catch-all externo y reenvío de buzones. El plan Agency ($29/month) admite 1,000+ dominios y ofrece acceso a la API para gestionar rutas en bloque. Todos los planes de pago incluyen una prueba gratuita de 14-day (requiere tarjeta).
Descubre cómo gestiona TrekMail el reenvío a cualquier escala en trekmail.net.
Conclusión
El reenvío de correo no es una función que se configura una vez y se olvida. Es una operación activa de enrutamiento que interactúa con los principales modelos de autenticación de Internet. Los fallos son previsibles: SPF se rompe al cambiar la IP, DKIM al modificar el contenido y DMARC rechaza cuando falla la alineación. Todos pueden corregirse al comprender lo que ocurre en la capa de protocolo.
Conclusiones prácticas: usa reenvío en el servidor con SRS y ARC, nunca reglas en el cliente. Prueba las cabeceras antes de activar el servicio. Presta atención al bloqueo de la política saliente de M365. Mantén aislado el catch-all. Y si gestionas reenvíos en varios dominios, evita pagar por puesto solo para enrutar correo.
Con una infraestructura subyacente correcta, el reenvío puede funcionar de forma fiable. Con una configuración incorrecta, los mensajes más importantes pueden desaparecer sin dejar rastro. La elección no es complicada.
