Imagina una correduría de seguros de 14 personas que llama un lunes. Dos clientes juran que los avisos de renovación nunca llegaron, un tercero los encontró en correo no deseado y el resto los recibió sin problema. Alguien del equipo manda una captura de pantalla del mensaje. Una captura no responde nada. Lo único que resuelve el caso es la cabecera cruda de un mensaje que sí falló, sacada del buzón que lo recibió, no de la carpeta de enviados de quien lo mandó.
Las cabeceras parecen ruido la primera vez que abres una. No lo son. Casi todos los casos de correo legítimo que cae en spam se reducen a una de cuatro lecturas, y cada una vive en una línea concreta. Este es el orden en que las leemos, y lo que cada línea puede probar de verdad.
Pide el mensaje correcto antes de leer nada
La mayoría de las horas perdidas en un caso de entregabilidad se van analizando el artefacto equivocado. Tres reglas que aplicamos antes que nada:
- La cabecera tiene que venir del lado que recibe. Una copia de la carpeta de enviados nunca pasó por los filtros del destinatario, así que no trae ninguno de los veredictos que necesitamos. Si el mensaje iba a un cliente en Gmail, ese cliente es quien tiene que sacarla.
- Tiene que ser un mensaje que realmente falló. No una prueba que te mandaste hace cinco minutos desde la misma red. Un mensaje que llegó bien sirve como control, pero no explica la falla.
- Copia el bloque completo. La gente suele copiar las primeras diez líneas. La cadena de
Received, el veredicto de autenticación y las anotaciones del filtro están repartidos por todo el bloque, y cortarlo elimina justo la parte que importa.
Si el mensaje rebotó en lugar de caer en spam, el texto del rebote vale más que la cabecera. Ese es otro camino de diagnóstico, y los rechazos de Gmail por reputación los cubrimos en la guía del error 550 5.7.1.
Cómo sacar el código fuente en Gmail, Outlook y Yahoo
Cada proveedor lo esconde en un lugar distinto, y el texto del menú cambia más seguido que la función.
Gmail. Abre el mensaje, haz clic en Más junto a Responder y elige Mostrar original. La ayuda de Google lo documenta como rastrear un correo con su cabecera completa, y la ventana que se abre trae el código fuente entero, con un botón para copiarlo. Hazlo en Gmail desde una computadora: la vista de código fuente vive en el cliente web de escritorio, así que si quien recibió el mensaje fallido solo tiene el teléfono, que abra Gmail en el navegador o reenvíe el mensaje a alguien con computadora.
Outlook y Microsoft 365. Abre el mensaje, entra en Más acciones (More actions), luego Ver (View) y luego Ver detalles del mensaje (View message details), que muestra las cabeceras de internet. La página de soporte de Microsoft sobre cabeceras de internet en Outlook describe la cabecera como la lista de detalles técnicos del mensaje: quién lo envió, con qué se redactó y por qué servidores de correo pasó.
Yahoo Mail. Abre el mensaje, entra en el menú de más opciones y elige ver el mensaje sin formato (View Raw Message). La ayuda de Yahoo presenta las cabeceras completas como la forma de encontrar un retraso de entrega o al remitente real de un correo, que son exactamente los dos trabajos que vamos a hacer con ellas.
Pega el bloque en algo con tipografía monoespaciada. El ajuste de línea de una ventana de chat parte una línea Received a la mitad de una dirección IP y te cuesta diez minutos.
La cadena Received: por dónde pasó y cuánto esperó
Las líneas Received se leen de abajo hacia arriba. El salto más antiguo, el más cercano al remitente, queda hasta abajo, y cada servidor que manejó el mensaje estampó una línea nueva encima. La ayuda de Yahoo describe el mismo orden: la primera entrega abajo, la más reciente arriba.
Tres cosas que sacamos de la cadena:
- El origen real. El salto de hasta abajo, junto con el remitente de sobre, es la respuesta honesta a "de dónde salió esto". El encabezado
From:es decoración en comparación, porque cualquiera puede escribir lo que quiera ahí. - Saltos que no deberían estar. Un gateway de seguridad, una regla de reenvío que nadie documentó, un relay en el hosting viejo que supuestamente se iba a dar de baja. Cada salto extra es otra oportunidad de romper una firma.
- Huecos de tiempo. Un mensaje que tardó cuatro horas entre dos saltos no fue filtrado como spam, estuvo en cola, y eso se arregla de otra forma. El Messageheader del Admin Toolbox de Google dibuja los saltos con el retraso de cada uno, así el eslabón lento salta a la vista sin hacer cuentas.
Authentication-Results: la línea que resuelve casi todo
Es la línea más valiosa de la cabecera. La escribe el servidor que recibe, con sus propias palabras, registrando lo que concluyó sobre el mensaje. Un ejemplo simplificado de cómo se ve en un mensaje que falla:
Authentication-Results: mx.receptor-ejemplo.com;
spf=pass smtp.mailfrom=bounces.plataforma-cotizaciones.example;
dkim=pass header.d=plataforma-cotizaciones.example;
dmarc=fail (p=NONE) header.from=correduria-ejemplo.comLéela campo por campo. spf=pass significa que la IP que envió estaba autorizada por el registro SPF del dominio del remitente de sobre, que es el valor smtp.mailfrom, no necesariamente el dominio que ve tu destinatario. dkim=pass significa que una firma verificó, y header.d dice de quién era la llave que firmó. dmarc es el veredicto que combina las dos con el dominio de la dirección From: visible, que aparece como header.from.
La ayuda de Gmail lo dice en menos palabras: busca el encabezado Authentication-Results y, si el mensaje se autenticó, verás spf=pass o dkim=pass. La trampa es suponer que esos dos pass cierran el caso.
Cuando SPF y DKIM pasan y DMARC igual falla
Mira otra vez el ejemplo. SPF pasó. DKIM pasó. DMARC falló de todos modos, y el motivo está a la vista: cada verificación que pasó pertenece a plataforma-cotizaciones.example, mientras que la dirección que el cliente ve es de correduria-ejemplo.com. Ese desajuste es una falla de alineación, y en nuestra experiencia es el hallazgo más frecuente en una cabecera que nos pasan.
El RFC 7489 define la alineación en dos modos. En modo relajado, el dominio organizacional del dominio firmante de DKIM, tomado de la etiqueta d=, debe ser igual al dominio organizacional de la dirección From:, que es lo que permite que los subdominios de un dominio verificado sigan alineando. En modo estricto los dominios deben coincidir exactamente.
La versión práctica: una plataforma externa que envía en tu nombre va a pasar su propio SPF y firmar con su propia llave, y nada de eso cuenta para tu dominio a menos que configures en esa plataforma un dominio de envío y una llave DKIM a tu nombre. La mayoría de las herramientas de facturación, CRM, tiendas y marketing lo permiten, bajo un nombre como dominio de envío personalizado o autenticación de dominio. El juego de registros cambia según el proveedor, por eso escribimos la solución exacta para Mailchimp, HubSpot y Klaviyo.
Cuando DKIM falla de plano en correo enviado con Google Workspace, las causas son una lista más corta y las recorremos en orden en la guía de DKIM en Workspace.
Reenvíos y listas de correo: fallas que no son culpa tuya
Antes de desarmar un registro DNS, revisa si el mensaje fue reenviado. Cuando un buzón reenvía de forma automática, el servidor que reenvía manda desde su propia IP mientras el dominio del From: sigue siendo el tuyo, así que SPF falla en el receptor final sin que tú hayas hecho nada mal. Las listas de correo van más lejos y modifican el mensaje, lo que además rompe la firma DKIM.
ARC, definido en el RFC 8617, existe justo para este caso. Un intermediario registra los resultados de autenticación que observó antes de tocar nada, en un encabezado ARC-Authentication-Results, firma esa foto con ARC-Message-Signature y sella la cadena con ARC-Seal. Si encuentras encabezados ARC en un mensaje fallido, la historia suele ser el reenvío, no un registro roto.
Las anotaciones del propio filtro
Algunos receptores muestran su razonamiento. En un mensaje que pasó por Microsoft 365 vas a encontrar un encabezado X-Forefront-Antispam-Report formado por pares de campo y valor separados por punto y coma. La documentación de Microsoft sobre cabeceras antispam explica las que vale la pena conocer: SCL, el nivel de confianza de spam, estampado como -1 o un valor de 0 a 9, donde 5 o más indica en general que el mensaje se considera malo; BCL, el nivel de quejas por correo masivo, que marca el correo gris, donde un valor más alto significa comportamiento más parecido al spam; y CAT, la categoría, que identifica qué filtró el mensaje. Microsoft también aclara que en organizaciones en la nube el valor de SCL ya no tiene el peso que tenía y por sí solo no determina el veredicto de spam, así que tómalo como pista. Gmail no publica un puntaje equivalente en la cabecera: cuando el receptor es Gmail y toda la autenticación pasa, lo siguiente que hay que mirar es reputación y volumen, no DNS.
Suplantación o mala configuración
Las dos producen dmarc=fail, y confundirlas te manda por el camino equivocado durante un día. La cabecera las separa.
La mala configuración se ve como una falla que viene de infraestructura que reconoces: tu propia plataforma de correo, tu herramienta de facturación, la tienda que sabes que manda confirmaciones de pedido. El host que envía, en la línea Received de hasta abajo, es algo que pagas. La suplantación se ve como una falla desde infraestructura que nunca habías oído nombrar, muchas veces con un Reply-To distinto del From:, y suele llegar en ráfagas. Una es un registro que hay que arreglar. La otra es motivo para llevar tu política DMARC a aplicación, paso a paso, como explicamos en pasar DMARC de p=none a p=reject.
Lo que una sola cabecera no te puede decir
Una cabecera es un mensaje, visto por un receptor, en un momento. No te dice qué porcentaje de tu correo falla, qué sistemas envían a tu nombre a lo largo de un mes, ni si tu tasa de quejas es el problema real. Las guías para remitentes de Gmail fijan umbrales que ninguna cabecera muestra: a quien envía alrededor de 5,000 mensajes o más al día a cuentas personales de Gmail se le trata como remitente masivo, y Gmail pide mantener la tasa de spam que reporta Postmaster Tools por debajo de 0.3 por ciento, con 0.1 por ciento como meta a la que apuntar.
Para la vista completa, el instrumento son los reportes agregados de DMARC, no las cabeceras. Cubren todas las fuentes a la vez con un resultado para cada una, y leemos varias semanas antes de cambiar cualquier política. Si nunca has abierto uno, empieza por cómo leer un reporte DMARC agregado. Y si la verificación que falla es SPF, confirma que el registro no se haya pasado del presupuesto de diez consultas, tema de la guía del límite de consultas SPF.
Cómo ayuda Guanacos Tech
Hacemos esto para empresas pequeñas y medianas en Norteamérica y Latinoamérica, en inglés y español: leer las cabeceras del lado que recibe, nombrar la verificación que falla, rastrearla hasta el sistema que la provocó, arreglar los registros y luego vigilar los reportes DMARC hasta que el panorama se sostenga. Si tienes un mensaje que se fue a spam, pega su cabecera en el analizador de arriba o agenda una llamada y la leemos contigo. El servicio completo está descrito en nuestra página de entregabilidad de correo.
Fuentes
- Gmail Help: Trace an email with its full header
- Gmail Help: Check if your Gmail message is authenticated
- Microsoft Support: View internet message headers in Outlook
- Microsoft Learn: Anti-spam message headers
- Yahoo Help: Find delivery delays and identify sender in Yahoo Mail
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8617: The Authenticated Received Chain (ARC) Protocol
- Gmail Help: Email sender guidelines