Autenticación de email para senders en crecimiento — SPF, DKIM y DMARC explicados con orden y propósito

Cuando un equipo empieza a enviar emails serios, la conversación con el equipo de operaciones suele ir así: "tienes que configurar SPF". Una entrada en DNS, listo. Funciona durante meses. Hasta que no funciona — empiezan a llegar reportes de que algunos clientes no reciben emails, Gmail empieza a marcarlos como sospechosos, o el departamento legal llama porque algún cliente recibió un phishing impersonando el dominio. Ese es el momento donde se descubre que SPF, DKIM y DMARC son tres mecanismos distintos, que se complementan, y que ninguno solo es suficiente. Este post los explica con orden y propósito.

El problema fundamental: el remitente del email es trivialmente falsificable

SMTP fue diseñado en los años 80, cuando internet era una red de confianza entre instituciones académicas y militares. Cualquier servidor podía enviar un email diciendo ser de cualquier dominio, sin verificación. Esto sigue siendo cierto técnicamente: si un atacante levanta un servidor SMTP, puede enviar emails con From: ceo@su-empresa.com a quien quiera, sin pedir permiso. La única razón por la que esos emails no llegan a inbox del receptor es porque los receptores aplican capas de autenticación construidas encima del protocolo SMTP base.

Esas capas son SPF, DKIM y DMARC. Cada una resuelve un trozo del problema. Aplicadas las tres con disciplina, dan al receptor evidencia razonable de que el email realmente viene de quien dice venir. No aplicadas, los emails serán crecientemente filtrados o rechazados — y la marca queda expuesta a phishing impersonado.

SPF — quién está autorizado a enviar desde mi dominio

SPF (Sender Policy Framework, RFC 7208) publica en DNS la lista de servidores autorizados a enviar desde su dominio. Cuando un receptor recibe un email de su-empresa.com, consulta el registro SPF de su-empresa.com en DNS y verifica si la IP del servidor que envió está en esa lista.

Un registro SPF típico se ve así en DNS:

su-empresa.com.  TXT  "v=spf1 include:_spf.proveedor.com ip4:198.51.100.0/24 -all"

Esto declara que están autorizados los servidores de proveedor.com (importado por reference) y la red 198.51.100.0/24. Cualquier otra fuente que envíe desde su-empresa.com falla SPF (eso significa el "-all" final: hard fail).

SPF tiene una limitación crítica: se rompe en forwarding. Si un destinatario reenvía su email automáticamente a otra dirección, el servidor que recibe el reenvío ve el email viniendo de un servidor que no está en su SPF, así que falla. Por esto, SPF solo no es suficiente para autenticación robusta — necesita combinarse con DKIM.

DKIM — firma criptográfica del propio mensaje

DKIM (DomainKeys Identified Mail, RFC 6376) firma criptográficamente cada mensaje saliente con una clave privada. La clave pública se publica en DNS bajo un selector específico. El receptor extrae la firma del mensaje, busca la clave pública en DNS, y verifica que la firma es válida y que las cabeceras críticas no han sido modificadas en tránsito.

Una clave DKIM en DNS se ve así:

selector1._domainkey.su-empresa.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3D...QAB"

El selector ("selector1" en este ejemplo) permite tener múltiples claves activas simultáneamente. Esto es útil para rotación periódica de claves (recomendado al menos anualmente) y para usar claves distintas por proveedor de envío (relay especializado, transaccional, marketing, cold email).

DKIM resuelve el problema del forwarding: la firma viaja con el mensaje, así que aunque el email pase por varios MTAs, mientras las cabeceras firmadas y el cuerpo no se modifiquen, la firma sigue siendo válida. La clave RSA recomendada en 2026 es de 2.048 bits mínimo (1.024 bits es legacy y empieza a fallar con receptores estrictos).

DMARC — política de qué hacer cuando algo falla

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) es la capa de política. Una vez que SPF y DKIM están configurados, DMARC dice al receptor: "si SPF y DKIM ambos fallan, esto es lo que debes hacer".

Un registro DMARC se ve así:

_dmarc.su-empresa.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@su-empresa.com; pct=100; aspf=s; adkim=s"

Las políticas posibles son tres en grados crecientes de estrictez: p=none (no hacer nada, solo reportar — modo monitoreo), p=quarantine (enviar a spam si falla), p=reject (rechazar entrega completamente). El parámetro pct controla qué porcentaje de mensajes que fallan recibe la política (útil para despliegue gradual).

