La cabecera Return-Path indica a qué dirección debe volver un correo cuando no se puede entregar. Es la dirección técnica del remitente del sobre SMTP (también llamada MAIL FROM, bounce address o dirección de rebote), la que recibe los avisos de error y la que comprueba SPF. Tu destinatario no la ve, pero los filtros de spam sí, y de ella depende en buena parte que DMARC pase o falle.

En esta guía verás qué es exactamente, en qué se diferencia de From y Reply-To, cómo localizarla en un mensaje real, cómo configurar un Return-Path propio en un subdominio y qué errores provocan rebotes y mala reputación cuando envías en volumen.

En resumen

• El Return-Path es el remitente del sobre SMTP: la dirección a la que se envían los rebotes. No es la dirección From que ve el lector ni la Reply-To a la que llegan tus respuestas.
• SPF valida el dominio del Return-Path, no el del From. Por eso, para que DMARC alinee por SPF, ese dominio debe coincidir con el de tu From, o ser un subdominio suyo en modo relajado.
• No puedes forzar la cabecera dentro del mensaje: la añade el servidor receptor final a partir del MAIL FROM que declaró el servidor emisor. Se configura en tu plataforma de envío y en tu DNS.
• Un Return-Path propio, del tipo bounces.tudominio.com con un CNAME o un registro MX hacia tu proveedor, es la práctica recomendada para envíos de volumen.
• Se verifica siempre con un mensaje real: “Mostrar original” en Gmail y revisar Return-Path y Authentication-Results.

Tabla de contenidos

• Qué es el Return-Path y para qué sirve
• Return-Path, From y Reply-To: tres direcciones distintas
• Envelope From frente a Header From: por qué importa la diferencia
• Cómo ver el Return-Path de un correo
• Por qué no puedes “poner” el Return-Path a mano
• Configurar un Return-Path personalizado paso a paso
• Lo que piden los grandes buzones
• Errores habituales con el Return-Path
• La mirada de PlusVibe: el Return-Path en prospección en frío
• Si prefieres no tocar el DNS tú mismo
• Preguntas frecuentes
• Fuentes

Qué es el Return-Path y para qué sirve

Todo correo lleva dos identidades de remitente. Una es la que ve el lector, la cabecera From. La otra viaja en el “sobre” del mensaje, es decir, en el diálogo SMTP entre servidores, y es el comando MAIL FROM. Esa segunda dirección es la que acaba registrada como Return-Path.

Según la definición recogida por Mailpro, el Return-Path es una cabecera SMTP oculta que indica a los servidores adónde enviar las notificaciones automáticas de fallo, y se define en el RFC 5321 como la dirección que usa el servidor receptor para informar de errores. La explicación de Lettr añade el detalle importante: la añade el servidor receptor en la entrega final, copiando la dirección que el servidor emisor dio en el comando SMTP.

Su utilidad práctica es doble:

1. Procesar rebotes. Cuando un buzón no existe, está lleno o el servidor rechaza el mensaje, el aviso de error vuelve a esta dirección y no a tu bandeja de ventas. Como explican los especialistas en entregabilidad, dirigir los rebotes automáticos a una dirección técnica mantiene limpio el buzón donde esperas respuestas humanas y facilita clasificar rebotes duros y blandos.
2. Autenticar con SPF. El servidor receptor consulta el registro SPF del dominio del Return-Path, no el del From.

Un detalle que despista a muchos: los propios avisos de rebote se envían con un remitente de sobre vacío, MAIL FROM:<>, lo que produce un Return-Path: <> en la cabecera final. Según la guía de Unspam sobre Return-Path, ese remitente vacío evita los bucles de rebote, en los que un error rebota de servidor en servidor sin fin. Si ves Return-Path: <> en un mensaje, no es un fallo: es un aviso automático.

Return-Path, From y Reply-To: tres direcciones distintas

La confusión entre estas tres direcciones está detrás de muchos problemas de configuración. Se resumen así:

La explicación de Unspam lo formula como tres entidades distintas: From es lo que ve el usuario y lo que DMARC protege, Reply-To es adónde va una respuesta manual y Return-Path es la dirección técnica de los rebotes. Mantenerlas alineadas o bien configuradas es, según esa misma fuente, una de las causas más habituales de mala entregabilidad y de caídas en spam.

