Todo correo lleva dos direcciones de remitente. Tu lector ve una de ellas. SPF comprueba la otra, y DMARC pasa o falla según si las dos pertenecen al mismo dominio.
La que ve tu lector es la cabecera From. La que comprueba SPF es el remitente del sobre, que el servidor receptor escribe dentro del mensaje como cabecera Return-Path al aceptar la entrega. Un mensaje puede pasar SPF a la perfección con una ruta de retorno que pertenece a tu plataforma de envío y aun así fallar DMARC, porque la dirección de la cabecera From es tuya y la autenticada no.
Return-Path es el remitente del sobre, no la dirección From
SMTP tiene un sobre y un mensaje, y cada uno lleva direcciones distintas. El remitente del sobre se indica en el comando MAIL FROM al principio de la transacción, antes de enviar ninguna cabecera. La cabecera From forma parte del mensaje, escrita por lo que sea que lo compuso.
El servidor receptor es quien convierte una cosa en la otra: al aceptar un mensaje estampa el remitente del sobre en una cabecera Return-Path arriba del todo. Así que un Return-Path en un mensaje que recibiste es un registro de lo que el servidor emisor declaró en el cable, anotado por el receptor. No es algo que el emisor ponga como cabecera, y un Return-Path añadido por un emisor no significa nada.
Tres direcciones se confunden habitualmente y cada una hace un trabajo distinto:
| Campo | Lo pone | Sirve para |
|---|---|---|
| Return-Path | El receptor, desde MAIL FROM | SPF, y adónde van los rebotes |
| From | Quien compone | Lo que ve tu lector, y lo que protege DMARC |
| Reply-To | Quien compone | Adónde se dirige una respuesta |
SPF autentica la ruta de retorno, y por eso SPF solo no frena la suplantación
SPF pregunta si el servidor que conecta está autorizado a enviar por un dominio, y el dominio que usa es el del remitente del sobre. El RFC 9989 compara RFC5321.MailFrom y nunca el nombre HELO, así que una herramienta que informa de alineación SPF a partir de la identidad HELO está respondiendo a otra pregunta.
Esa es toda la razón por la que SPF por sí solo nunca ha frenado la suplantación del nombre visible. Cualquiera puede enviar un mensaje con MAIL FROM: bounces@a-domain-they-own.example y una cabecera From que ponga el nombre de tu empresa. SPF pasa, porque el emisor sí está autorizado para el dominio del sobre que eligió. El lector ve tu nombre en la bandeja. Nada de esto es un defecto de SPF: es SPF comprobando el identificador que fue diseñado para comprobar.
DMARC es la capa que lo cierra, al exigir que el identificador autenticado se relacione con el visible.
DMARC necesita que el dominio de la ruta de retorno se alinee con tu dominio From
La alineación es la comparación que hace DMARC. No pregunta si SPF pasó. Pregunta si SPF pasó para un dominio que coincide con el de la cabecera From.
Tu plataforma de marketing puede pasar SPF con su propio dominio de rebotes todas y cada una de las veces, y tu resultado DMARC sigue siendo un fallo por el lado de SPF, porque los dos identificadores no se relacionan. DKIM puede rescatar el mensaje si la plataforma firma como tu dominio, y a menudo es lo único que lo hace. En los dominios que probamos para el Unspam 2026 Email Deliverability Benchmark, solo el 48% publica una política DMARC, y entre los que sí lo hacen, una ruta de retorno sin alinear es una de las razones más comunes de que un dominio se quede un año en p=none.
El síntoma visible, antes de que llegue ningún informe, es que la bandeja de entrada te delata. Gmail muestra un mensaje como enviado "via" el dominio de la plataforma cuando la ruta de retorno no coincide con el dominio From, y otros clientes imprimen algo parecido. Si tu correo dice "via" otro, tu ruta de retorno no está alineada.
La alineación relajada no se puede decidir solo con las cabeceras
DMARC tiene dos modos de alineación, y la diferencia importa al leer la salida de un comprobador.
- Estricta significa que los dos dominios son idénticos. Eso se puede decidir con las cabeceras que tienes delante.
- Relajada, la opción por defecto, significa que los dos comparten un dominio organizativo. Eso no se puede decidir con las cabeceras, porque averiguar dónde está el límite organizativo es una pregunta de DNS.
El RFC 9989 sustituyó la Public Suffix List por un recorrido del árbol DNS precisamente por esto. Con el enfoque antiguo una herramienta podía llevar una copia de la lista y responder sin conexión, a cambio de equivocarse cada vez que la lista se movía. Con el actual, la respuesta exige resolver el árbol, así que un analizador de cabeceras que informa de "alineado" sin hacer consultas o solo ha resuelto el caso estricto o se lo ha inventado.
Nuestro analizador de cabeceras de correo resuelve la alineación estricta a partir de las cabeceras e informa de la relación entre los dos dominios, una de estas: idénticos, subdominio del dominio autor, el autor es subdominio, comparten un ancestro, o no están relacionados. La alineación relajada se resuelve aparte con el recorrido del árbol, porque un resultado que no se ha medido no es un resultado.
Esa distinción es práctica, no quisquillosa. bounces.example.com frente a example.com está alineado en relajado y desalineado en estricto, que es el estado normal de una ruta de retorno personalizada bien configurada, y una herramienta que lo informe como fallo te mandará a arreglar algo que ya está bien.
Una ruta de retorno personalizada es como una plataforma consigue alineación SPF
La solución estándar es un subdominio que delegas en la plataforma. Publicas un CNAME en algo como bounces.example.com que apunta a la infraestructura de la plataforma, la plataforma usa ese nombre como remitente del sobre, y SPF pasa ahora con un dominio que comparte tu dominio organizativo, o sea alineado en relajado.
Cuatro detalles deciden si esto funciona:
- Tiene que ser un subdominio de tu dominio From. Un CNAME en otro dominio que también tengas no se alinea con nada.
- El registro SPF que importa es el del dominio de la ruta de retorno, no el de tu dominio From. Este es el paso que más se salta, porque la gente comprueba el registro equivocado y ve un pase.
- Hay que configurar la plataforma para que lo use. Publicar el DNS es la mitad; la plataforma tiene un ajuste, y si no se toca sigue usando su propio dominio de rebotes.
- Un subdominio hereda tu política DMARC por el recorrido del árbol, salvo que publiques
sppara decir otra cosa, así que queda cubierto por la aplicación que tengas.
La guía sobre registros SPF cubre el registro en sí, y nuestra guía sobre registros DMARC cubre la política y sus etiquetas.
Los rebotes van a la ruta de retorno y a ningún otro sitio
El otro trabajo del remitente del sobre es ser la dirección a la que se envían los informes de no entrega. Un servidor que no puede entregar tu mensaje manda el fallo a la ruta de retorno, no a tu dirección From ni a Reply-To.
Por eso una ruta de retorno personalizada cambia quién ve los rebotes. Delégala en una plataforma y la plataforma los recoge, que es lo que le permite suprimir direcciones muertas automáticamente. Apúntala a un buzón sin vigilancia de tu propio dominio y los informes se amontonan donde nadie los lee, que es como una lista se pudre en silencio.
También es la razón de que exista una ruta de retorno <>, el remitente nulo. Los propios mensajes de rebote se envían con un remitente de sobre vacío para que un rebote no pueda rebotar, y un mensaje que llega con la ruta de retorno vacía es un informe automático y no correo que escribió alguien.
Cómo leer la ruta de retorno en un mensaje que ya enviaste
La comprobación más rápida es sobre un mensaje real y no en el DNS, porque la ruta de retorno solo existe una vez que un receptor la ha anotado.
- Mándate un mensaje a través de la plataforma que estés revisando, a un buzón de otro proveedor.
- Mira las cabeceras originales y busca
Return-Path. Gmail lo llama "Mostrar original"; casi todos los clientes tienen un equivalente. - Compara su dominio con el dominio From. Idéntico es alineación estricta, un subdominio de tu dominio From es el caso relajado normal, y un dominio sin relación significa que SPF no puede aportar nada a DMARC.
- Lee
Authentication-Resultsen ese mismo mensaje. La propiedadsmtp.mailfromes el dominio que el receptor autenticó de verdad, que es la respuesta autorizada cuando está presente. - Repítelo con cada plataforma que envía como tú. Cada una tiene su propio ajuste, y las configuran personas distintas en momentos distintos.
La alineación de la ruta de retorno es una de las dos formas de que un mensaje satisfaga DMARC, y la otra es DKIM, que sobrevive al reenvío donde SPF no. Nuestra guía sobre autenticación del correo cubre cómo dependen unos de otros los tres registros, y el fallo silencioso del lado de SPF es el tema de nuestra guía sobre el mecanismo include de SPF.
Para ver los dos identificadores en un mensaje real, junto a todo lo demás que puntúa un receptor, haz una prueba de spam gratis.
