Por qué el correo que reenviaste a ti mismo terminó en spam

Configura un reenvío automático de tu cuenta antigua a la nueva, y parte de ese correo desaparecerá silenciosamente en spam — no porque tu proveedor esté roto, sino porque el reenvío reescribe quién está enviando el mensaje sin reescribir la prueba criptográfica. SPF verifica el servidor equivocado, el veredicto de DMARC cambia a fallo, y un correo legítimo que te enviaste a ti mismo se pone en cuarentena. La solución tiene un nombre: ARC, definido en RFC 8617 allá en 2019.

¿Por qué el reenvío hace que mi correo falle SPF?

Porque SPF verifica el último servidor que retransmitió el mensaje, y el reenvío cambia ese servidor. SPF — Sender Policy Framework — es un registro DNS que lista qué direcciones IP están autorizadas a enviar correo para un dominio. Cuando bank.com te envía un recibo, el servidor receptor verifica: ¿esto llegó desde una IP que bank.com autorizó? Sí. Aprobado.

Ahora reenvía ese recibo desde tu Gmail a tu nueva dirección. Los servidores de Google lo retransmiten. El servidor receptor final ejecuta la verificación SPF y pregunta: ¿Google está autorizado a enviar para bank.com? No, no lo está. SPF falla. La documentación propia de Google Workspace sobre Workspace explica esto claramente — los mensajes reenviados fallan SPF porque el servidor de reenvío no está en el registro SPF del dominio original. Nada fue suplantado. La verificación solo está mirando el salto equivocado.

Entonces, ¿por qué eso lo envía a spam?

DMARC. SPF fallando solo solía ser superable; DMARC lo convirtió en un veredicto. DMARC vincula SPF y DKIM y le dice a los receptores qué hacer cuando ambos fallan: nada, cuarentena, o rechazo. En 2024, los grandes remitentes no tuvieron opción — Google y Yahoo comenzaron a requerir DMARC a cualquiera que enviara más de 5.000 mensajes al día a sus usuarios.

DKIM, el otro pilar, es una firma horneada en el mensaje. En teoría sobrevive el reenvío, porque firma el contenido, no la ruta. En la práctica, cualquier cosa que toque el mensaje la rompe. Una lista de correo que agrega un pie de página "estás suscrito, desuscríbete aquí", un servidor que reescribe la línea de asunto, incluso un cambio en cómo se envuelve una línea — la firma ya no coincide, y DKIM también falla. Ahora ambos pilares están caídos, DMARC dice fallo, y tu propio recibo está en la carpeta de basura.

¿Qué es ARC y realmente arregla esto?

ARC — Authenticated Received Chain, RFC 8617 — permite que un reenviador honesto certifique que el correo pasó autenticación antes de que lo tocara. El servidor de reenvío sella el mensaje con un registro protegido que dice "cuando esto llegó a mí, SPF y DKIM eran válidos — confía en mi palabra para el tramo que no puedes verificar". El receptor final, si confía en ese reenviador, puede anular el fallo de DMARC y entregar.

La trampa está en "si confía". ARC no es una contraseña; es un sistema de reputación. Un receptor sopesa si el sellador de ARC es un operador conocido y bien comportado. Google sella encabezados ARC y los respeta de remitentes en los que confía, por eso un reenvío de Gmail a Gmail usualmente sobrevive mientras que un reenvío a través de algún antiguo relé universitario no.

Si ejecutas el reenvío tú mismo, dos movimientos concretos ayudan. Usa reescritura Server-Side Redirect / estilo SRS si tu proveedor la ofrece, que reescribe el remitente del sobre para que SPF verifique contra tu reenviador en lugar del dominio original. Y prefiere reenvío entre proveedores que ambos soporten ARC. Si estás consolidando cuentas y quieres que el destino solo maneje el desorden de autenticación para ti, ese es exactamente el tipo de infraestructura para la que está construida una plataforma de correo con IA.

¿Cuándo debería dejar de culpar a mi proveedor?

Cuando el patrón es "solo falla el correo reenviado", el proveedor está haciendo su trabajo correctamente — el protocolo es el problema. Aquí está la señal: abre los encabezados del mensaje que falta y busca la línea Authentication-Results. Si ves spf=fail junto con una IP de envío que pertenece a un reenviador en lugar del remitente original, eso es SPF verificando el salto equivocado. Si dkim=fail aparece en correo que fue a través de una lista o un relé que edita mensajes, eso es una firma corrupta, no una falsificación.

La verdad incómoda es que la autenticación de correo fue parcheada, capa por capa, a lo largo de dos décadas en un sistema que nunca asumió que alguien mentiría. SPF llegó en 2006, DKIM en 2007, DMARC en 2015, ARC en 2019 — cada uno parcheando un agujero que el anterior abrió. El reenvío es la costura donde los cuatro se frotan entre sí, y tu bandeja de entrada es donde sientes la fricción.