Un ejemplo con una campaña de prospección:

• From: ana@tuempresa.com
• Reply-To: ventas@tuempresa.com
• Return-Path: bounces@bounces.tuempresa.com

El lector ve a Ana, sus respuestas llegan a ventas y los rebotes caen en un buzón técnico que tu plataforma procesa de forma automática. Si en cambio el Return-Path perteneciera a un dominio ajeno, por ejemplo el de la herramienta de envío, SPF validaría ese dominio ajeno y no el tuyo.

Envelope From frente a Header From: por qué importa la diferencia

En inglés se habla de envelope from frente a header from. El primero es el Return-Path (el sobre); el segundo, la cabecera From (la carta). Importa porque cada mecanismo de autenticación mira una cosa distinta:

• SPF comprueba si la IP que envía está autorizada por el dominio del envelope from.
• DKIM firma el mensaje con el dominio que indica la firma (d=), que puede ser cualquiera.
• DMARC compara el dominio del header from con los resultados de SPF y DKIM. El RFC 7489 describe cómo el receptor contrasta la dirección From con esos resultados y con la política publicada por el titular del dominio.

El resultado es que SPF puede dar “pass” y, aun así, no contar para DMARC. Si tu plataforma envía con un Return-Path de su propio dominio, SPF pasa contra ese dominio, pero no coincide con tu From. Entonces solo te salva DKIM, y cuando DKIM tampoco alinea el mensaje falla DMARC aunque “todo parezca en verde”.

Alineación relajada y estricta

Según Unspam, DMARC exige que el dominio del From coincida con el autenticado por SPF (el del Return-Path) o por DKIM. La alineación puede ser relajada, donde un subdominio coincide con el dominio organizativo, o estricta, donde se exige coincidencia exacta. Con alineación relajada, bounces.tuempresa.com alinea con un From de tuempresa.com. Con alineación estricta, no.

Si aún no has publicado tu política, tenemos una guía para configurar DMARC paso a paso sin bloquear tu correo.

Cómo ver el Return-Path de un correo

La forma más fiable es mirar un mensaje real, porque el Return-Path solo existe cuando el servidor receptor lo ha registrado. Unspam lo recomienda así: abrir el mensaje original con la opción de ver origen de tu cliente y buscar la cabecera en la parte superior del código o en Authentication-Results.

En Gmail:

1. Envía un mensaje de prueba desde tu herramienta a una cuenta de Gmail que controles.
2. Abre el mensaje, pulsa los tres puntos y elige Mostrar original.
3. Busca la línea Return-Path: al principio del texto.
4. Más abajo, en Authentication-Results, localiza spf=pass y el dominio que aparece en smtp.mailfrom=. Ese es el dominio que SPF ha comprobado.
5. Comprueba también dkim=pass con header.d= y dmarc=pass con header.from=.

Cómo interpretarlo:

Si quieres una comprobación rápida de cómo se ve tu cuenta de envío desde fuera, nuestra herramienta gratuita de revisión de spam en cold email puede servirte de punto de partida.

Por qué no puedes “poner” el Return-Path a mano

Un error frecuente: añadir una cabecera Return-Path: en el código del mensaje o en la plantilla esperando que cambie adónde van los rebotes. No funciona. Según Unspam, el servidor final de entrega la añade a partir del MAIL FROM, y cualquier Return-Path inyectado en el cuerpo o en las cabeceras probablemente se elimine o se sobrescriba. Una respuesta muy citada en Stack Overflow llega a la misma conclusión: la escribe el servidor receptor, no el emisor.

Lo que sí puedes cambiar es el MAIL FROM de la conexión SMTP. Según la herramienta que uses, eso se hace en un ajuste llamado “dominio de rebote”, “custom return-path”, “MAIL FROM personalizado” o “dominio de seguimiento de rebotes”. El resultado es el mismo: tu plataforma usa una dirección de tu dominio como sobre.

Configurar un Return-Path personalizado paso a paso

El proceso varía por proveedor, pero la lógica es común.

1. Elige el subdominio

Usa un nombre corto, descriptivo y que no se confunda con el sitio web ni con los buzones de las personas. Opciones habituales: bounces, bounce, mail, em o rp. Evita nombres que se parezcan a tus subdominios de envío reales, para que un fallo de DNS no afecte a los dos. Por ejemplo: bounces.tuempresa.com.

