Source: https://once-email.com/es/blog/read-spf-dkim-dmarc-results Entrega y autenticación · 27 abr 2025Actualizado 8 ago 2026 # Cómo interpretar SPF, DKIM y DMARC en una cabecera de correo Qué comprueba cada mecanismo, cómo leer Authentication-Results y qué conclusiones no permite obtener. [Equipo de ingeniería de Once Email, Once Email author Equipo de ingeniería de Once Email]() Revisado por Revisión editorial de Once Email Qué te ayuda a hacer esta guía El lector puede localizar resultados, comparar dominios y reconocer fallos normales sin declarar seguro un mensaje solo por pasar controles. Guía del artículo Por qué vale la pena leer este artículo **Análisis original** Separamos autenticación, alineación y evaluación de contenido para evitar que un resultado técnico favorable se convierta en una afirmación de identidad. **Contexto de tendencias** La adopción de DMARC crece por requisitos de grandes receptores, pero el reenvío y los proveedores delegados siguen complicando la interpretación. **Valor práctico** El lector puede localizar resultados, comparar dominios y reconocer fallos normales sin declarar seguro un mensaje solo por pasar controles. SPF, DKIM y DMARC ayudan a los receptores a evaluar si un mensaje está autorizado para utilizar un dominio. No analizan por sí solos si el texto es verdadero, si un enlace es seguro o si la persona que lo envió es quien afirma ser. ## [Empieza por Authentication-Results]() Busca la cabecera ` Authentication-Results ` añadida por un servidor receptor de confianza. Puede incluir resultados como ` spf=pass `, ` dkim=pass ` y ` dmarc=pass `, junto con los dominios evaluados. No confíes automáticamente en una línea incluida más abajo por el emisor: las cabeceras anteriores al primer salto de confianza pueden falsificarse. ## [SPF: autorización de la ruta]() SPF publica qué servidores pueden enviar para el dominio usado en el retorno SMTP, normalmente visible como ` smtp.mailfrom ` o Return-Path. Un ` pass ` significa que la IP observada estaba autorizada por ese dominio en ese momento. No significa que el campo visible ` From ` sea auténtico. Además, el reenvío puede romper SPF porque el servidor intermediario no está incluido en la política del dominio original. Resultados ` neutral `, ` softfail `, ` fail `, ` temperror ` y ` permerror ` describen decisiones distintas; no deben agruparse como un único fallo. ## [DKIM: firma de dominio]() DKIM añade una firma criptográfica vinculada a un dominio (` d= `) y un selector (` s= `). El receptor obtiene la clave pública por DNS y comprueba que las partes firmadas no cambiaron de forma incompatible. Un ` pass ` confirma que la firma verificó, no quién pulsó «enviar». Proveedores legítimos firman en nombre de muchos clientes, y un dominio comprometido también puede producir firmas válidas. Las listas de correo pueden modificar asuntos o cuerpos y romper una firma legítima. ## [DMARC: alineación con el From visible]() DMARC toma SPF y DKIM y exige que al menos uno pase **y** esté alineado con el dominio visible de ` From `. La alineación compara dominios organizativos según una política estricta o relajada. El propietario publica además una recomendación: monitorizar (` p=none `), enviar a cuarentena o rechazar. ` dmarc=pass ` indica que hubo una ruta autenticada y alineada. No certifica el nombre mostrado, la cuenta concreta ni la seguridad del contenido. ## [Un orden de lectura útil]() 1. Identifica qué sistema añadió ` Authentication-Results `. 2. Anota el dominio visible de ` From `. 3. Para SPF, compara ` smtp.mailfrom ` y la IP evaluada. 4. Para DKIM, revisa cada dominio ` d= `; puede haber varias firmas. 5. Comprueba qué mecanismo permitió la alineación DMARC. 6. Relaciona el resultado con la cadena ` Received ` y el contexto esperado. No publiques una cabecera completa. Puede contener direcciones, identificadores, IP y tokens de listas. El [analizador de cabeceras]() trabaja localmente, pero aun así conviene eliminar datos que no necesites. ## [Ejemplos de conclusiones correctas]() - «DKIM pasó para el dominio del proveedor y quedó alineado con From» es una observación técnica. - «El correo es seguro porque DMARC pasó» es una conclusión excesiva. - «SPF falló después de un reenvío, pero DKIM alineado permitió DMARC» puede ser completamente normal. - «No hay DMARC» no demuestra fraude; indica que falta esa señal concreta. Consulta [RFC 7208]() , [RFC 6376]() y [RFC 7489]() para las definiciones normativas. La interpretación práctica siempre debe combinar autenticación, ruta, contenido y una verificación independiente cuando la solicitud sea sensible. ## Guías relacionadas ¿No llega el correo de verificación? Lista segura de diagnóstico Un orden de comprobación para encontrar un mensaje retrasado sin solicitar códigos repetidamente ni exponer información sensible. [¿No llega el correo de verificación? Lista segura de diagnóstico]() Cómo leer cabeceras Received y seguir la ruta de entrega de un correo Un método para reconstruir saltos, tiempos y servidores sin confundir la ruta técnica con la identidad del remitente. [Cómo leer cabeceras Received y seguir la ruta de entrega de un correo]() Postfix vs Dovecot: funciones distintas en un servidor de correo entrante Ubica Postfix, Dovecot, LMTP, la cola e IMAP en la ruta de entrada y decide con evidencias dónde falla una entrega. [Postfix vs Dovecot: funciones distintas en un servidor de correo entrante]() ## Herramientas de correo centradas en la privacidad Analizador de cabeceras de correo Explica los saltos de entrega y resume SPF, DKIM y DMARC sin afirmar una autenticidad absoluta. [Analizador de cabeceras de correo]() [Cómo inspeccionar enlaces y píxeles de seguimiento sin abrirlos Un método local para revisar destinos, parámetros y recursos remotos de un correo sin convertir el análisis en una visita.]() [Política editorial y de revisión de Once Email Cómo seleccionamos temas, comprobamos afirmaciones, corregimos errores y separamos contenido educativo de promoción y publicidad.]()