¿Debo agregar a mi registro SPF el servidor que reenvía de quien me recibe?

No. No puedes conocer todas las direcciones que reenvían tu correo, y cada include que agregas gasta parte de un presupuesto limitado a diez consultas DNS, así que el intento termina rompiendo SPF para todos. Usa DKIM: una firma de tu propio dominio sobrevive un reenvío simple, y a DMARC le basta una comprobación alineada.

¿Puedo pasar DMARC a p=reject si el correo reenviado falla SPF?

Sí, siempre que cada sistema que envía como tu dominio firme con una llave DKIM que alinee con el dominio de tu From. DMARC necesita un identificador alineado, no los dos, así que el correo reenviado sigue pasando por DKIM. Antes de apretar la política, resuelve las filas donde fallan SPF y DKIM al mismo tiempo.

¿Quién tiene que configurar ARC, yo o el reenviador?

El intermediario que modifica el mensaje: la lista de correo, el servicio de reenvío, la pasarela. No puedes agregar cabeceras ARC en el salto de otro, solo documentar dónde se rompe la cadena y pedirlo. Del lado que recibe sí puedes decirle a Microsoft 365 que confíe en un sellador ARC concreto, y Gmail ya lee la cadena cuando está.

El reenvío de correo rompe SPF: arréglalo con DKIM o ARC

Un cliente nos llamó por sus facturas. A sus clientes les llegaban sin problema, salvo a uno, cuyo contador nunca recibió ni un archivo. El rebote que al final nos reenviaron decía que el mensaje había fallado SPF. Nada había cambiado de su lado: el mismo Workspace, el mismo registro SPF, el mismo buzón que llevaba toda la semana enviando las mismas facturas. La diferencia era un salto más. La dirección del contador era una vieja, de un trabajo anterior, que reenvía todo en silencio a una cuenta personal de Gmail, y SPF no sobrevive ese viaje.

Es la falsa alarma más común en el trabajo de entregabilidad. El síntoma se parece exactamente a un registro DNS roto, así que la gente reescribe el registro, lo vuelve a reescribir, y los fallos siguen, porque el registro nunca fue el problema.

Qué cambia el reenvío y qué deja intacto

Cada mensaje lleva dos direcciones de remitente. La del sobre es el MAIL FROM que un servidor le anuncia al siguiente durante la conversación SMTP, también llamada ruta de retorno o 5321.MailFrom. La cabecera From: es la que ve quien lee, la 5322.From. SPF no tiene nada que ver con la segunda. Toma el dominio del remitente del sobre, consulta el registro SPF de ese dominio y hace una sola pregunta: ¿la IP que se está conectando ahora está en la lista?

El reenvío simple conserva las dos direcciones y cambia la IP. El servidor que reenvía vuelve a enviar tu mensaje desde su propia infraestructura, pero sigue declarando tu dominio en el sobre. El receptor del otro extremo hace entonces justo lo que SPF le pide: consulta tu registro, encuentra tus includes de Google o de Microsoft, no encuentra al reenviador en ninguno y devuelve un fallo. La documentación de Google lo dice sin rodeos: los mensajes reenviados fallan SPF con frecuencia, y lo hacen incluso cuando SPF está bien configurado para el dominio, por la forma en que el servidor reenvía.

Por qué DKIM suele sobrevivir y las dos cosas que lo matan

DKIM va pegado al mensaje, no a la conexión. La firma vive en una cabecera y cubre el cuerpo más un conjunto elegido de cabeceras, así que viaja con el mensaje en lugar de recalcularse en cada salto. Si reenvías el mensaje sin tocarlo, la firma sigue verificando al final. Por eso Google le dice a quien envía que DKIM importa especialmente en el correo que se reenvía.

Dos cosas lo rompen. La primera es la modificación. Una lista de correo que agrega un pie con el enlace para darse de baja, o que le pone el nombre de la lista al asunto, cambia los bytes exactos que cubría la firma, así que el hash del cuerpo ya no coincide y DKIM falla. La segunda es la ausencia: un mensaje que tu dominio nunca firmó. Sigue siendo común con sistemas de facturación, CRM, herramientas de reservas y equipos que escanean y envían por su cuenta, a los que nadie les configuró una llave.