2. Crea el registro DNS que te indique la plataforma

Hay dos patrones:

• CNAME: bounces.tuempresa.com apunta a un host del proveedor. Así, el proveedor recibe los rebotes y publica su propio SPF en ese nombre. Es el patrón que describe, por ejemplo, la documentación de una plataforma de email marketing: el CNAME redirige los rebotes a sus servidores, que registran el contacto como rebotado y hacen pasar SPF con tu dominio.
• MX + TXT: un registro MX en el subdominio hacia el servidor que recibe rebotes y un TXT con el SPF que autoriza al proveedor. Es útil si necesitas recibir los avisos tú mismo.

Si estás configurando registros MX por primera vez, recuerda que cada subdominio tiene los suyos, independientes del dominio principal. Un MX en bounces.tuempresa.com no altera dónde recibes el correo de tuempresa.com.

3. Publica o revisa el SPF

El SPF debe estar en el nombre que coincide con el Return-Path. Si usas CNAME, normalmente el SPF ya lo publica el proveedor en el destino. Si usas TXT, incluye solo los remitentes que realmente envían desde ese subdominio y evita superar el límite de diez consultas DNS de SPF.

4. Firma con DKIM en tu dominio

La alineación por SPF y la alineación por DKIM se complementan. Con DKIM firmado con d=tuempresa.com (o un subdominio, en modo relajado) tienes una segunda vía para DMARC si SPF falla, por ejemplo cuando un servidor reenvía el mensaje y el sobre cambia.

5. Publica DMARC y empieza en p=none

El RFC 7489 define el modelo: el titular publica una política y los receptores envían informes. Empieza en none, revisa los informes, corrige las fuentes que no alinean y endurece después. Los pasos con ejemplos están en nuestra guía de DMARC sin bloquear tu correo.

6. Verifica con un mensaje real

Envía una prueba a Gmail, abre el original y confirma que smtp.mailfrom es tu subdominio, que spf=pass y que dmarc=pass. Hasta que no lo ves en una cabecera real, no está comprobado.

Lo que piden los grandes buzones

Los requisitos de autenticación ya no son opcionales para quien envía en volumen. Las directrices de Google para remitentes indican que, desde el 1 de febrero de 2024, quienes envían más de 5.000 mensajes al día a cuentas de Gmail deben cumplir requisitos adicionales, entre ellos configurar SPF y DKIM, publicar una política DMARC (puede ser none) y contar con registros DNS inversos y directos (PTR) válidos. Para cualquier remitente, la guía pide al menos SPF o DKIM y TLS.

El Return-Path entra en esa lista de forma indirecta: si no está alineado, tu SPF no te ayuda a cumplir DMARC. Que los umbrales puedan cambiar es una razón más para consultar esa página antes de lanzar una campaña grande.

Errores habituales con el Return-Path

Return-Path de un dominio sin relación con el From. Los especialistas coinciden en que un dominio de Return-Path ajeno al del From puede dar problemas de entregabilidad, porque los filtros modernos miran la alineación y pierdes una de las señales de autenticación más fuertes.

Buzón de rebotes que no existe o está lleno. Si el destino de rebotes no procesa mensajes, no sabrás qué direcciones son inválidas y seguirás enviando a ellas. En prospección en frío eso eleva la tasa de rebote y daña la reputación. Si tu tasa sube de golpe, repasa las siete comprobaciones más rápidas ante picos de rebote.

Confundir el tipo de rebote. No es lo mismo un 550 de buzón inexistente que un bloqueo temporal. Los códigos 5xx son permanentes y los 4xx, temporales. Te explicamos cómo actuar en códigos de rebote 550 y en bloqueo temporal SMTP.

Intentar fijarlo desde la plantilla. Como hemos visto, una cabecera Return-Path insertada en el mensaje se descarta. Cámbialo en el ajuste de la plataforma y en el DNS.

Mezclar subdominios de web, de envío y de rebote. Un solo registro mal editado puede romper la web o el correo corporativo. Documenta qué hace cada subdominio y revisa los registros MX y TXT cada vez que añadas una herramienta.

No tocar nada tras migrar de plataforma. Al cambiar de proveedor de envío, el CNAME antiguo sigue apuntando al anterior. Los rebotes se pierden y SPF deja de alinear. Elimina o actualiza los registros heredados.

