SPF, DKIM y DMARC: Guía completa de autenticación de correo

Es muy probable que ocurran dos situaciones críticas en su dominio en este preciso instante, y ambas tienen impacto económico directo:

Cualquiera puede enviar correos haciéndose pasar por su empresa. A menos que disponga de una política DMARC configurada en quarantine o reject, los servidores de correo de destino no tienen instrucción de rechazar un mensaje falsificado que utilice su nombre. Así es exactamente como se ejecutan los fraudes por suplantación de facturas contra sus clientes.

Parte de sus correos legítimos están terminando en la carpeta de spam. Desde febrero de 2024, Google y Yahoo exigen autenticación estricta para emisores masivos, y Microsoft ha adoptado requisitos equivalentes. Los dominios sin una configuración rigurosa de SPF, DKIM y DMARC son progresivamente filtrados o rechazados de plano.

No es una simple cuestión técnica secundaria. Si emite confirmaciones de pedidos, facturas, restablecimientos de contraseñas o comunicaciones comerciales, constituye infraestructura crítica para sus ingresos.

A continuación, explicamos cómo opera cada registro y cómo implementarlos sin interrumpir sus comunicaciones habituales.

SPF: qué servidores están autorizados a enviar en su nombre

SPF es un registro DNS de tipo TXT que enumera los servidores y servicios autorizados para emitir correo desde su dominio.

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Interpretación técnica: versión 1 de SPF; autorizar los servidores de Google Workspace; autorizar los servidores de Mailchimp; cualquier otro servidor no listado debe tratarse como fallo leve (~all, soft fail).

Los tres errores críticos en la configuración de SPF

Superar el límite de 10 consultas DNS (lookup limit). Cada mecanismo include, a, mx, ptr, exists y redirect consume una consulta DNS, y las llamadas anidadas también computan. El estándar RFC impone un límite estricto de 10 consultas. Si se supera, el registro devuelve un error permanente (permerror), lo que la mayoría de proveedores receptores interpretan como un fallo de autenticación, empezando a rechazar correos legítimos.

Este problema surge de forma inadvertida: Google Workspace más un CRM, una plataforma de marketing, un servicio de soporte técnico y un software de facturación superan rápidamente las 10 consultas debido a sus inclusiones internas.

Para solucionarlo, unifique y simplifique registros (reemplazando include: por rangos IP explícitos si es indispensable) o elimine herramientas en desuso. Tenga en cuenta que especificar rangos IP directos exige mantenimiento manual si el proveedor cambia su infraestructura. Priorice siempre la eliminación de servicios obsoletos.

Múltiples registros SPF. Un dominio solo puede tener un único registro SPF. Publicar dos registros TXT que comiencen por v=spf1 genera automáticamente un permerror. Esto ocurre con frecuencia cuando un proveedor externo añade su propio registro en lugar de editar el ya existente.

Finalizar el registro en +all. Esta directiva autoriza a cualquier servidor de internet a emitir correos en nombre de su dominio. Es peor que no tener SPF, ya que afirma formalmente que cualquier intento de suplantación es legítimo. Suele ser el remanente de una prueba técnica que nadie revirtió.

Utilice ~all (soft fail) durante la fase de auditoría e inventario de remitentes y cambie a -all (hard fail) una vez confirmado que la lista de servidores está completa.

DKIM: firma criptográfica de autenticidad

DKIM añade una firma digital al encabezado de los correos salientes mediante una clave privada custodiada por su proveedor de correo. La clave pública correspondiente se publica en su zona DNS. El servidor de destino verifica la firma, demostrando que el mensaje procede auténticamente de su dominio y no fue alterado durante el trayecto.

El registro se ubica en selector._domainkey.sudominio.com, donde el selector es determinado por el proveedor del servicio (google, selector1, k1, s1, etc.).

Dos aspectos prácticos a considerar:

No es posible enumerar los selectores desde el exterior. Si una herramienta externa indica «DKIM no encontrado», significa simplemente que no halló el registro en los selectores comunes habituales. Debe consultar la documentación de su proveedor para conocer el selector exacto.

Cada plataforma de envío requiere su propio registro DKIM. Google Workspace firma los correos emitidos desde su cuenta corporativa, pero no firma los boletines enviados desde su plataforma de email marketing. Cada herramienta externa debe contar con su propia clave DKIM configurada individualmente.

DMARC: la política que articula la protección

