Reenviar correo de tu dominio a Gmail: guía práctica

Configuras contact@yourdomain.com para reenviar el correo del dominio a Gmail. Un cliente envía un contrato y un banco, una alerta de seguridad. Ningún mensaje aparece.

Revisas spam y no encuentras nada. En este escenario, los mensajes faltan sin que tú veas un error o aviso; el remitente puede haber recibido una notificación aunque tú no la recibas.

Puede ser un problema de autenticación, no un capricho de Gmail. Al reenviar el correo de tu dominio a Gmail, tu servidor transmite desde su IP un mensaje de otro dominio. Si se conserva el remitente original del sobre y su SPF no autoriza esa IP, SPF falla. Si el remitente publica DMARC estricto (p=reject) y tampoco pasa un DKIM alineado, Gmail puede rechazarlo con un error como 550-5.7.26. Un rechazo SMTP puede generar un rebote al remitente; no implica necesariamente borrado silencioso sin avisos para nadie.

SRS (Sender Rewriting Scheme) reescribe el remitente del sobre y ARC (Authenticated Received Chain) conserva resultados de autenticación firmados. Estos mecanismos pueden ayudar al reenvío, pero no garantizan entrega ni son ambos imprescindibles en todos los casos: un DKIM válido y alineado que sobreviva puede permitir que DMARC pase.

Esta guía aborda la reescritura SRS, la prevención de bucles y «Enviar como» en Gmail. Para entender cómo interactúan SPF, DKIM y DMARC y cómo funciona SRS, consulta la guía completa de configuración y solución de problemas del reenvío de correo.

Por qué Gmail puede rechazar el correo reenviado

El SPF original puede fallar porque la IP del servidor de reenvío no figura entre las autorizadas por el dominio del remitente del sobre. SRS permite evaluar SPF con el dominio del reenviador, siempre que este autorice el servidor. No garantiza la alineación DMARC con el From: original: DKIM, ARC, los filtros y la política receptora también importan.

Un posible fallo cuando un mensaje de client@bank.com se reenvía a you@gmail.com:

1. bank.com entrega el mensaje a tu servidor de reenvío
2. Tu servidor lo transmite a Gmail
3. Gmail comprueba SPF con el remitente del sobre conservado: client@bank.com
4. El SPF de bank.com no autoriza la IP de tu servidor: SPF FAIL
5. La política DMARC es p=reject y no pasa un DKIM alineado: Gmail puede devolver 550-5.7.26
6. El mensaje se rechaza; tú puedes no recibir aviso, aunque el remitente puede recibir un rebote. La retención depende del servidor.

DKIM puede sobrevivir al reenvío si no se modifica lo que cubre la firma. Evita pies añadidos y cambios del asunto firmado. Un DKIM válido y alineado puede permitir que DMARC pase incluso con SPF fallido. El parámetro aspf=s afecta solo a la alineación SPF, no a DKIM. Modificar contenido firmado puede invalidar DKIM, pero no todo cambio lo hace. Revisa ambos mecanismos; SRS no es una solución garantizada para DMARC.

Tres formas de reenviar el correo de tu dominio a Gmail

No todas las configuraciones presentan el mismo riesgo. Elige una arquitectura adecuada para tu uso antes de activar el reenvío.

El catch-all puede perjudicar la entregabilidad. Los emisores de spam prueban direcciones como abc123@yourdomain.com y junk@yourdomain.com. Si el servidor acepta y reenvía esos mensajes, transmite también spam. El 90% citado en la fuente es un ejemplo ilustrativo, no un umbral de bloqueo de Gmail. La IP puede perder reputación y el correo legítimo acabar en spam; la recuperación no tiene un plazo fijo.

Para conocer los compromisos del reenvío, consulta las ventajas y riesgos del reenvío de alias. Si eliges entre un alias y un buzón dedicado, la comparación de alias de correo con dominio y buzones explica los criterios.

SRS: por qué conviene evaluarlo al reenviar correo a Gmail

SRS ayuda a tratar el fallo SPF del salto de reenvío. Cambia el remitente del sobre, reflejado en Return-Path y utilizado para los rebotes, del dominio original al del reenviador. Gmail puede validar SPF contra ese dominio si el servidor está autorizado. Esto no garantiza DMARC ni la entrega; no es una obligación universal para todo reenvío.

