¿Por qué su correo dice "vía" el dominio de otra persona?
Un cliente les envió una captura de pantalla de su último correo. Debajo de su nombre, en texto gris pequeño, Gmail imprimió via sendgrid.net. Su dirección está justo ahí, en la línea From. Es su propio dominio. Entonces, ¿por qué Gmail les dice a las personas que alguien más envió este mensaje?
Gmail no se equivoca. Un servidor de sendgrid.net realmente entregó este mensaje, y ninguno de los dominios ocultos dentro de él coincidía con el de ustedes. La línea de “vía” es Gmail diciéndolo en voz alta. Y es más fácil de arreglar de lo que parece.
Qué es la línea de “vía”
Cada correo lleva dos direcciones de remitente. El encabezado From: es la que ven sus lectores. El remitente del sobre es la que usan los servidores de correo. La encuentran en los encabezados como Return-Path:, y pertenece a la máquina que transportó su mensaje. También aparece un tercer dominio: el campo d= de la firma DKIM. Nombra el dominio que firmó el mensaje.
La documentación de Google enuncia la regla. Gmail muestra “vía” y un nombre de dominio junto al remitente cuando el dominio del que proviene el mensaje no coincide con el dominio de la dirección From. Alineen el dominio del sobre o el dominio de la firma con su dominio del From, y la línea desaparece.
Estos son los encabezados de un mensaje que muestra via sendgrid.net, reducidos a las dos partes que importan:
Return-Path: <bounces+e81f-jane=example.org@sendgrid.net>
From: Ana <ana@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.net; s=smtp1; ...
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounces+e81f@sendgrid.net
designates 198.51.100.24 as permitted sender)
dkim=pass header.i=@sendgrid.net
dmarc=fail (p=NONE dis=NONE) header.from=example.comLean esas líneas como lo hace un receptor. SPF aprobó, pero para sendgrid.net. DKIM aprobó, pero también para sendgrid.net. El remitente que todos pueden ver es example.com, y nada une a los dos. Gmail imprimió el resumen honesto de ese desorden debajo del nombre del remitente.
Hagan esto: abran un mensaje que muestre la etiqueta, pulsen “Mostrar original” y busquen la línea Return-Path: y el d= dentro de DKIM-Signature:. El dominio que encuentren ahí es el de su etiqueta de “vía”. Ahora saben qué plataforma envía su correo desalineado.
Por qué importa
La línea les cuesta dos veces.
Primero, el costo humano. Gmail muestra “vía” para que las personas detecten correo que declara un origen y llega de otro. Esa es la forma que adopta la mayoría del phishing. Así que Gmail acaba de invitar a su lector a desconfiar del mensaje. Las respuestas caen. Nadie les dice por qué.
Segundo, el costo técnico. Cuando tanto el dominio del sobre como el dominio de la firma pertenecen a otra persona, la alineación de DMARC falla. Eso es exactamente lo que registra la línea dmarc=fail de arriba. La alineación, en una frase: un mensaje aprueba DMARC solo si el dominio que aprobó SPF o el dominio que firmó con DKIM coincide con el dominio de la línea From. Esa coincidencia se llama alineación. Ambas comprobaciones de ustedes pasan actualmente por el dominio de otra persona, y esa única condición causa la etiqueta y una parte considerable de la ubicación en spam. Si su correo también cae en la carpeta de spam, empiecen por el diagnóstico completo de spam cuando terminen aquí.
Hagan esto: traten la línea de “vía” como un error de alineación que pueden ver. La solución de abajo también restaura DMARC.
Las tres causas, en orden
Causa uno: nunca configuraron su plataforma para enviar como su dominio
La mayoría de las líneas de “vía” vienen de esto. Todo ESP, herramienta de facturación, helpdesk y plataforma de cursos envía por su propio equipo por defecto. Y por defecto, tanto el remitente del sobre como la firma DKIM nombran el dominio de la plataforma.
Los valores por defecto se parecen en todas partes. Mailchimp firma con mailchimpapp.net hasta que ustedes autentican el dominio, que es exactamente el caso que recorre el artículo de Mailchimp. Amazon SES usa un sobre de amazonses.com hasta que configuran un MAIL FROM personalizado, y el artículo de SES cubre ese caso. SendGrid firma como sendgrid.net hasta que ustedes autentican un dominio de envío. Nada de esto es la plataforma fallando. Simplemente no terminaron la configuración, y nadie se los advirtió.
La pista: Return-Path: y d= nombran ambos la plataforma, y ustedes nunca publicaron registros DNS para ella. El email health check mostrará los registros que faltan.
Qué hacer: activen el custom sending domain de la plataforma. La sección de solución de abajo muestra cómo.
Causa dos: la configuración quedó a medias
El panel insiste en los registros DKIM, así que la mayoría publica esos. El subdominio del return path es fácil de omitir. A veces ocurre lo contrario: el sobre pasó a su dominio, los CNAME de DKIM nunca resolvieron, y la firma todavía nombra a la plataforma.
Esta es la razón por la que media configuración funciona, por un tiempo. Las dos rutas de alineación son alternativas. Cualquiera de las dos, alineada con su dominio del From, satisface DMARC y elimina la línea de “vía”. Publiquen un juego y omitan el otro, y todo funciona hasta que la mitad alineada se rompe. Entonces la etiqueta vuelve. Sin ningún error en ninguna parte. Una rotación de DKIM selector o una clave vencida del lado del ESP hace exactamente eso.
La pista: uno de los dos dominios es suyo y el otro todavía nombra a la plataforma. El primo SPF de este estado, donde el registro existe pero lista a los remitentes equivocados, está en el artículo sobre fallos de SPF.
Qué hacer: publiquen todo lo que la plataforma pidió, el subdominio del sobre y los registros de firma juntos.
Causa tres: un reenviador envió su mensaje de nuevo
A veces su configuración está bien y la etiqueta sigue siendo honesta. Cuando un mensaje pasa por una lista de correo o el reenvío automático de una empresa, esa máquina lo envía de nuevo con su propio sobre. SPF y la firma original ya no coinciden con el nuevo salto, así que el proveedor del destinatario muestra “vía” el dominio de reenvío.
La pista: su propia copia en Enviados muestra dominios alineados, y el dominio de “vía” es uno que nunca han escuchado. A menudo pertenece al empleador del propio destinatario o a un administrador de listas. Pregúntenle a la persona dónde aterrizó el mensaje.
Qué hacer: nada de su lado corrige este caso. El reenviador envió su correo de nuevo, así que esa corrección les corresponde a ellos. Comprueben que sus propios encabezados se alineen, y traten el resto como información. Este caso también es la razón por la que los receptores crearon ARC, que lleva los veredictos de alineación a través de los saltos. Ese es un problema del lado receptor, no de ustedes.
La solución
Los pasos son los mismos en cada plataforma, aunque cada una lo llama de otra forma. Mailchimp dice authenticated domain. SendGrid dice sending domain authentication. SES dice custom MAIL FROM.
La plataforma les entrega registros DNS. Un juego al estilo SendGrid se ve así:
em123.example.com. CNAME u123.wl.sendgrid.net.
s1._domainkey.example.com. CNAME s1.domainkey.u123.wl.sendgrid.net.
s2._domainkey.example.com. CNAME s2.domainkey.u123.wl.sendgrid.net.La primera entrada mueve el sobre a su subdominio, así que Return-Path: termina en em123.example.com y SPF se alinea. Las otras dos permiten que la plataforma firme con su dominio, así que d=example.com aparece en la firma y DKIM se alinea. Para saber cómo publicar registros como estos, incluidas las peculiaridades de hostname en los distintos proveedores de DNS, lean la guía de configuración de DKIM. Esos pasos no se repiten aquí.
Una vez que los registros resuelven, los encabezados cuentan la historia con claridad:
Return-Path: <bounces+e81f-jane=example.org@em123.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.google.com;
spf=pass (... domain of bounces+e81f@em123.example.com ...)
dkim=pass header.i=@example.com
dmarc=pass (p=NONE dis=NONE) header.from=example.comAmbas rutas ahora nombran example.com. DMARC aprueba. Gmail no tiene nada que imprimir después del nombre del remitente.
Hagan esto: publiquen el juego completo de registros, esperen el TTL y envíen una prueba nueva al mismo buzón que mostró la etiqueta.
Comprobar que la solución funcionó
Peguen el mensaje nuevo en el analizador gratuito de encabezados y comprueben tres cosas: el dominio del sobre, el dominio del d= y el veredicto del dmarc=. Los tres deben nombrar su dominio ahora, y el mensaje no debe mostrar ninguna línea de “vía”.
Luego confirmen el DNS desde afuera del panel de la plataforma. El email health check lee sus registros como lo hace un receptor, así que detecta cosas como un CNAME pegado contra el hostname equivocado mientras la plataforma todavía dice “pending verification”.
Ambas herramientas responden por un mensaje, en un día, en un dominio.
Lo que la comprobación puntual no ve
Esta solución es un estado, no un evento. La alineación se mantiene solo mientras los registros se mantienen. Cosas rutinarias los rompen en silencio: una migración de DNS elimina los CNAME, una plataforma rota sus selectores DKIM, alguien agrega una herramienta nueva bajo su dominio y esta empieza a enviar con su propia configuración por defecto. Cada una de esas cosas trae de vuelta la línea de “vía”. Ninguna envía un error. Se enteran semanas después, por la captura de pantalla de un cliente.
Por eso existe la parte de vigilancia. LitInboxes vuelve a comprobar sus registros SPF, DKIM y DMARC cada seis horas, marca cada cambio con una fecha para que puedan rastrear una falla hasta el día en que empezó, y les avisa cuando un registro se mueve. No tienen que recordar mirar. Las alertas por correo están en todos los planes, y las alertas de Slack, Discord y webhook están en Pro. Hay una demostración en vivo si quieren verla primero.
La lista de verificación
- Abran un mensaje que muestre la etiqueta. Elijan “Mostrar original”.
- Encuentren el dominio en
Return-Path:y en el campod=de DKIM. Ese es su dominio de “vía”. - Encuentren el ajuste de custom sending domain en esa plataforma y actívenlo.
- Publiquen cada registro que les entregue. Sí, también el subdominio del sobre.
- Esperen el TTL de DNS. Envíen una prueba nueva al mismo buzón.
- Confirmen con el analizador de encabezados que ambos dominios y el veredicto de DMARC ahora nombran su dominio.
- Ejecuten el email health check para confirmar los registros desde afuera de la plataforma.
- Pongan los registros en un ciclo de vigilancia, semanal a mano o con monitoreo continuo. La etiqueta vuelve en silencio cuando uno se rompe.
Cómo eliminar la línea de "vía" de sus correos
- Lean los encabezados de un mensaje que muestre la etiquetaAbran el mensaje en Gmail, usen el menú de tres puntos y elijan Mostrar original. Anoten qué dominio aparece en Return-Path y en el campo d= de DKIM-Signature. Ese dominio es el que Gmail imprime después de "vía".
- Activen el custom sending domain en su plataformaEn su plataforma de envío, busquen authenticated domain, custom domain o dedicated sending domain, e inicien la configuración para el dominio de su dirección From. La plataforma les entrega los registros DNS para publicar.
- Publiquen los registros de return path y DKIMNormalmente hay dos tipos: un subdominio para el remitente del sobre, a menudo llamado return path o MAIL FROM, y uno o dos CNAME de DKIM bajo _domainkey. Publiquen todos, no solo el juego de DKIM.
- Esperen el TTL de DNS y envíen una prueba nuevaLos cambios de DNS necesitan un mensaje nuevo para demostrar su efecto. Los registros viejos permanecen en caché un tiempo, así que vuelvan a probar después de una hora y usen el mismo buzón que mostró la etiqueta.
- Confirmen que los dominios ahora coincidenLean los encabezados del mensaje nuevo: Return-Path y d= deben nombrar su dominio, dmarc debe leer pass y Gmail no debe mostrar ninguna línea de "vía" bajo el nombre del remitente. El analizador de encabezados muestra todo esto en una sola vista.
Preguntas frecuentes
¿La línea de "vía" significa que alguien hackeó la cuenta de correo?
No. Significa que la máquina que envió el mensaje pertenece a un dominio distinto del de la dirección From. Cualquier plataforma de envío hace esto hasta que ustedes terminan su configuración. Si sospechan una intrusión, revisen mejor la carpeta de enviados y sus inicios de sesión recientes.
¿"Vía" manda el correo a spam?
No por sí sola. Es una etiqueta de visualización, no un veredicto. Pero la condición detrás de ella, el fallo de ambas rutas de alineación de DMARC, sí daña la ubicación. Traten la etiqueta como el síntoma de ese problema mayor.
"Vía" sigue apareciendo aun con los registros en DNS. ¿Por qué?
Tres posibilidades: los CNAME de DKIM resolvieron pero el registro del return path no, el mensaje de prueba salió antes de que el DNS terminara de propagarse, o un reenviador o una lista de correo envió el mensaje de nuevo bajo un tercer dominio. Una prueba nueva a una dirección directa separa las dos primeras de la tercera.
¿Puede el destinatario ocultar la línea de "vía"?
No. Gmail la construye a partir de los resultados de autenticación del propio mensaje, así que solo el remitente puede eliminarla, alineando el dominio de envío con el dominio del From. Ningún ajuste de ningún lado la oculta para el correo desalineado.