Comprobar SPF y DMARC: cómo consultar, leer y corregir tus registros

Qué comprueba cada uno: SPF, DKIM y DMARC

SPF y DKIM pueden pasar los dos para un dominio que el lector nunca ve. DMARC cierra ese hueco con la alineación: un mensaje pasa cuando SPF o DKIM pasan para un dominio alineado con el dominio del From, y basta con un resultado alineado. La alineación relajada, la predeterminada, solo exige el mismo dominio organizativo, así que bounce.example.com se alinea con example.com. La alineación estricta exige que coincidan exactamente.

Un servicio de boletines hipotético muestra por qué importa. Envía como news@example.com, pero usa como remitente del sobre su propio dominio de rebotes en example.net. SPF pasa para example.net, que no está alineado, así que DMARC solo pasa si el servicio firma con DKIM como d=example.com.

Si buscas una introducción en español, el INCIBE (Instituto Nacional de Ciberseguridad de España) publicó en 2019 un resumen de estos tres mecanismos pensado para empresas. Es anterior a la especificación actual de DMARC, así que para los detalles de esta guía la referencia es el RFC 9989.

Cómo consultar los registros con dig o nslookup

Basta con dig (Linux, macOS) o nslookup (Windows):

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

El registro SPF es el TXT que empieza por v=spf1; a su lado suele haber tokens de verificación de otros servicios. El registro DMARC es el TXT en _dmarc que empieza por v=DMARC1. Comprueba SPF en el dominio del remitente del sobre, que puede ser distinto del dominio del From; la cabecera Return-Path de un mensaje entregado lo muestra.

Las claves DKIM no se pueden listar desde fuera, porque cada una está bajo un selector. Lee los valores s= y d= de la cabecera DKIM-Signature de un mensaje que hayas enviado y consulta ese nombre, por ejemplo dig +short TXT s1._domainkey.example.com.

Después de un cambio, los resolutores pueden seguir dando la respuesta anterior hasta que caduque su TTL. Para ver lo que está publicado ahora, localiza los servidores autoritativos con dig +short NS example.com y consulta uno directamente: dig +short TXT example.com @ns1.example.net. Después envía un mensaje real a un buzón que controles y lee su cabecera Authentication-Results. Muestra lo que decidió el receptor para SPF, DKIM y DMARC, y ese es el resultado que cuenta.

Cómo leer un registro SPF

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

Los mecanismos se evalúan de izquierda a derecha, y el primero que coincide decide el resultado. Cada uno puede llevar un calificador: + pass (el predeterminado), - fail, ~ softfail, ? neutral.

¿~all o -all?

~all indica que los servidores no listados probablemente no están autorizados, y los receptores no deberían rechazar un mensaje solo por eso. -all indica que no están autorizados; lo que pase después depende de la política de cada receptor. Las dos opciones son razonables, y la BSI (Oficina Federal de Seguridad de la Información de Alemania) acepta cualquiera de ellas. El RFC 9989 añade una advertencia: con -all, un receptor que comprueba SPF al principio de la sesión SMTP puede rechazar un mensaje que una firma DKIM alineada habría hecho pasar, normalmente correo reenviado, y ese rechazo nunca aparece en los informes DMARC. ?all, o no poner all, no dice nada sobre los servidores no listados. +all deja pasar a cualquier dirección IP de internet; no lo publiques nunca.

El límite de 10 consultas

Los receptores evalúan como máximo 10 términos que generan consultas DNS, contando los que hay dentro de los registros incluidos (apartado 4.6.4). Por encima de ese límite el resultado es permerror, y SPF ya no puede ayudar a que un mensaje pase DMARC. Otro límite cubre las consultas que no devuelven respuesta: más de dos también deberían terminar en permerror. Un registro con cuatro términos visibles puede superar el límite si los registros incluidos tienen a su vez otros include, así que cuenta de forma recursiva. Para volver por debajo del límite, quita los servicios que ya no usas, escribe ip4/ip6 para las direcciones que controlas y lleva los servicios de mucho volumen a su propio subdominio de rebotes, con su propio registro SPF. El aplanado (flattening), que copia en tu registro los rangos IP de un proveedor, queda desactualizado cuando el proveedor los cambia.

Un registro por nombre

Dos registros TXT que empiezan por v=spf1 en el mismo nombre producen un permerror; fusiónalos. Un registro de más de 255 caracteres se publica en un único registro TXT dividido en varias cadenas entre comillas, que los receptores unen sin espacios. SPF tampoco se hereda: un registro en example.com no cubre mail.example.com, así que cada nombre que se use como remitente del sobre necesita el suyo.

Cómo leer un registro DMARC

DMARC es ahora el RFC 9989 (mayo de 2026), una especificación del IETF de la categoría Standards Track que sustituye al RFC 7489. El registro sigue en _dmarc y empieza por v=DMARC1:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Un registro en example.com cubre también los subdominios que no tienen uno propio; los receptores lo encuentran con lo que el RFC 9989 llama un recorrido del árbol DNS (DNS Tree Walk). Los receptores que envían informes agregados los entregan como archivos XML, normalmente a diario, con las direcciones IP que enviaron en nombre de tu dominio y sus resultados. Si rua apunta a otro dominio organizativo, como un servicio de informes, ese dominio tiene que publicar un registro TXT como example.com._report._dmarc.reports.example.net que empiece por v=DMARC1 (RFC 9990, apartado 4); si no, los receptores ignoran la dirección.

De none a reject

1. Haz una lista de todos los servicios que envían con el dominio: plataforma de correo, boletines, CRM, facturación, atención al cliente, formularios del sitio web.
2. Publica p=none con rua y lee los informes.
3. Corrige cada fuente legítima hasta que pase con alineación, preferiblemente mediante DKIM, que en general sobrevive al reenvío, mientras que SPF no.
4. Pasa a quarantine, si quieres primero con t=y, y después valora reject.