Sin SRS, escenario con fallo:
Remitente del sobre: client@bank.com
IP emisora: 203.0.113.10 (servidor de reenvío del ejemplo)
SPF: registro de bank.com → FAIL (203.0.113.10 no está autorizado)
DMARC: FAIL si tampoco pasa DKIM alineado (p=reject) → posible rechazo, no borrado inevitable

Con SRS, SPF corregido en el ejemplo:
Remitente del sobre: SRS0=HASH=TT=bank.com=client@yourdomain.com
IP emisora: 203.0.113.10 (servidor de reenvío del ejemplo)
SPF: registro de yourdomain.com → PASS (203.0.113.10 está autorizado)
From: de la cabecera: client@bank.com (sin cambios; se conserva el remitente visible original)

El SPF del dominio utilizado por SRS debe autorizar la IP o el servicio emisor mediante los mecanismos adecuados. Si no lo hace, la reescritura no basta: SPF puede fallar aunque el nuevo remitente pertenezca a tu dominio.

Una infraestructura de reenvío también puede añadir ARC (Authenticated Received Chain). ARC registra resultados de autenticación mediante una cadena firmada. Gmail puede considerar esos resultados según su confianza en el reenviador y sus políticas. Requiere una configuración de firma ARC válida, no simplemente añadir una firma DKIM ordinaria. Lo gestiona el operador del servidor; consulta la compatibilidad del proveedor si no lo administras tú.

SPF se define en RFC 7208. ARC, que documenta resultados de autenticación a lo largo de varios saltos, se define en RFC 8617.

Prevención de bucles: cuatro comprobaciones antes de activar el servicio

Los bucles pueden causar errores como 5.4.14 Hop count exceeded e impedir la entrega. Antes de usar el reenvío en producción, realiza estas comprobaciones.

1. Evita rutas circulares. Comprueba que you@gmail.com no tenga un filtro que devuelva el correo a you@yourdomain.com y de nuevo a Gmail. Esa ruta puede crear un bucle hasta que intervengan los límites del servidor.
2. Controla las respuestas de ausencia. Con una dirección funcional (team@domain.com → varias cuentas de Gmail), revisa las respuestas automáticas y la prevención de ciclos. Precedence: bulk puede ayudar en algunos sistemas, pero no sustituye una política completa de supresión de respuestas.
3. Prueba desde una tercera cuenta. Gmail puede deduplicar mensajes. Si pruebas desde el propio destino, el mensaje puede quedar en Enviados sin aparecer en Recibidos. Usa otra cuenta, por ejemplo Yahoo u Outlook, y revisa también los registros.
4. Revisa la política saliente de M365. Si usas Microsoft 365, un administrador autorizado debe comprobar si la política de spam saliente permite el reenvío necesario. Un bloqueo puede producir 550 5.7.520; no cambies controles sin aprobación ni asumas que todas las rutas tienen la misma política.

Son causas habituales de problemas al empezar. Los códigos de error por sí solos no siempre permiten identificar la configuración responsable.

Cómo reenviar el correo de tu dominio a Gmail con TrekMail

La fuente describe reescritura SRS y firma ARC en el MTA de TrekMail para los mensajes reenviados, con el destino configurado en el panel. Confirma la implementación y cobertura actuales en la documentación; la automatización no garantiza que Gmail acepte cada mensaje.

La versión descrita en la fuente sitúa el reenvío de buzones en los planes Pro y Agency, no en Free ni Starter. Comprueba los requisitos actuales antes de cambiar de plan. Los pasos descritos están en la documentación de reenvío de buzones de TrekMail:

1. Abre Buzones (Mailboxes) en el panel
2. Pulsa Gestionar (Manage) en el buzón elegido
3. Activa Habilitar reenvío (Enable forwarding)
4. Introduce tu dirección de Gmail en Reenviar a (Forward to)
5. Activa Guardar una copia (Keep a copy) durante la configuración inicial
6. Pulsa Guardar ajustes de reenvío (Save Forwarding Settings)