DMARC pasa cuando una de las dos alinea

Esta es la parte que resuelve casi todas estas llamadas. DMARC no necesita que pasen las dos comprobaciones. Necesita un identificador autenticado que pase y cuyo dominio alinee con el dominio de la cabecera From:. El RFC 9989, el estándar DMARC publicado en mayo de 2026 que reemplazó al RFC 7489, mantiene esa estructura de una o la otra y deja los dos modos de alineación en relajado, lo que significa que debe coincidir el dominio organizacional y no el nombre exacto.

Entonces un mensaje reenviado que muestra spf=fail dkim=pass, con una firma de tu propio dominio, es un DMARC pass. No hay nada roto. El reenvío sacó a SPF del juego y DKIM cargó con el mensaje igual, que es el diseño funcionando como se pensó. Un mensaje que muestra spf=fail dkim=fail es otra conversación, y la siguiente pregunta es cuál de los dos problemas de DKIM de arriba tienes.

Lee un mensaje reenviado antes de tocar el DNS

Pedimos una sola cosa: las cabeceras completas de un mensaje que de verdad falló, copiadas del buzón que está al final de la cadena. No el reporte DMARC, no una captura del panel de DNS. Las cabeceras llevan la ruta entera. La línea Authentication-Results, arriba, muestra a qué conclusión llegó el receptor final. Las líneas Received:, leídas de abajo hacia arriba, muestran cada salto, incluido el reenviador que nadie mencionó en la llamada. La cabecera DKIM-Signature muestra qué dominio firmó, en su etiqueta d=.

Con eso, tres preguntas se responden solas: si el mensaje fue reenviado, si DKIM sobrevivió y si el dominio que firma alinea con el dominio del From:. Pega las cabeceras aquí abajo y obtienes las mismas tres respuestas sin recorrer la cadena a mano, y hay un recorrido más largo en cómo leer las cabeceras de un correo que cayó en spam.

Tres situaciones de reenvío, tres trabajos distintos

Quien recibe reenvía tu correo. Una dirección vieja de un trabajo anterior, una cuenta de rol que reparte a tres personas, un Gmail personal alimentado por uno del trabajo. Ese reenviador no lo controlas y nunca lo vas a controlar. Tu palanca es que DKIM esté puesto y sin romper, para que DMARC pase sin SPF.
Hay una lista o un grupo en medio. Aquí el mensaje se modifica a propósito, así que DKIM falla por diseño y no por accidente. El arreglo le toca a quien administra la lista, y el mecanismo es ARC.
Una pasarela reenvía el correo hacia tu propio dominio. Un filtro, un servidor viejo, otro proveedor parado delante de Google Workspace. Este sí te toca a ti, y se arregla con una opción, no con un registro DNS.

Qué arreglamos del lado que envía

Firma todo con DKIM, desde cada remitente. Primero armamos el inventario: la plataforma de correo, el sistema de facturación, el CRM, la tienda en línea, la mesa de ayuda, la impresora del rincón. Cada uno que envíe como tu dominio recibe su propia llave o su par de CNAME. Un remitente que nadie recordaba es la razón habitual de que un flujo siga fallando tras el reenvío mientras el resto va bien.
Revisa la alineación, no solo que exista una firma. Una firma cuyo d= apunta al dominio del proveedor verifica sin problema y no hace nada por tu resultado DMARC, porque no alinea con el dominio de tu From:. Esa diferencia es todo el tema de nuestras notas sobre la alineación en las grandes plataformas de marketing.
Deja a SPF fuera de esto. No puedes enumerar a todos los reenviadores del mundo, y cada include que agregas gasta parte de un presupuesto limitado a diez consultas DNS, que es su propio modo de falla en cuanto lo cruzas. Escribimos aparte sobre cómo volver debajo del límite de diez consultas. Perseguir IP de reenviadores es como los dominios terminan ahí.
Lee bien los fallos. Una fila de reenvío no es un atacante, y tratarla como tal cuesta semanas de trabajo sobre registros que ya estaban bien.

Qué se arregla en el reenviador

Existen dos mecanismos para esto, y los dos viven con el intermediario, no contigo.