SPF y DKIM generan validaciones técnicas aisladas. DMARC establece qué hacer con los resultados y exige alineación de dominios (alignment): el dominio validado por SPF o DKIM debe coincidir con el dominio visible en el encabezado From: del remitente.

Esta alineación es el núcleo de la seguridad. Sin ella, un atacante podría validar SPF con un dominio propio mientras muestra el nombre de su empresa en el campo visual del remitente.

v=DMARC1; p=reject; rua=mailto:dmarc@sudominio.com; pct=100; adkim=s; aspf=s

p= — la directiva de actuación: none (solo monitorizar), quarantine (enviar a spam) o reject (rechazar de plano)
rua= — dirección para la recepción de informes agregados
pct= — porcentaje de mensajes a los que se aplica la política (para despliegues graduales)
adkim= / aspf= — rigor de la alineación: s estricta (strict) o r flexible (relaxed)

El riesgo de permanecer indefinidamente en p=none

Gran parte de los dominios con DMARC permanecen en p=none durante años.

p=none significa únicamente: evaluar, generar informes y entregar el correo en cualquier caso. No bloquea ninguna suplantación. Los correos falsificados que simulan provenir de su empresa seguirán llegando a las bandejas de entrada de sus clientes.

Es el punto de partida adecuado para auditar todos los remitentes legítimos, pero no es una configuración finalizada. Un dominio en p=none transmite una falsa sensación de protección sin aplicar seguridad real.

Protocolo para una transición segura

El riesgo de activar el bloqueo estricto es rechazar correos legítimos no inventariados: el software de contabilidad, la plataforma de selección de personal o un script interno antiguo. El despliegue por fases evita este problema:

Publicar p=none con directiva rua=. Recopile informes durante 2 a 4 semanas.
Analizar los informes. Utilice herramientas de análisis DMARC para detectar qué servidores envían correo en su nombre y cuáles fallan la alineación.
Corregir o autorizar cada emisor legítimo. Añádalo a SPF, configure su DKIM o migre sus envíos a un subdominio dedicado.
Activar p=quarantine; pct=10. Supervise durante una semana e incremente al 50% y posteriormente al 100%.
Establecer p=reject. Solo cuando los informes confirmen que todos los envíos legítimos superan la autenticación.

Este proceso requiere entre uno y tres meses en organizaciones de tamaño medio. Precipitarse en el paso 3 es el motivo por el cual los departamentos financieros descubren de repente que las facturas no llegan a los clientes.

Dos aspectos frecuentemente ignorados

Subdominios. DMARC se aplica a los subdominios mediante la etiqueta sp=. Si no se define, los subdominios heredan la política principal. Los atacantes suelen utilizar subdominios desprotegidos (mail.sudominio.com, facturas.sudominio.com) para eludir controles. Configure sp=reject en dominios que nunca deban emitir correos desde subdominios.

Dominios aparcados y defensivos. Todo dominio registrado por su empresa que no emita correo debe publicar obligatoriamente v=spf1 -all y v=DMARC1; p=reject;. Los dominios secundarios y defensivos son objetivos habituales de suplantación precisamente porque se suele descuidar su configuración.

Verificación de registros técnicos

Puede auditar la configuración de cualquier dominio con nuestra herramienta gratuita de entregabilidad de correo. Consulta directamente los servidores DNS y muestra los registros reales en texto, permitiéndole diagnosticar errores de sintaxis y alineación.

También puede consultar los registros desde su terminal:

dig +short TXT sudominio.com          # muestra SPF entre los resultados
dig +short TXT _dmarc.sudominio.com   # muestra la política DMARC
dig +short TXT google._domainkey.sudominio.com  # clave DKIM para ese selector
dig +short MX sudominio.com           # servidores de correo entrante

Secuencia prioritaria de implementación

Publicar SPF con todos los servicios emisores autorizados, finalizando en ~all
Habilitar DKIM en cada uno de dichos servicios
Publicar DMARC en p=none configurando la dirección rua= para informes
Analizar los informes agregados durante un mes y corregir discrepancias
Evolucionar la política a p=quarantine y finalmente a p=reject
Proteger subdominios y dominios aparcados
Ajustar la directiva SPF final a -all

Abrir herramienta Entregabilidad de Email Consultas DNS en tiempo real de registros SPF, DMARC, DKIM y MX con el texto exacto publicado en su servidor.

Seleccione su idioma