Pero DMARC tiene un detalle crítico que confunde a muchos equipos: el alignment. Para que DMARC pase, no basta con que SPF o DKIM autentiquen el mensaje. El dominio que autentica debe alinearse con el dominio del From visible. Si SPF pasa pero el dominio MAIL FROM es bounce.proveedor.com mientras el From visible es su-empresa.com, DMARC falla el alignment de SPF. Solo si DKIM firma con el mismo dominio del From, DMARC pasa el alignment de DKIM.

Esta es la razón por la que muchos equipos configuran SPF y DKIM correctamente, ven que pasan en herramientas de testing, pero DMARC sigue fallando: les falta el alignment correcto. La solución típica es asegurar que el proveedor de envío firme DKIM con el dominio del cliente (no con su propio dominio), y que el MAIL FROM use un subdominio del dominio del cliente (bounce.su-empresa.com en lugar de bounce.proveedor.com).

Orden recomendado de despliegue

El despliegue conservador en el orden correcto evita romper deliverability mientras se construye la autenticación. La secuencia probada es esta:

Paso 1 — SPF. Configurar SPF incluyendo todos los servidores y proveedores que envían desde el dominio. Mejor empezar con ~all (soft fail) para detectar omisiones sin rechazar mensajes legítimos. Una vez verificado durante 2-4 semanas que ninguna fuente legítima falla SPF, cambiar a -all (hard fail).

Paso 2 — DKIM. Configurar DKIM en cada proveedor de envío con clave 2.048 bits y selector específico por proveedor. Verificar firma con herramientas (mail-tester.com, dkimcore.org) antes de declarar la configuración estable. Mantener documentación de qué selector usa qué proveedor para futuras rotaciones.

Paso 3 — DMARC en modo monitoreo (p=none). Publicar registro DMARC con política p=none y reportes rua. Durante 4-8 semanas analizar los reportes XML que llegan: identificar fuentes legítimas que no estén autenticando bien, fuentes ilegítimas que intentan impersonar el dominio, y errores de alignment.

Paso 4 — DMARC enforcement gradual. Cuando los reportes muestran que las fuentes legítimas autentican correctamente, mover a p=quarantine con pct=10 (10% de mensajes que fallan van a spam). Subir progresivamente pct=25, 50, 100 a lo largo de semanas, monitoreando reportes.

Paso 5 — DMARC reject completo. Cuando p=quarantine; pct=100 ha funcionado estable durante un mes sin pérdida de mensajes legítimos, mover a p=reject. Esto es el destino final: cualquier email que falle autenticación es rechazado, protegiendo activamente la marca contra phishing impersonado.

Errores frecuentes en deployment

Múltiples registros SPF. RFC permite solo un registro SPF por dominio. Algunos equipos publican varios cuando integran nuevos proveedores ("añade este otro registro SPF") y eso rompe SPF — debe consolidarse todo en uno con includes.

Excede el límite de 10 lookups DNS. SPF limita a 10 las consultas DNS recursivas (includes, redirects, mx, a). Equipos con muchos proveedores (transaccional + marketing + cold + monitoring + invoicing + support tickets...) llegan rápido a ese límite. La solución es usar un servicio de SPF flattening que mantenga el árbol bajo 10 lookups.

DKIM con clave 1024 bits. Receptores estrictos (Gmail enterprise, Microsoft 365 con políticas estrictas) marcan claves 1024 como débiles. La práctica actual son 2048 bits.

DMARC sin reportes activados. Configurar DMARC sin rua es como navegar a ciegas: no se sabe qué está pasando con la autenticación. Siempre incluir dirección de reporte y procesar los reportes (manual o con herramienta tipo dmarcian, Postmark DMARC monitoring, EasyDMARC).

Mover a p=reject demasiado pronto. La tentación de "saltar" del modo monitoreo directo a reject es alta. Los daños de pasar prematuro (clientes legítimos sin recibir emails críticos) son reales. La paciencia de hacer el rollout gradual es lo que separa una operación seria.

Por qué autenticación bien hecha es ventaja competitiva, no checkbox

La autenticación de email ha pasado de ser "nice to have" a ser requisito básico de operación. En 2024 Gmail y Yahoo formalizaron requisitos para senders bulk (5.000+ emails/día): SPF, DKIM y DMARC con alignment correcto, ratio de complaints bajo 0.3%, opt-out funcional. Microsoft está en proceso de formalizar requisitos similares. La tendencia es clara: senders sin autenticación correcta serán crecientemente filtrados.

Para equipos que están en fase de crecimiento, la autenticación bien hecha desde el inicio elimina problemas que se acumulan más tarde. Para equipos con autenticación parcial o problemática, el esfuerzo de hacer el deployment correcto se compensa rápidamente en deliverability mejorada y exposición de marca reducida frente a phishing.