El RFC 9989 dice que los dominios cuyos usuarios escriben en listas de correo no deberían publicar reject (en el lenguaje del RFC, SHOULD NOT); los que aun así lo quieran deberían pasar antes al menos un mes en none y otro tanto en quarantine, comparando los resultados. Todo dominio que publique reject tiene que firmar su correo con DKIM (MUST). La guía TR-03182 de la BSI adopta la postura más estricta: un dominio que envía correo debería exigir reject. Un dominio que solo se usa para facturas y notificaciones no es el mismo caso que uno que tu equipo usa en listas de correo. El RFC 9989 también pide a los receptores que no rechacen solo por p=reject, pero reconoce que en la práctica el correo de listas con la línea From sin cambios se rechaza a menudo.

Dominios que no envían correo

Los dominios aparcados, los que registras para proteger la marca (por ejemplo, las variantes .es, .mx o .com.ar de tu nombre) y los que solo redirigen pueden aparecer igualmente en un From falsificado. El RFC 7208 considera una buena práctica bien establecida publicar un registro SPF en los dominios que no envían correo. Un conjunto completo para un dominio aparcado hipotético:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

El registro SPF no autoriza a nadie, y p=reject no cuesta nada aquí porque no hay correo legítimo que perder. El MX nulo del RFC 7505 indica que el dominio no acepta correo; por eso los informes van a example.com, que tiene que publicar example.net._report._dmarc.example.com. La BSI TR-03182 exige esta misma combinación para los dominios sin uso. La política DMARC cubre los subdominios, pero SPF no, así que añade también v=spf1 -all a cualquier subdominio que tenga su propio registro A o MX.

Qué exigen Gmail, Yahoo y Outlook.com a quienes envían correo

Desde noviembre de 2025, Gmail ha ido endureciendo la aplicación de estas normas, con rechazos incluidos. Las reglas de Google se refieren a las cuentas personales de Gmail, no a los destinatarios de Google Workspace. Google y Yahoo exigen claves DKIM de al menos 1024 bits. Microsoft rechaza el correo que no cumple sus requisitos con el código 550 5.7.515. Los tres aceptan p=none, que basta para la norma pero no expresa ninguna preferencia sobre el correo falsificado; tómalo como una etapa, no como la configuración final.

MTA-STS y CAA: otros dos registros que conviene revisar

MTA-STS (RFC 8461) protege el correo entrante: indica a los remitentes que no entreguen en tus hosts MX si no ofrecen TLS con un certificado de confianza. Necesita un registro TXT en _mta-sts.example.com, como v=STSv1; id=20261001000000Z;, y un archivo de política en https://mta-sts.example.com/.well-known/mta-sts.txt con el modo, los nombres MX y max_age. Empieza en modo testing, en el que los remitentes siguen entregando e informan de los fallos si tienes configurados los informes TLS en _smtp._tls.example.com, y después pasa a enforce. Cambia el id cada vez que cambie la política.

CAA (RFC 8659) nombra las autoridades certificadoras que pueden emitir certificados TLS para el dominio, por ejemplo CAA 0 issue "ca.example.net". Las CA públicas tienen que consultarlo antes de emitir; no impide que una CA autorizada emita por error, y los navegadores no lo usan. Un registro en example.com cubre los subdominios que no tienen uno propio. Incluye todas las CA que usas, también la de tu CDN, o las renovaciones pueden fallar. La guía de TLS y cabeceras HTTP trata los certificados con más detalle.

Errores habituales de SPF y DMARC y cómo corregirlos

Qué revisa el snapshot gratuito en el DNS de tu correo

El snapshot gratuito ejecuta ocho comprobaciones pasivas sobre un origen público, sin registro. No es un pentest ni la auditoría de seis áreas. Una de las ocho lee los registros DNS del correo:

• Nombre de host exacto. MX, TXT, _dmarc, _mta-sts y CAA se consultan en el nombre que escribes, sin recurrir al dominio principal. Que falte un registro en www.example.com no significa que example.com esté desprotegido. Para que lea los registros de tu dominio de correo, escribe ese dominio (example.com en lugar de www.example.com); tiene que resolver a una dirección IP para que el snapshot dé una puntuación.
• SPF. La falta de registro se marca (riesgo medio) solo si el host tiene registros MX. +all se marca como riesgo alto y ?all como bajo; ~all y -all no generan nada. Más de diez términos con consulta DNS se marcan (riesgo medio), pero solo cuentan los del registro principal, porque no sigue los include:.
• DMARC. La falta de registro se marca (riesgo medio) solo si el host tiene registros MX. p=none se marca como modo de observación (riesgo bajo), y quarantine o reject cuentan como control aprobado. No evalúa sp, pct, rua ni la alineación.
• MTA-STS y CAA. La falta del registro TXT _mta-sts se marca (riesgo bajo) solo si el host tiene registros MX; no descarga el archivo de política. Cualquier registro CAA cuenta como aprobado y su ausencia es una señal baja; no compara su contenido con tu certificado.
• No se comprueban: DKIM, los informes TLS ni DNSSEC.

Obtienes una puntuación con su calificación, la calificación de Refuerzo, el número de señales de riesgo y de controles aprobados, y hasta tres señales, de la más grave a la menos grave, así que un hallazgo del correo puede quedar por detrás de uno de la web. Un nombre que no resuelve a una dirección no recibe puntuación. La checklist de seguridad antes de lanzar una web recorre las ocho comprobaciones, y la guía de DNS y seguridad del correo trata la revisión continua.