SPF (Sender Policy Framework) describe qué hosts pueden enviar correo usando un dominio en el sobre SMTP. DMARC (Domain-based Message Authentication, Reporting, and Conformance) comprueba si una identidad que pasa SPF o DKIM está alineada con el dominio de la dirección From visible. También publica una política para los mensajes que no superan esa comprobación. MX responde a otra pregunta: adónde debe ir el correo entrante del dominio.
Al revisar el dominio de un cliente con Domain Intelligence, conviene empezar por la pregunta que se quiere resolver. MX describe la ruta de entrada; SPF y DMARC, la configuración de envío. Para comprobar un buzón concreto hace falta evidencia sobre la dirección de correo.
La diferencia entre SPF, DMARC y MX
| Registro | Pregunta principal | Qué no demuestra su publicación por sí sola |
|---|---|---|
| MX | ¿Adónde debe ir el correo dirigido a este dominio? | Que exista un buzón concreto o que un servidor acepte un mensaje |
| SPF | ¿Está autorizado el host de envío para usar la identidad de dominio SMTP? | Que el dominio del From visible esté autenticado |
| DMARC | ¿Una identidad que pasa SPF o DKIM está alineada con el dominio del From visible? |
Que un mensaje concreto haya pasado la autenticación o llegado a la bandeja de entrada |
SPF usa la identidad SMTP MAIL FROM y también puede comprobar HELO. DMARC usa el dominio del From visible. Estas funciones aparecen en la descripción del funcionamiento de SPF y en el modelo de validación de DMARC.
Para recibir correo, SMTP consulta los destinos MX al elegir una ruta. Las reglas de enrutamiento SMTP y el glosario de registros MX explican ese proceso.
Leer los registros de un dominio sin mezclar sus funciones
La siguiente configuración DNS es ficticia. Todos los nombres usan el espacio reservado .example; sirve como ilustración, no como configuración para copiar en producción.
atelier.example. IN MX 10 inbound.gateway.example.
atelier.example. IN TXT "v=spf1 include:_spf.sender.example -all"
_dmarc.atelier.example. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s"
El MX indica un destino de entrada. Puede ser una pasarela de filtrado situada delante de otro servicio de buzones. El servicio de envío que aparece en SPF puede ser distinto del que recibe el correo. El artículo sobre cómo identificar al proveedor de correo a partir de MX explica los límites de esa atribución.
El mecanismo SPF include pide al evaluador que consulte la política SPF de otro dominio. El -all final da un resultado SPF fail si la evaluación llega hasta él sin encontrar una coincidencia anterior. Para evaluar una transacción real hacen falta la IP de envío, la identidad SMTP y la política referenciada. Ver el registro es solo el punto de partida. RFC 7208 define estos mecanismos.
El registro DMARC publica p=reject y elige alineación estricta con aspf=s y adkim=s. La alineación estricta exige dominios idénticos; la relajada permite dominios que comparten el mismo dominio organizativo. La política afecta a mensajes con atelier.example en el From visible, no a mensajes dirigidos a atelier.example. DMARC define por separado la alineación y la política.
Los otros valores de política son none, que no expresa una preferencia de tratamiento para los fallos de DMARC, y quarantine, que considera sospechosos esos mensajes. El receptor también aplica sus propias reglas; el valor publicado no garantiza la entrega. Valores de política DMARC.
SPF puede pasar mientras DMARC falla
Supongamos que un servicio de envío entrega un mensaje con estas identidades:
Visible From: hello@atelier.example
SMTP MAIL FROM: bounce@sender.example
SPF result for sender.example: pass
DKIM: no passing aligned signature
Es un escenario ficticio de un mensaje, no un resultado de Domain Intelligence. Se da por hecho que el receptor ha comprobado que SPF pasa para sender.example. Ese dominio es distinto de atelier.example, por lo que el resultado SPF no cumple la alineación DMARC. Sin una firma DKIM válida y alineada, el mensaje falla DMARC. La guía de Google explica este requisito de alineación SPF.
Añadir un servicio a la lista SPF include de atelier.example no cambia la identidad MAIL FROM del mensaje. Hay que comprobar qué dominio usa realmente el servicio en el sobre SMTP.
DKIM (DomainKeys Identified Mail) autentica un dominio firmante mediante una firma del mensaje. Si el mensaje tiene una firma DKIM válida cuyo dominio d= es atelier.example, ese resultado alineado puede satisfacer DMARC aunque la identidad SPF no esté alineada. Basta con que pase un mecanismo y su identidad esté alineada. Lo explican la especificación de la firma DKIM y la guía de Google sobre alineación DMARC.
Qué evidencia aporta Domain Intelligence
Domain Intelligence de Emvero lee la ruta de correo y los registros MX, identifica al proveedor de entrada visible cuando lo reconoce y devuelve los campos admitidos de los registros SPF y DMARC publicados. No abre una sesión SMTP ni autentica un mensaje.
| Campo del perfil | Cómo interpretarlo |
|---|---|
mail_routing.status |
routable indica que DNS ofrece una ruta de correo; no se ha comprobado si se acepta al destinatario |
SPF present y syntax |
Si se observó el registro y se pudo comprobar su sintaxis de publicación |
SPF includes, redirect, all_qualifier |
Partes extraídas del registro; las políticas SPF referenciadas no se evalúan de forma recursiva |
DMARC policy_domain e inherited |
Dónde se encontró la política y si es heredada |
DMARC published_policy y effective_policy |
Política publicada y política efectiva tras aplicar las reglas de búsqueda y política admitidas; ninguna es un veredicto sobre un mensaje |
SPF/DMARC evaluation |
not_performed: no se ejecutó una prueba de autenticación de un remitente o mensaje |
Un perfil partial puede conservar una ruta conocida aunque otra observación no esté disponible. Lea los metadatos del campo afectado, incluidos observed_at, expires_at y stale. Un dato obsoleto describe una observación anterior; con unknown, la pregunta sigue sin resolverse. Ninguno de esos estados justifica una conclusión negativa en la aplicación.
La guía de la respuesta de Domain Intelligence documenta esos campos. El perfil no incluye comprobación DKIM, monitorización DMARC, evaluación de la reputación de envío ni pruebas de llegada a la bandeja de entrada.
Elegir la evidencia según la decisión
Para saber si un dominio tiene una ruta de correo entrante, hay que empezar por el enrutamiento. Que falten registros SPF o DMARC no demuestra que el dominio no pueda recibir correo. Una política p=reject tampoco cierra sus buzones.
Si no hay MX, la explicación sobre el dominio sin registro MX detalla cómo SMTP puede usar una ruta implícita. Una declaración null MX indica expresamente que el dominio no acepta correo.
Si la pregunta se refiere a una dirección concreta, hay que elegir entre una verificación completa y una comprobación de dominio. La evidencia del dominio termina antes del buzón; una verificación completa puede obtener evidencia sobre la aceptación del destinatario cuando el servidor de destino lo permite.
Para investigar un problema de autenticación del envío, examine un mensaje real en un sistema receptor que controle. Compare el dominio del sobre, el From visible, el dominio firmante DKIM y los resultados de autenticación. La publicación DNS por sí sola no ofrece esos resultados.
Para revisar la configuración del dominio, abra Domain Intelligence en su cuenta de Emvero. Lea primero la ruta y después las observaciones SPF y DMARC, con el estado y la vigencia de cada una.