SPF, DKIM y DMARC explicados: configuración y alineación

SPF, DKIM y DMARC son tres registros DNS que permiten a los proveedores de correo verificar que un mensaje realmente viene de tu dominio. SPF autoriza qué servidores pueden enviar en nombre del dominio del sobre, DKIM firma criptográficamente el mensaje y DMARC exige que al menos uno de los dos pase alineado con el dominio visible en el From, y le dice al receptor qué hacer si no ocurre. Sin los tres bien configurados, Gmail, Yahoo y Outlook tratarán tu correo con desconfianza o directamente lo rechazarán.

Por qué hacen falta los tres

El protocolo SMTP no verifica quién envía. Cualquiera puede conectarse a un servidor y escribir From: facturacion@example.com. Cada mecanismo cubre una parte del problema:

El punto clave: SPF y DKIM por sí solos no protegen el From que ve el usuario. Un atacante puede pasar SPF con su propio dominio en el sobre y poner tu dominio en el From. DMARC cierra esa brecha con la alineación.

Paso 1: configurar SPF

SPF se evalúa contra el dominio del comando MAIL FROM (el que acaba en el header Return-Path), no contra el From visible. Un registro típico:

bounces.example.com.  IN TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 -all"

O, si usas además un proveedor externo:

example.com.  IN TXT  "v=spf1 include:_spf.proveedor.example ip4:203.0.113.10 ~all"

Reglas que conviene respetar:

• Un solo registro v=spf1 por nombre. Dos registros producen permerror.
• Máximo 10 consultas DNS (mecanismos include, a, mx, ptr, exists y el modificador redirect). Superarlo también da permerror. Cada include anidado cuenta.
• -all vs ~all: -all (fail) es más estricto; ~all (softfail) es común mientras auditas tus fuentes. Con DMARC en vigor, la diferencia práctica es menor porque DMARC decide la política.
• Evita ptr: RFC 7208 lo desaconseja por lento y poco fiable.

El subdominio de return-path

Una práctica muy recomendable es usar un subdominio dedicado para el sobre, por ejemplo bounces.example.com. Así el registro SPF de ese subdominio solo lista tus servidores de envío, los rebotes llegan a una infraestructura que los procesa y, con alineación relajada, bounces.example.com sigue alineado con example.com en el From.

Paso 2: configurar DKIM

DKIM añade un header DKIM-Signature con una firma calculada sobre el cuerpo y una lista de headers. El receptor obtiene la clave pública del DNS usando el selector (s=) y el dominio (d=):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=pg2026; t=1791763200; h=from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=Kx7r...truncado...

Y el registro DNS correspondiente:

pg2026._domainkey.example.com.  IN TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv1..."
  "...resto-de-la-clave...IDAQAB" )

Recomendaciones prácticas:

• Claves RSA de 2048 bits. Las de 1024 bits ya se consideran débiles. Como un string TXT tiene un límite de 255 caracteres, la clave se divide en varios strings dentro del mismo registro; el resolvedor los concatena.
• Canonicalización relaxed/relaxed, que tolera cambios menores de espacios en blanco introducidos por servidores intermedios.
• Firma los headers que importan: From (obligatorio según RFC 6376), Subject, Date, Message-ID, To y, si envías marketing, List-Unsubscribe y List-Unsubscribe-Post.
• Rota las claves periódicamente publicando un selector nuevo, firmando con él y retirando el antiguo pasados unos días, cuando ya no queden mensajes en tránsito.
• Firma con tu dominio, no con el del proveedor. Si d= es el dominio de tu proveedor, DKIM pasa, pero no alinea con tu From.

Paso 3: publicar DMARC

DMARC se publica en _dmarc del dominio del From:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r; fo=1"

Cómo funciona la alineación

DMARC pasa si cualquiera de estas condiciones se cumple:

1. SPF pasa y el dominio del MAIL FROM está alineado con el From.
2. DKIM pasa y el dominio d= de una firma válida está alineado con el From.

Con alineación relajada, basta con que coincida el dominio organizacional: bounces.example.com y mail.example.com se alinean con example.com. Con alineación estricta, los dominios deben ser idénticos.

Ejemplo de un mensaje bien autenticado, tal como lo registra el receptor:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.example.com;
  dkim=pass header.d=example.com header.s=pg2026;
  dmarc=pass (p=NONE) header.from=example.com

DKIM es el pilar más robusto de la alineación porque sobrevive al reenvío. SPF se rompe cuando un mensaje se reenvía, porque la IP del reenviador no está en tu registro. Por eso conviene que DKIM siempre alinee, aunque SPF también lo haga.

Paso 4: endurecer la política de forma gradual

1. Semanas iniciales con p=none y rua activo. Analiza los reportes: verás todas las IPs que envían en tu nombre, incluidas herramientas olvidadas (CRM, facturación, soporte).
2. Corrige cada fuente legítima para que firme DKIM con tu dominio o use un MAIL FROM alineado.
3. Pasa a p=quarantine, opcionalmente con pct reducido al principio.
4. Llega a p=reject cuando los reportes muestren que solo falla el tráfico no autorizado.

Recuerda que, según las directrices de Google para remitentes masivos, el mínimo exigido es p=none, pero una política de cumplimiento protege tu marca frente a la suplantación.

Errores comunes

• Dos registros SPF porque cada herramienta pidió "agregar su registro". Hay que fusionarlos en uno.
• Superar las 10 consultas al acumular include. Revisa con una herramienta de análisis SPF y elimina proveedores que ya no usas.
• DKIM firmado con el dominio del proveedor, lo que deja DMARC dependiendo solo de SPF.
• Registro DKIM mal partido, con comillas o espacios extra que corrompen la clave.
• DMARC publicado en el host equivocado (dmarc.example.com en vez de _dmarc.example.com).
• Saltar directamente a p=reject sin revisar los reportes, bloqueando correos legítimos de otros sistemas.
• Olvidar los subdominios: si envías desde news.example.com, también necesita SPF y DKIM alineados, y la política sp del dominio padre se le aplica si no tiene su propio registro DMARC.

Checklist rápido

• [ ] Un único registro SPF por dominio de envío, con menos de 10 consultas.
• [ ] Return-path en un subdominio propio (bounces.example.com) con su SPF.
• [ ] DKIM con clave de 2048 bits, d= igual a tu dominio y firma de From.
• [ ] Plan de rotación de selectores DKIM.
• [ ] _dmarc publicado con rua y, como mínimo, p=none.
• [ ] Reportes agregados revisados antes de endurecer la política.
• [ ] Verificación de Authentication-Results en un mensaje real enviado a Gmail y Outlook.

Cómo encaja Pidgely

En Pidgely cada dominio que verificas recibe su propia clave DKIM y un subdominio de return-path con SPF alineado, de modo que DMARC pasa por ambas vías sin depender de un proveedor de envío externo. Tú publicas los registros DNS una vez y la plataforma comprueba que sigan correctos.