El primero es el Sender Rewriting Scheme. El reenviador reescribe el remitente del sobre a una dirección de un dominio que él controla, así el receptor del otro extremo evalúa SPF contra el reenviador, donde la IP que conecta sí está autorizada, y SPF pasa. Microsoft 365 lo hace con los mensajes que salen hacia destinatarios externos, y desde agosto de 2023 también lo usa para el reenvío de buzón en lugar de la dirección del buzón que reenvía. Solo toca el remitente del sobre; la dirección From: que se ve en el cliente de correo queda igual.

El segundo es ARC, la Authenticated Received Chain definida en el RFC 8617. Un intermediario registra lo que vio antes de cambiar nada, en tres cabeceras: ARC-Authentication-Results con el veredicto en ese salto, ARC-Message-Signature sobre el mensaje tal como estaba y ARC-Seal sobre la cadena hasta ahí. El extremo final puede ver entonces que un mensaje que falla ahora venía pasando cuando entró a la cadena. Google les pide a los servicios de reenvío, a las listas y a las pasarelas de entrada que agreguen estas cabeceras, y aplica la lógica en los dos sentidos: si un mensaje reenviado pasa SPF o DKIM en el último salto pero la cadena muestra que falló antes, Gmail lo trata como no autenticado. Del lado que recibe, Microsoft 365 te deja nombrar selladores ARC de confianza, identificados por el valor d= de la cabecera ARC-Seal, para que el correo modificado por un servicio en el que confías deje de fallar.

Ninguno de los dos te toca desplegarlo. Cuando el correo de un cliente sigue fallando a través de un solo intermediario, podemos documentar la cadena, mostrarle al operador dónde se rompe y pedirlo. El mejor uso de la hora suele ser dejar DKIM sólido de tu lado, porque eso funciona sin la cooperación de nadie más.

Cuando la pasarela está delante de tu propio dominio

Este caso sí lo arreglamos de raíz, y es el que más se pasa por alto. Si el correo llega a tus usuarios de Google Workspace pasando primero por otra cosa, Gmail está juzgando a la última máquina con la que habló, que es tu propia pasarela y no quien envía. Para eso existe la opción de pasarela de entrada: listas las IP de la pasarela y activas la detección automática de la IP externa. Gmail lee entonces las cabeceras Received: buscando la primera IP pública que no esté en tu lista de pasarelas y usa esa dirección para SPF y para evaluar el spam. Con la opción apagada, Gmail revisa un solo salto hacia atrás. Una advertencia de la misma página: una dirección que pongas en la configuración de pasarela de entrada no se agregará además a una lista de permitidos.

Qué van a seguir mostrando los reportes

Las filas de reenvío no desaparecen nunca. Tus reportes agregados siempre van a traer algo de correo desde IP que no reconoces, fallando SPF y pasando DKIM, y así se ve un reenvío sano desde dentro. Nuestra guía para leer reportes agregados de DMARC explica cómo distinguir esas filas de las que sí vale la pena mirar.

La consecuencia para la política: el reenvío no es razón para quedarse en p=none. Cuando cada remitente firma con una llave DKIM alineada, el correo reenviado sigue pasando por DKIM y moverse a cuarentena y después a reject no lo pone en riesgo. Resuelve las filas donde fallan las dos comprobaciones antes de apretar la política. Esas casi nunca son reenviadores; son un remitente del que nadie te avisó.

Cómo ayuda Guanacos Tech

Aquí la mayor parte del trabajo es diagnóstico, no configuración. Tomamos un mensaje que falló, leemos la cadena y decimos en cuál de las tres situaciones estás, y luego arreglamos lo que sí te toca: los remitentes sin llave DKIM, las firmas que verifican pero no alinean, la opción de la pasarela que hace que Gmail juzgue a la máquina equivocada. Nuestra consultoría de entregabilidad de correo empieza por ese diagnóstico y te muestra las cabeceras en las que se basa. Si tu correo funciona hasta que alguien lo reenvía, agenda una llamada de 30 minutos y trae un rebote contigo.

Tu correo pasa SPF, hasta que alguien lo reenvía: qué se rompe y qué arreglamos primero