«Guardar una copia» es importante. Según la configuración descrita, conserva una copia local además de intentar entregar a Gmail, siempre que haya cuota y la entrega local funcione. Sin ella, un rechazo externo puede dejarte sin copia accesible en el buzón. Mantenla activa mientras verificas mensajes y cabeceras; no equivale a una copia de seguridad garantizada.

La fuente también describe acciones masivas para seleccionar varios buzones y aplicar un destino común, incluso en un centenar de dominios. Confirma su disponibilidad y alcance antes de usarlas en dominios de clientes; prueba y revisa los resultados, sin asumir que una acción funciona en todos ellos.

Completar el flujo: «Enviar como» en Gmail

El reenvío gestiona el correo entrante, no la identidad de respuesta. Sin «Enviar como», las respuestas pueden salir desde tu dirección personal @gmail.com en vez de ceo@yourdomain.com, según el cliente y sus ajustes.

Configura «Enviar como» con credenciales SMTP externas autorizadas cuando corresponda. Revisa el método de envío y «Tratar como un alias» para tu caso: esa casilla por sí sola no determina el servidor usado ni garantiza la alineación DMARC. Prueba el From:, Return-Path y los resultados de autenticación.

Ruta orientativa en Gmail: Configuración → Cuentas e importación → Enviar como → Añadir otra dirección de correo. Revisa «Tratar como un alias» según la configuración actual, en lugar de desmarcarlo sin comprobar sus efectos.

Configuración SMTP de TrekMail descrita para Starter, Pro y Agency:

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano: SMTP propio (SES, SendGrid, Mailgun, etc.) según la fuente:

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

Los bloques anteriores son ejemplos: confirma los parámetros y credenciales vigentes. Gmail puede enviar un código de verificación al añadir la dirección. Completa la confirmación y configura el remitente predeterminado si procede; después comprueba qué identidad se selecciona realmente al responder.

Verificar el resultado: cabeceras de autenticación en Gmail

Tras recibir una prueba desde una cuenta externa, revisa las cabeceras completas antes de confiar correo importante a la configuración.

En Gmail: abre el mensaje → menú de tres puntos → Mostrar original. Busca Authentication-Results.

La fuente ofrece este ejemplo de resultados; no demuestra por sí solo que DMARC esté alineado con el remitente original:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

spf=softfail o spf=fail pueden indicar problemas de SRS, autorización SPF u otras condiciones de evaluación. arc=fail puede deberse a modificaciones de contenido firmado, claves, firmas o cadena inválidas; no identifica una única causa. Revisa también From:, DKIM, DMARC y la confianza ARC. La guía oficial de Google sobre reenvío a Gmail aporta criterios para comprobar el tratamiento del remitente del sobre.

Administración propia o servicio gestionado: el coste real

En un Postfix autogestionado, una opción es configurar postsrsd, proteger y gestionar srs_secret, planificar su rotación e integrar OpenARC con claves de firma ARC apropiadas. También conviene vigilar la reputación con Google Postmaster Tools cuando sea aplicable. Los detalles dependen de la arquitectura. Actualizaciones, rotaciones incorrectas o nuevas políticas pueden requerir investigación, incluso a las 11 de la noche.

La fuente describe SRS y ARC gestionados en el MTA tras configurar el destino en TrekMail. Comprueba los requisitos actuales, la autorización DNS y los resultados de entrega; seguir revisando la configuración es necesario.

Primeros pasos

La fuente presenta Nano sin tarjeta para conectar y probar un dominio, pero no como un plan con reenvío de buzones incluido. Para esa función, sitúa Pro desde $10/mes fijos sin cargos por usuario, dentro de sus límites. Confirma la disponibilidad y el precio actuales antes de contratar.

La versión descrita en la fuente ofrece una prueba gratuita de 14 días en planes de pago, con tarjeta de crédito, y Nano sin tarjeta. Consulta trekmail.net/pricing para verificar las condiciones actuales.

Revisa cuatro aspectos: la reescritura del sobre con SRS cuando corresponda, los resultados firmados de ARC, la autorización SPF del reenviador y la identidad saliente de «Enviar como». Son controles útiles, no una garantía de entrega durante años. DKIM, los filtros, las políticas receptoras y la supervisión también importan; los errores no siempre son silenciosos.

Configura, verifica las cabeceras y mantén el seguimiento.