MX, SPF, DKIM y DMARC explicados: cómo encajan entre sí

Cuatro tipos de registros DNS deciden cómo se entrega el correo de su dominio y si los receptores creen que de verdad es suyo. Suelen explicarse de uno en uno, y así se pierde lo más importante: cada uno cubre un hueco que los otros dejan abierto.

Esta guía recorre los cuatro, los errores que más aparecen en zonas reales y un orden de despliegue que no pone en riesgo el correo legítimo.

La versión corta

MX indica dónde debe entregarse el correo dirigido a su dominio.
SPF indica qué servidores pueden enviar correo usando su dominio en el remitente del sobre.
DKIM añade una firma criptográfica que demuestra que un mensaje fue autorizado por un dominio y no se alteró por el camino.
DMARC vincula SPF y DKIM con la dirección From que la gente ve de verdad, dice a los receptores qué hacer cuando ambos fallan y le envía informes a usted.

MX trata de recibir. Los otros tres tratan de enviar.

MX: adónde va el correo

$ dig +short MX example.com
10 mx1.mail.example.net.
20 mx2.mail.example.net.

Los remitentes prueban primero el número de preferencia más bajo y pasan a los más altos si falla. Los números iguales se reparten la carga.

Reglas que importan:

El destino de un registro MX debe ser un nombre de host con registro A o AAAA. No puede ser una dirección IP ni un CNAME.
Si no existe ningún registro MX, los remitentes recurren al registro A/AAAA del propio dominio. Casi nunca es lo que se quiere.
Un dominio que nunca debe recibir correo puede publicar un MX nulo: 0 . (preferencia cero, destino un solo punto). Los remitentes fallan entonces de inmediato en lugar de reintentar durante días.

SPF: qué servidores pueden enviar

SPF es un único registro TXT en el dominio:

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

El servidor receptor toma el dominio del remitente del sobre (el Return-Path, no la cabecera From visible), obtiene su registro SPF y comprueba si la dirección IP que se conecta coincide. El all del final decide qué pasa con todos los demás: -all significa fallo, ~all fallo leve (softfail) y ?all sin opinión.

Lleva dos limitaciones de fábrica:

SPF comprueba un dominio que el destinatario nunca ve. Por sí solo no hace nada para impedir que alguien falsifique su dirección From visible.
SPF se rompe con el reenvío. Cuando un mensaje se reenvía, es la IP del reenviador la que se conecta al receptor final, y esa IP no está en su registro.

DKIM: una firma que viaja con el mensaje

Con DKIM, el servidor de envío firma con una clave privada ciertas cabeceras y el cuerpo, y añade una cabecera DKIM-Signature. La clave pública vive en el DNS:

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

s2026 es el selector. Es una etiqueta arbitraria elegida por el sistema que envía, y aparece en la cabecera de la firma como s=s2026 junto al dominio firmante d=example.com. Un dominio puede tener cuantos selectores quiera: uno por servicio de envío y uno por cada rotación de clave.

De ahí sale una consecuencia con la que mucha gente tropieza: no se puede consultar "el registro DKIM" de un dominio. El DNS no tiene forma de enumerar los nombres que cuelgan de _domainkey. Hace falta el selector, y la manera fiable de conseguirlo es abrir las cabeceras de un mensaje que el dominio haya enviado de verdad.

DKIM sobrevive al reenvío simple porque la firma viaja con el mensaje. Se rompe cuando un intermediario modifica el contenido firmado, que es lo que hacen muchas listas de correo al añadir un pie o una etiqueta en el asunto.

DMARC: alineación, política e informes

DMARC es un registro TXT en _dmarc:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Añade tres cosas.

Alineación. Un mensaje supera DMARC si SPF pasa y el dominio del sobre está alineado con el dominio del From, o bien si DKIM pasa y el dominio d= está alineado con el dominio del From. Basta un resultado positivo alineado. Por defecto la alineación es relajada, de modo que mail.example.com se considera alineado con example.com.

Política. p=none pide a los receptores que no hagan nada; p=quarantine, que traten los fallos como sospechosos (normalmente, carpeta de spam), y p=reject, que rechacen el mensaje. sp= fija una política aparte para los subdominios.

Informes. Los receptores envían a la dirección rua informes agregados diarios en XML: qué IP enviaron correo diciendo ser usted, cuántos mensajes, y si SPF y DKIM pasaron y estaban alineados. Con esos informes se descubren los remitentes de los que uno se había olvidado.

La alineación es el motivo de que un mensaje pueda "pasar SPF" y aun así fallar DMARC. Una plataforma de boletines que usa su propio dominio de rebotes pasa SPF para su dominio, que no está alineado con el de usted. El arreglo habitual es configurar un return-path personalizado o, mejor, la firma DKIM con su propio dominio en esa plataforma.

Los errores que más vemos

Varios registros SPF

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ~all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

Dos registros que empiezan por v=spf1 son un error permanente (permerror). SPF falla para todos los mensajes. Suele ocurrir cuando alguien sigue al pie de la letra la guía de configuración de un proveedor nuevo. Hay que fusionarlos en un solo registro con ambos include.

El límite de 10 consultas

Un receptor puede hacer como máximo diez consultas DNS mientras evalúa SPF. include, a, mx, exists, redirect y ptr cuentan cada uno, y los include se anidan: un solo include de un proveedor puede costar tres o cuatro consultas por sí mismo. ip4, ip6 y all no cuestan nada. Si se pasa de diez, el resultado vuelve a ser permerror.

Soluciones, por orden de preferencia: eliminar los servicios que ya no se usan; mover los envíos masivos a un subdominio con su propio registro SPF; apoyarse en DKIM alineado para los servicios que lo admitan y quitar su include. Cuidado con el "SPF flattening", que copia las IP del proveedor en su registro: se queda obsoleto sin avisar cuando el proveedor cambia sus rangos.

`+all`

v=spf1 +all autoriza a todos los servidores de Internet. Es peor que no tener registro, porque afirma activamente que el correo falsificado es legítimo. ?all no es mucho mejor.

El mecanismo `ptr`

Lento, poco fiable y desaconsejado por la propia especificación de SPF. Elimínelo.

`p=none` para siempre

p=none es un modo de observación. Proporciona informes y ninguna protección: cualquiera puede seguir poniendo su dominio en la línea From, y los receptores lo entregarán igual que lo habrían hecho sin DMARC. Muchos dominios publican p=none para cumplir con una lista de requisitos para remitentes masivos y no pasan de ahí. Si los informes llevan semanas limpios, no hay motivo para quedarse.

Olvidar los dominios que no envían correo

Los dominios aparcados y los que solo se usan para webs se suplantan precisamente porque nadie los vigila. Ciérrelos:

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject"
example.org.         MX   0 .

Desplegar DMARC sin sustos

Haga inventario de sus remitentes. Proveedor de buzones, correo de la web y de las aplicaciones, CRM, herramienta de boletines, facturación, soporte, alertas de monitorización. Los que se olvidan son los que se rompen.
Arregle SPF. Un solo registro, menos de diez consultas, terminado en ~all o -all.
Active DKIM en todas partes. En cada servicio, habilite la firma con su dominio en d=. Es lo más importante, porque DKIM es lo que mantiene DMARC en verde a través de los reenvíos.
Publique p=none con una dirección rua. Use un buzón o un servicio que procese los informes; el XML en bruto es desagradable de leer a mano.
Lea los informes durante dos a cuatro semanas. Busque las fuentes legítimas que fallan la alineación. Corrija cada una en origen.
Pase a p=quarantine. Use pct= para ir de forma gradual si su volumen es grande: por ejemplo 10, después 50, después 100. Siga leyendo los informes.
Pase a p=reject. Decida por separado si los subdominios necesitan su propia política sp=.
Siga vigilando. Las herramientas nuevas se adoptan sin que nadie avise a quien lleva el DNS. Por los informes es como uno se entera.

Cuente con un pequeño residuo de fallos que no podrá arreglar, sobre todo de listas de correo y reenviadores peculiares. Muchos receptores los gestionan con ARC o con heurísticas locales. Es una razón para avanzar con cuidado, no para quedarse en p=none.

Lo que los registros no pueden hacer

Unos registros MX, SPF, DKIM y DMARC correctos significan que los receptores pueden verificar que el correo está autorizado por su dominio. No significan que el correo llegue a la bandeja de entrada. Los proveedores de buzones valoran además la reputación del dominio y de las IP de envío, las tasas de quejas, la calidad de las listas, el contenido y cómo interactúan los destinatarios con sus mensajes. Nada de eso vive en el DNS.

La autenticación es la entrada. Los grandes proveedores ya la exigen a los remitentes masivos, y sin ella se le filtra antes de considerar cualquier otra cosa. Con ella, se le juzga por cómo envía realmente. Si sus mensajes ya están acabando en la carpeta de correo no deseado, la lista de comprobación DNS para correos que llegan a spam recorre el diagnóstico paso a paso.

Una comprobación de DNS tampoco puede demostrar que el correo esté fluyendo. Puede mostrar que la política publicada es coherente, que es la parte que se controla desde la zona.

Compruébelo con OrbitProbe

La consulta MX de OrbitProbe lee los registros MX, SPF y DMARC de un dominio y señala los problemas descritos arriba: varios registros SPF, demasiadas consultas, +all, un registro DMARC ausente o una política atascada en p=none. Para DKIM, busque el selector en las cabeceras de un mensaje enviado y consulte selector._domainkey.sudominio como registro TXT. Si quiere saber cuándo cambian estos registros, una vigilancia de cambios DNS en el espacio de trabajo guarda el historial.

Para repasar cómo se escriben estos registros en la zona, véase tipos de registros DNS; y antes de editarlos, recuerde que los cambios tardan lo que marque el TTL.