Registros TXT explicados: SPF, DKIM y DMARC

Un registro TXT contiene texto arbitrario asociado a un nombre de dominio. Parece trivial, pero así es como se publica todo el sistema de confianza del correo electrónico, además de la mayor parte de las verificaciones de propiedad de dominio que harás jamás.

El problema de fondo es que SMTP, diseñado en 1982, permite que cualquier servidor afirme enviar en nombre de cualquier dominio. Nada en el protocolo lo impide. SPF, DKIM y DMARC son tres capas añadidas después para corregirlo, y las tres viven en registros TXT.

SPF: qué servidores pueden enviar en tu nombre

SPF (Sender Policy Framework) publica una lista de los servidores autorizados a enviar correo en nombre de tu dominio. Un servidor receptor compara la IP que se conecta con esa lista.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.34 ~all"

DKIM: una firma criptográfica

DKIM (DomainKeys Identified Mail) firma cada mensaje saliente con una clave privada. Tú publicas la clave pública correspondiente en el DNS y los receptores verifican la firma.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

La parte selector1 la elige tu proveedor de correo y se incluye en cada mensaje firmado, de modo que los receptores saben qué clave obtener. Usar selectores permite rotar claves, o trabajar con varios proveedores, sin conflictos.

La ventaja de DKIM sobre SPF es que la firma cubre el propio mensaje, así que sobrevive a los reenvíos. Su debilidad es que no dice nada sobre los mensajes que llegan sin ninguna firma, que es el hueco que cierra DMARC.

DMARC: qué hacer cuando fallan los dos primeros

DMARC (Domain-based Message Authentication, Reporting and Conformance) une a los otros dos: exige que SPF o DKIM no solo pasen, sino que se alineen con la dirección From visible, e indica a los receptores qué hacer en caso de fallo.

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100"

Cómo implantar los tres con seguridad

El orden importa. Ir directamente a p=reject es la forma clásica de que tus propias facturas dejen de poder entregarse.

1. 1

   Haz un inventario de todo lo que envía en tu nombre

   Tu proveedor de correo, sí, pero también las herramientas de facturación, el CRM, las plataformas de marketing, los sistemas de tickets y el correo transaccional de tu aplicación. Cualquier cosa que se omita aquí fallará más adelante.

2. 2

   Publica SPF con fallo suave

   Incluye a todos los remitentes del primer paso y termina con ~all. El fallo suave marca a los remitentes no incluidos como sospechosos sin destruir el correo mientras verificas la lista.

3. 3

   Activa la firma DKIM

   Actívala en cada proveedor y publica los registros de selector que te den. Envía un mensaje de prueba y confirma que la firma se verifica.

4. 4

   Empieza DMARC con p=none

   Solo supervisión. Recopila informes agregados durante dos a cuatro semanas: revelarán remitentes que olvidaste.

5. 5

   Endurece la política gradualmente

   Cuando los informes muestren que solo pasan las fuentes legítimas, pasa a p=quarantine, opcionalmente con pct=25 primero, y luego a p=reject cuando todo esté limpio.

Los registros TXT no son solo para el correo

El mismo tipo de registro sirve para verificar la propiedad del dominio en decenas de servicios: Google Search Console, Microsoft 365, Facebook y otros te piden que publiques un token como registro TXT y luego lo comprueban.

example.com.    IN    TXT    "google-site-verification=rXsLp2..."
example.com.    IN    TXT    "MS=ms12345678"

Estos conviven sin problema. Un dominio puede tener muchos registros TXT; la única regla es que debe haber exactamente uno que empiece por v=spf1.

Pasa cualquier dominio por la herramienta de consulta para ver todos sus registros TXT juntos: una forma rápida de detectar un registro SPF duplicado o un token de verificación que nunca se eliminó.