¿Puedo quitar la etiqueta via de correos que mis clientes ya recibieron?

No. Gmail se la muestra a quien lee, y Google indica que el destinatario no puede desactivarla. Cuando te autenticas con tu propio dominio, los mensajes nuevos dejan de llevarla, pero los ya entregados conservan lo que se envió con ellos.

¿La etiqueta via significa que mi correo cayó en spam?

Por sí sola no. Reporta cuál dominio se autenticó, no una decisión de filtrado. Casi siempre convive con un problema real de entregabilidad, porque ese mismo desajuste es el que hace fallar DMARC.

Solo enviamos desde Google Workspace. ¿Por qué el nuestro dice gappssmtp.com?

Porque nunca se generó una llave DKIM para tu dominio. Google firma con una llave por defecto en un dominio gappssmtp.com hasta que publiques la tuya. Generar el registro en la consola de administración y agregar el TXT a tu DNS lo resuelve.

Gmail via: por qué aparece y cómo quitarlo de tus correos

La captura casi siempre llega de quien manda las facturas. Es su propio correo de facturación, abierto en Gmail desde el teléfono, y junto al nombre de su empresa aparece un fragmento extra: su nombre, luego la palabra via, y después una empresa de la que su cliente nunca ha oído hablar. A veces es la plataforma de marketing. A veces es una cadena que termina en gappssmtp.com. La pregunta que viene con la captura siempre es una versión de la misma: ¿esto nos hace ver como una estafa?

Nadie en la empresa cambió nada. La factura es real, el correo está llegando y ningún filtro lo bloqueó. Gmail simplemente le está diciendo al destinatario algo que el remitente nunca quiso decir. Esto es lo que reporta la etiqueta, cómo confirmamos la causa en unos diez minutos y el trabajo de DNS que la quita.

Qué está reportando Gmail cuando imprime via

Gmail muestra via y el nombre de un sitio junto al nombre del remitente cuando el dominio desde el que se envió el mensaje no coincide con el dominio de la dirección From:. La página de ayuda de Google usa la versión cotidiana del ejemplo: correo que parece venir de una dirección de un dominio, pero que se lo entregó a Gmail un servicio distinto. La etiqueta no es un veredicto de spam ni una advertencia. Es una revelación.

Dos detalles deciden qué tan en serio tomarla. El destinatario no puede desactivarla, porque Google la muestra para que quien lee sepa de dónde vienen los mensajes, así que pedirle a tus clientes que la ignoren no es una opción. Y la misma etiqueta aparece en correo enviado a un grupo de Google desde un dominio que publica una política DMARC de p=quarantine o p=reject, que es una causa aparte con una respuesta aparte.

Trata la etiqueta como un síntoma. La condición de fondo es que la identidad con la que te autenticas y la identidad que le muestras a tus clientes no son la misma.

Mailed by y signed by, las dos filas de abajo

Abre el mensaje en Gmail desde una computadora y despliega los detalles debajo del remitente. Salen hasta dos filas, y Google es claro sobre cómo leerlas: un mensaje está autenticado si ves un encabezado mailed-by con el nombre del dominio y un encabezado signed-by con el dominio de envío. Si en cambio aparece un signo de interrogación junto al nombre del remitente, el mensaje no está autenticado, lo que significa que Gmail no sabe si viene de quien parece venir.

Esas dos filas corresponden a los dos métodos de autenticación:

mailed-by es el dominio que Gmail usó para la revisión de SPF. Ese es el remitente de sobre, también llamado return path o dirección de rebote. No es la dirección que lee tu cliente.
signed-by es el dominio de la firma DKIM, el valor de la etiqueta d= definida en el RFC 6376.

Cuando alguno de esos dominios es de otra empresa, Gmail autenticó a otra empresa, y lo dice en el sobre que abre tu cliente. Ese es todo el mecanismo.

Los tres escenarios donde lo encontramos

Un tenant de Workspace que nunca publicó su propia llave DKIM

Este es el que más sorprende a los dueños, porque el correo sale de los servidores de Google. Si no configuras una llave DKIM para tu dominio, Google firma los mensajes salientes con una llave por defecto cuyo dominio termina en gappssmtp.com en lugar del tuyo. Ese seguía siendo el comportamiento documentado cuando revisamos la página de ayuda para administradores el 7 de octubre de 2026. La firma es válida y el correo va bien firmado. Solo que no va firmado como tú. Los mensajes enviados desde servidores que no son de Google no quedan cubiertos por esa llave por defecto.

Una plataforma que sigue enviando con su propio dominio

Las herramientas de marketing, los CRM, las mesas de ayuda, el software de facturación y las plataformas de tienda vienen con un dominio de envío compartido para que una cuenta nueva funcione desde el primer día. Hasta que alguien termine el paso de autenticación de dominio dentro de ese producto, el valor d= sigue siendo de ellos. Si este es tu caso, nuestras notas sobre Mailchimp, HubSpot y Klaviyo y sobre SendGrid, Mailgun y Amazon SES listan los registros exactos que pide cada producto.

