Imagina una correduría de seguros de 14 personas que envía una cotización, y el cliente responde con una captura de pantalla. Arriba del mensaje, Gmail puso un aviso: no puede verificar que el correo venga realmente de la correduría. Nada rebotó. La cotización llegó. Pero el cliente pregunta si hackearon a la correduría, y el corredor nos pregunta si debe cambiar el DNS, cambiar de proveedor de correo, o las dos cosas.
Ese aviso no es un veredicto de spam. Es una afirmación sobre identidad: Gmail no pudo comprobar que el mensaje venga del dominio que aparece en el campo De. El problema es más acotado de lo que parece y, cuando el correo es tuyo, normalmente se arregla la misma tarde.
Qué te está diciendo el aviso en realidad
Gmail revisa dos pruebas de identidad en cada mensaje que recibe. SPF pregunta si el servidor que entregó el mensaje tiene permiso de enviar por ese dominio. DKIM verifica una firma criptográfica del mensaje contra una clave pública publicada en el DNS del dominio. Si no pasa ninguna, Gmail considera el mensaje no autenticado, y la ayuda de Google es clara sobre cómo se ve eso: un signo de interrogación junto al nombre del remitente significa que Gmail no pudo autenticar el mensaje, así que no sabe si el correo viene de quien parece enviarlo.
De ahí se desprenden dos cosas. Primero, no autenticado no es lo mismo que spam. Google dice que los mensajes sin autenticar no son necesariamente spam, y señala que la autenticación a menudo no funciona para organizaciones reales que escriben a listas de correo grandes. Segundo, el aviso habla del dominio del campo De, no de tu asunto, tu redacción ni tu adjunto. Reescribir el correo no lo va a quitar.
Qué revisamos primero, y no es el DNS
Casi todos empiezan pegando su dominio en una herramienta de consulta. Nosotros empezamos por el mensaje que falló, porque dice cuál verificación falló y contra cuál dominio. Un registro de DNS solo no te dice eso.
Pídele a quien lo recibió que abra el mensaje en Gmail en una computadora y elija Mostrar original en el menú del mensaje. Eso muestra el mensaje crudo con sus cabeceras. La línea que hay que leer es Authentication-Results. La guía de Google es buscar ahí spf=pass o dkim=pass; las apps de Gmail también muestran las líneas Enviado por y Firmado por cuando la autenticación funciona, que es más rápido cuando solo necesitas un sí o un no.
Esa cabecera vale más que una hora de suposiciones, porque nombra el dominio contra el que corrió cada verificación. Cuando no coincide con el que ve el cliente, estás ante un problema de alineación.
Relaciona la cabecera con la causa
Con la línea Authentication-Results enfrente, el trabajo es mecánico. Busca tu fila, cambia esa sola cosa y manda otra prueba.
| Qué muestran las cabeceras | Qué significa | Qué cambiar |
|---|---|---|
spf=none y dkim=none | El dominio no publica nada que Gmail pueda verificar, así que todo su correo llega sin autenticar | Publica un registro SPF y luego activa la firma DKIM en el servicio que envía |
spf=fail o spf=softfail con dkim=none | Algo envía desde una dirección que el registro SPF no lista, y nada firma el mensaje | Agrega ese servicio al registro SPF y activa su firma DKIM |
spf=pass para un dominio que no es tuyo, dkim=none | SPF pasó para la plataforma de envío, no para tu dominio del De, y nada queda alineado con la dirección visible | Activa DKIM con tu dominio en esa plataforma y publica la clave en tu DNS |
dkim=fail en correo que pasó por un reenvío o una lista | Se reescribió una cabecera firmada o el cuerpo en tránsito, y rompió la firma | Detén la reescritura, o entrega el correo sin ese salto extra |
spf=pass y dkim=pass, y el aviso sigue ahí | La autenticación está bien. El aviso viene de la configuración de Gmail de quien recibe | Nada en tu DNS. Las dos últimas secciones cubren este caso |
Arreglo 1: un solo registro SPF que liste todo lo que envía por ti
La instrucción de Google para SPF es corta y aun así se rompe seguido: el registro de tu dominio debe incluir todos los remitentes de correo de tu dominio. Una correduría casi siempre tiene más remitentes de los que recuerda: Workspace, el sistema de pólizas, la pasarela de pagos, una herramienta de marketing, el formulario del sitio. Un remitente que quedó fuera del registro es un remitente cuyo correo llega sin autenticar.
Un dominio lleva un registro SPF, no varios. Dos registros v=spf1 en el mismo nombre son un error de configuración según el RFC 7208 y pueden hacer que todas las verificaciones fallen a la vez, así que combina en lugar de agregar una segunda línea.
Tipo: TXT
Nombre: @
Valor: v=spf1 include:_spf.google.com ~allAgrega un mecanismo por servicio, dentro de ese único registro. SPF también tiene un presupuesto: diez consultas de DNS durante su evaluación, y la número once convierte el resultado en un error permanente. Si tu lista de servicios es larga, lee el límite de consultas de SPF y cómo bajar de diez antes de seguir agregando includes.
Arreglo 2: DKIM en todos los servicios, no solo en Workspace
SPF se rompe con facilidad en tránsito, así que DKIM es la que vale la pena dejar bien, y Google la señala como la forma preferida de autenticar. Cada servicio genera una clave, tú publicas la mitad pública como registro TXT bajo un selector, y el servicio firma con la mitad privada.
Tipo: TXT
Nombre: <selector>._domainkey
Valor: v=DKIM1; k=rsa; p=<clave pública del servicio de envío>Dos detalles de la guía de DKIM de Google que corregimos en proyectos de clientes más seguido de lo que nos gustaría. Usa una clave de al menos 1024 bits, con 2048 recomendado, ya que 1024 es el mínimo que Google indica para el correo a cuentas personales de Gmail. Y no uses la etiqueta de longitud l= de DKIM, porque deja el mensaje más fácil de suplantar. El formato del registro está definido en el RFC 6376.
La falla habitual es una plataforma que firma con su propio dominio en lugar del tuyo: una firma DKIM válida que no hace nada por la dirección que ve tu cliente. Lo que explicamos en la guía de SPF, DKIM y DMARC en Workspace aplica igual a herramientas externas, porque la firma tiene que llevar tu dominio.
Arreglo 3: DMARC, para que la decisión sea tuya
SPF y DKIM le permiten a quien recibe verificarte. DMARC es como le dices qué hacer cuando la verificación falla. Google lo describe como publicar una política que les indica a Gmail y a otros proveedores participantes cómo manejar los mensajes sin autenticar enviados desde tu dominio, y recomienda avanzar de monitoreo a cuarentena y a rechazo conforme crece la confianza en la configuración.
Tipo: TXT
Nombre: _dmarc
Valor: v=DMARC1; p=none; rua=mailto:reportes-dmarc@ejemplo.comEl orden importa. La guía de Google indica activar primero SPF o DKIM, esperar 48 horas y solo entonces publicar el registro DMARC. Publicar una política antes de que la autenticación funcione convierte un aviso en correo rechazado.
DMARC también trae la alineación, la razón silenciosa de que muchos mensajes que pasan SPF igual se vean sin autenticar. Las guías para remitentes de Google exigen que el dominio organizacional del campo De coincida con el dominio organizacional que autenticó SPF o DKIM. Si son distintos, tienes un pass en el papel y una falla en la práctica. Los reportes te muestran esto en todos tus remitentes a la vez, y el paso gradual de p=none a p=reject es la manera segura de actuar sobre ellos.
Para quien envía volumen la exigencia es más firme. Las guías de Google piden SPF o DKIM a todo remitente, y las tres juntas a los remitentes masivos, es decir cerca de 5,000 mensajes o más a cuentas personales de Gmail en 24 horas, aunque la política de DMARC puede quedar en none.
Cuando el aviso no es tu culpa
El reenvío es el caso común. La guía de reenvío de Google dice que los mensajes reenviados fallan SPF con frecuencia, porque la verificación corre contra el servidor que reenvía y no contra el original. DKIM sobrevive al reenvío solo si nada cambia las partes firmadas: Google menciona modificar el asunto y otras cabeceras protegidas, y el software que modifica o vuelve a codificar el cuerpo. Las listas que agregan un pie o una etiqueta en el asunto hacen justamente eso.
Hay un caso más sutil. Gmail usa ARC para leer el estado de autenticación que el mensaje traía antes de ser reenviado. Si un mensaje reenviado pasa SPF o DKIM al llegar, pero ARC muestra que ya había fallado antes en el camino, Google dice que Gmail lo trata como no autenticado. Un pass limpio en el último salto no cierra el tema. Google también aclara que la alineación de DMARC no se exige para mensajes reenviados ni de listas de correo, lo que llama correo indirecto. Qué le hace el reenvío a SPF cubre las opciones cuando el reenvío sí está en tus manos.
Cuando el aviso viene del Workspace de quien recibe
Este es el caso que nadie espera, y evita mucho trabajo inútil en el DNS. Una organización que recibe puede configurar Gmail para que agregue avisos por su cuenta. En la consola de administración, en Aplicaciones, Google Workspace, Gmail, Seguridad, las protecciones avanzadas contra phishing y software malicioso incluyen una opción para cualquier mensaje no autenticado, y el administrador elige si deja ese mensaje en la bandeja con un aviso, que es la opción predeterminada, lo manda a spam o lo pone en cuarentena. Esos avisos aparecen en Gmail en la web.
Una segunda función, distinta, produce un aviso que se parece. Las advertencias por destinatarios externos, en Aplicaciones, Google Workspace, Gmail, Acceso del usuario final, están activadas de forma predeterminada y agregan un aviso y marcas de color junto a las direcciones de fuera de la organización, con los contactos y los miembros del directorio exentos. Esa no tiene nada que ver con la autenticación. Si las cabeceras muestran las dos verificaciones en pass, ningún cambio de DNS lo va a quitar; la salida es una conversación con el administrador de quien recibe.
Qué vigilamos las dos semanas siguientes
Dale tiempo a los cambios de DNS y después prueba en lugar de suponer. Manda un correo a una cuenta personal de Gmail, abre Mostrar original y confirma que las líneas de pass estén ahí y nombren tu dominio. Revisa los paneles de autenticación y de tasa de spam en Postmaster Tools, que es donde se delata un remitente a medio arreglar: un servicio alineado y otro todavía sin firmar. Las guías de Google también le piden a quien envía volumen mantener baja la tasa de spam reportada por usuarios y nunca dejar que llegue a 0.3%. Configurar Postmaster Tools y saber leerlo toma unos diez minutos.
Después anota cada servicio que envía con tu dominio, con su mecanismo de SPF y su selector de DKIM. Este aviso regresa un año después porque alguien conectó una herramienta nueva sin tocar el DNS.
Cómo ayuda Guanacos Tech
La mayor parte de este trabajo es lectura, no configuración. El cambio suele ser de dos registros de DNS, pero saber cuáles dos implica leer el mensaje que falló, revisar con qué firma de verdad cada servicio y separar tu problema de la configuración de quien recibe. Lo hacemos como consultoría de entregabilidad de correo, tanto en dominios de Workspace como de Microsoft 365. Agenda una llamada de 30 minutos y trae un mensaje con las cabeceras completas, de alguien que vio el aviso; con eso normalmente nos alcanza para nombrarte la verificación que falla y el servicio detrás.
Fuentes
- Check if your Gmail message is authenticated (Gmail Help)
- Control unauthenticated mail from your domain (Gmail Help)
- Email sender guidelines (Gmail Help)
- Best practices for forwarding email to Gmail (Google Workspace Help)
- Advanced phishing and malware protection (Google Workspace Admin Help)
- Control Gmail external recipient warnings (Google Workspace Help)
- Troubleshoot DKIM issues (Google Workspace Help)
- Set up DMARC (Google Workspace Help)
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures