---
title: "SPF y DMARC: cómo leer los registros DNS de correo | Emvero"
description: "Conozca la diferencia entre SPF y DMARC, por qué SPF puede pasar y DMARC fallar, y cómo interpretar los registros MX y de autenticación de un dominio."
url: https://emvero.io/es/blog/spf-vs-dmarc/
language: es
updated: 2026-10-09
---

Blog

# SPF y DMARC: qué indican los registros DNS de un dominio

SPF autoriza a los hosts que envían correo. DMARC comprueba la alineación con el dominio del From visible. El artículo explica cómo interpretar esos registros junto con MX.

Publicado 2026-09-27

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](https://www.rfc-editor.org/rfc/rfc7208.html#section-2) y en el [modelo de validación de DMARC](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.1).

Para recibir correo, SMTP consulta los destinos MX al elegir una ruta. Las [reglas de enrutamiento SMTP](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1) y el [glosario de registros MX](https://emvero.io/es/glossary/mx-record/) 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](https://emvero.io/es/blog/how-to-find-email-provider/) 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-5).

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](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4).

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](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7).

## 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](https://knowledge.workspace.google.com/admin/security/set-up-dmarc).

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](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.5) y la [guía de Google sobre alineación DMARC](https://knowledge.workspace.google.com/admin/security/set-up-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](https://docs.emvero.io/using/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](https://emvero.io/es/blog/domain-without-mx-record/) detalla cómo SMTP puede usar una ruta implícita. Una [declaración null MX](https://www.rfc-editor.org/rfc/rfc7505.html#section-3) 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](https://emvero.io/es/compare/full-check-vs-domain-check/). 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](https://emvero.io/es/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.

## Términos que aparecen aquí

### Registro MX

Un registro DNS que indica a qué servidor dirigir el correo de un dominio.

### Fallo de DNS

Una consulta DNS no aporta datos útiles; el resultado depende de si falta el nombre o la consulta ha fallado temporalmente.

[Todos los artículos](https://emvero.io/es/blog/)

## Elige qué comprobar ahora.

Haz una consulta desde tu cuenta y examina los datos del resultado.

Empezar gratis