Correo a un grupo de Google desde un dominio en quarantine o reject

Aquí la etiqueta es un efecto secundario de hacer las cosas bien. El grupo reescribe o retransmite el mensaje, el dominio de envío deja de coincidir con el de From: y Gmail lo revela. No hay nada que arreglar en DNS. El lugar para revisar son las opciones de reenvío del grupo, y la etiqueta en correo interno de listas no vale la pena perseguir.

Qué revisamos primero, en orden

Pedimos un mensaje que haya recibido un destinatario real, reenviado como adjunto o pegado como mensaje original. Una captura no alcanza, porque la respuesta está en los encabezados. Después leemos tres cosas antes de que nadie toque el DNS.

La línea Authentication-Results: qué identidad pasó y a qué dominio pertenecía.
El valor d= del encabezado DKIM-Signature, comparado con el dominio de From:.
El Return-Path, comparado con ese mismo dominio de From:.

Un mensaje con el problema se ve así:

Authentication-Results: mx.google.com;
       dkim=pass header.d=mailer.plataformadeenvio.example;
       spf=pass smtp.mailfrom=bounces.plataformadeenvio.example;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tuempresa.com

Las dos revisiones pasan. Ninguna pasó por ti. DMARC falla como consecuencia y Gmail imprime la revelación. Si quieres la misma lectura de tu propio mensaje sin esperarnos, pega los encabezados en el analizador de arriba, o sigue a tu ritmo cómo leer los encabezados de un correo.

La solución, según el escenario

Para Google Workspace, el registro sale de la consola de administración: abre Apps, luego Google Workspace, luego Gmail, elige Autenticar correo, selecciona el dominio y genera un registro nuevo. El prefijo de selector por defecto es google, que es el recomendado. Publica lo que te entregue como registro TXT y después activa la autenticación en la consola.

google._domainkey.tuempresa.com.   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Para una plataforma de terceros, la instrucción de Google para quien envía con un proveedor de correo masivo o con afiliados es publicar un registro SPF que incluya las IP desde las que envía ese proveedor, y firmar los mensajes con una firma DKIM asociada a tu dominio. En la práctica eso significa completar la autenticación de dominio del producto para que el valor d= pase a ser un nombre bajo tu dominio, y configurar un return path o dominio de rebote propio donde el producto lo ofrezca, para que la identidad de SPF también quede alineada. Alinear una de las dos basta para DMARC. Alinear las dos es lo que quita la etiqueta y lo que aguanta cuando el proveedor cambia sus valores por defecto.

Aprovecha para contar tus consultas DNS. Cada include de un proveedor gasta parte del presupuesto de diez consultas de SPF, y un registro que ya está en el límite se rompe sin avisar cuando agregas otro remitente.

Por qué esto es más que un problema cosmético

Las guías para remitentes de Google piden SPF y DKIM, un registro DMARC cuya política puede ser p=none, y que el dominio de From: esté alineado con el dominio de SPF o con el de DKIM. El RFC 7489 llama a eso alineación de identificadores, y es la condición para que DMARC pase. Quien envía más de 5,000 mensajes al día a cuentas de Gmail tiene que cumplir esos requisitos desde el 1 de febrero de 2024.

Un d= sin alinear es entonces el mismo defecto que hace fallar DMARC, y un dominio cuyo correo legítimo falla DMARC nunca se puede mover a p=reject sin perder facturas. La etiqueta via es solo la parte de ese defecto que tus clientes alcanzan a ver. Arreglar la etiqueta y arreglar la autenticación son el mismo trabajo.

Qué vigilamos después del cambio

Primero el DNS: el registro TXT tiene que verse públicamente, no solo quedar guardado en el panel. Después un mensaje de prueba a una dirección de Gmail, revisando que signed-by ya diga tu dominio y que aparezca dmarc=pass en los encabezados. Después los reportes agregados por una o dos semanas, porque una empresa casi siempre tiene más remitentes de los que recuerda, y en los reportes es donde salen la impresora olvidada, el software contable y la vieja herramienta de boletines. Solo después de eso tiene sentido subir la política.

Cómo ayuda Guanacos Tech

Tomamos esto como un solo trabajo acotado: encontrar todo sistema que envía con tu dominio, alinear los que deben, cerrarle la puerta a los que no, y dejarte registros que puedas explicarle a quien administre tu DNS después. En cómo trabajamos está la forma en que corre un proyecto. El punto comercial es sencillo: un cliente que se detiene a preguntar si una factura es legítima es un cliente que todavía no la ha pagado. Nuestra página de consultoría de entregabilidad de correo es el lugar para empezar. Una llamada de 30 minutos alcanza para decirte en cuál de los tres escenarios de arriba estás y qué implica la solución.

Por qué Gmail muestra via junto al nombre de tu empresa, y cómo quitarlo