La mirada de PlusVibe: el Return-Path en prospección en frío

En cold email, el Return-Path pesa más que en el correo transaccional por una razón sencilla: envías a listas que no te conocen, con tasas de rebote que cualquier dato sucio puede disparar, y desde dominios y buzones que has de proteger uno a uno.

Nuestro punto de vista, tal como trabajamos en PlusVibe, se apoya en tres ideas:

1. La infraestructura debe ser tuya, no compartida. Un Return-Path o una IP que comparten cientos de remitentes heredan la reputación del peor de ellos. Por eso apostamos por infraestructura de envío aislada, IPs dedicadas y warm-up privado.
2. Los rebotes son un dato, no un trámite. Un rebote duro te dice que una dirección no sirve; una racha de rebotes te dice que algo falla en la lista o en la autenticación. Hay que medirlos por buzón y por dominio, y detener el envío antes de que el daño llegue a la reputación.
3. Antes de escalar, verifica. Limpiar la lista con verificación de emails reduce rebotes en origen, y la autenticación (SPF, DKIM, DMARC y Return-Path alineado) evita que los filtros te penalicen por algo que se corrige en DNS.

No hay truco que sustituya a lo básico: dominio de envío separado del principal, autenticación alineada, calentamiento gradual y listas limpias. Nuestra guía de calentamiento de emails y la lista de comprobación de entregabilidad recogen ese orden de trabajo.

— Yaro

Si prefieres no tocar el DNS tú mismo

Configurar subdominios, MX, SPF, DKIM y DMARC para varios dominios y buzones es trabajo repetitivo y fácil de equivocar. En PlusVibe puedes empezar con una prueba gratuita y comparar los planes publicados: Starter desde 19 $ al mes, Growth a 39 $ al mes y Scale a 89 $ al mes, además de los planes Personal, Business y Agency. Si quieres que otro monte la infraestructura, el servicio Done-for-you Email Setup cubre la configuración de correo por ti, y en la página de planes encontrarás su precio actual.

Preguntas frecuentes

¿El Return-Path es lo mismo que la dirección From?

No. From es la dirección visible para el lector y la que protege DMARC. El Return-Path es la dirección del sobre SMTP, normalmente oculta, a la que se envían los rebotes y cuyo dominio comprueba SPF. Pueden coincidir, pero lo habitual con plataformas de envío es que difieran.

¿Puedo cambiar el Return-Path desde el contenido del correo?

No. La cabecera la añade el servidor receptor final a partir del MAIL FROM de la conexión SMTP, y una cabecera insertada a mano se descarta o se sobrescribe. Se cambia en la configuración de tu plataforma de envío y con los registros DNS que esta te pida.

¿Qué subdominio conviene usar para el Return-Path?

Uno corto y específico, como bounces, bounce o em, que no se confunda con tu web ni con tus buzones. En alineación relajada, un subdominio de tu dominio principal alinea con tu From. En alineación estricta, el dominio debe coincidir exactamente.

¿Por qué veo Return-Path: <> en algunos mensajes?

Porque son avisos de rebote o notificaciones automáticas, que se envían con remitente de sobre vacío para evitar bucles de rebotes entre servidores. No indica un error de tu configuración.

¿Cómo sé si mi Return-Path está bien configurado?

Envía un mensaje a Gmail, abre “Mostrar original” y comprueba que el dominio de smtp.mailfrom es tu subdominio, que SPF da pass y que DMARC también. Si DMARC solo pasa por DKIM, funciona, pero conviene alinear también SPF.

Fuentes

• Return-Path: la dirección que comprueba SPF y nadie ve (Unspam)
• ¿Qué es Return-Path (remitente del sobre)? (Mailpro)
• What is the Return-Path header? (Lettr)
• RFC 7489: DMARC
• Lineamientos para remitentes de correo electrónico (Ayuda de Gmail)
• Domains and domain alignment (ActiveCampaign)
• Set email headers so bounced emails go to a specific address (Stack Overflow)

Recomendaciones

• Códigos de rebote 550: qué significan y cómo solucionarlos
• Cómo configurar DMARC paso a paso sin bloquear tu correo
• Calentamiento de emails: guía práctica para prospección en frío
• Bloqueo temporal SMTP: cómo identificar la causa y recuperar el envío