DMARC, SPF y DKIM: guía completa de autenticación de email para empresas
Si alguien puede enviar emails haciéndose pasar por tu empresa, tu reputación y tus clientes están en riesgo. Aprende a configurar DMARC, SPF y DKIM correctamente.
El problema: cualquiera puede enviar un email como si fuera tu empresa
Esto sorprende a la mayoría de los directores de IT: el protocolo de email (SMTP) no tiene autenticación de origen incorporada. Fue diseñado en 1982 cuando internet era una red académica de confianza. Cualquiera puede enviar un email con el campo "From:" configurado como tu dominio.
Esto significa que un atacante puede enviar un email que parece venir de facturacion@tuempresa.com.mx a tus clientes con una factura falsa, y sin autenticación de email configurada, no hay nada técnico que lo prevenga.
Las consecuencias reales:
- Fraude financiero: Clientes pagan facturas falsas enviadas "desde" tu dominio
- Pérdida de reputación: Tu dominio aparece en listas negras porque se usa para spam
- Phishing interno: Un empleado recibe un email "del CEO" pidiendo una transferencia urgente
- Problemas de entregabilidad: Tus emails legítimos terminan en spam porque tu dominio no está autenticado
Los 3 protocolos de autenticación de email
SPF (Sender Policy Framework)
Qué hace: Define qué servidores tienen permiso de enviar email en nombre de tu dominio.
Cómo funciona: Publicas un registro TXT en tu DNS que lista las IPs y servicios autorizados. Cuando un servidor recibe un email de tu dominio, verifica que el servidor que lo envió esté en tu lista de SPF.
Ejemplo de registro SPF para M365:
```
v=spf1 include:spf.protection.outlook.com -all
```
Ese `-all` al final es crítico: significa "rechaza todo lo que no venga de los servidores autorizados". La mayoría de los administradores ponen `~all` (soft fail) que solo marca el email como sospechoso pero no lo rechaza. Usa `-all` siempre.
Errores comunes:
- Usar `?all` o `~all` en lugar de `-all`
- Tener múltiples registros SPF (solo puede haber uno por dominio)
- Exceder el límite de 10 lookups DNS (cada `include:` cuenta como un lookup)
- Olvidar agregar servicios como HubSpot, Mailchimp, o Salesforce que envían email en tu nombre
DKIM (DomainKeys Identified Mail)
Qué hace: Agrega una firma digital a cada email que envías, verificando que no fue alterado en tránsito.
Cómo funciona: Tu servidor de email firma cada mensaje con una clave privada. La clave pública se publica en tu DNS. El servidor receptor verifica la firma contra la clave pública. Si alguien modificó el email en tránsito (o lo envió sin tu clave privada), la verificación falla.
Configuración para Microsoft 365:
1. En el portal de administración de Exchange, habilita DKIM para tu dominio
2. Microsoft genera dos registros CNAME que apuntan a sus claves de firma
3. Publicas esos CNAMEs en tu DNS
4. Microsoft rota las claves automáticamente
Errores comunes:
- No habilitar DKIM (Microsoft 365 lo tiene desactivado por defecto para dominios personalizados)
- Configurar DKIM para el dominio principal pero olvidar subdominios que también envían email
- No verificar que los registros CNAME estén correctamente propagados
DMARC (Domain-based Message Authentication, Reporting & Conformance)
Qué hace: Le dice a los servidores receptores qué hacer cuando un email falla SPF y DKIM: no hacer nada, ponerlo en cuarentena, o rechazarlo. También te envía reportes de quién está enviando email usando tu dominio.
Los 3 niveles de DMARC:
1. `p=none` — Solo monitoreo. No toma acción. Útil para empezar.
2. `p=quarantine` — Envía a spam los emails que fallan. Nivel intermedio.
3. `p=reject` — Rechaza completamente los emails que fallan. Nivel máximo de protección.
Ejemplo de registro DMARC:
```
v=DMARC1; p=reject; rua=mailto:dmarc@tuempresa.com.mx; ruf=mailto:dmarc@tuempresa.com.mx; fo=1
```
Errores comunes:
- Quedarse en `p=none` permanentemente (solo monitorea pero no protege)
- No configurar `rua` para recibir reportes agregados (pierdes visibilidad)
- Pasar de `p=none` a `p=reject` sin analizar los reportes primero (puedes bloquear email legítimo)
- No configurar DMARC en subdominios (`sp=reject` protege subdominios)
El roadmap correcto de implementación
Semana 1: SPF
1. Identifica todos los servicios que envían email con tu dominio (M365, CRM, marketing, sistema de facturación)
2. Crea un registro SPF que los incluya todos
3. Usa `-all` para hard fail
4. Verifica con herramientas como MXToolbox
Semana 2-3: DKIM
1. Habilita DKIM en Microsoft 365
2. Publica los registros CNAME en tu DNS
3. Habilita DKIM en cualquier otro servicio que envíe email (HubSpot, Mailchimp, etc.)
4. Verifica con herramientas de diagnóstico
Semana 4: DMARC en modo monitor
1. Publica `v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com`
2. Espera 2-4 semanas recopilando reportes
3. Analiza los reportes: ¿quién está enviando email como tú? ¿Hay servicios legítimos que no incluiste en SPF?
Semana 8: DMARC en modo cuarentena
1. Cambia a `p=quarantine` después de confirmar que todo el email legítimo pasa SPF/DKIM
2. Monitorea durante 2 semanas más
Semana 10: DMARC en modo reject
1. Cambia a `p=reject` para protección completa
2. Configura `sp=reject` para proteger subdominios también
3. Mantén el monitoreo de reportes permanentemente
Qué evalúa nuestro escaneo
Nuestro escaneo gratuito de 192 reglas incluye verificación detallada de:
- Existencia y configuración de registro SPF
- Modo de falla de SPF (`-all` vs `~all`)
- DKIM habilitado y funcionando
- Registro DMARC publicado y su política
- Análisis de si tu DMARC está en modo protección o solo monitoreo
En 90 segundos sabes exactamente si tu email está protegido contra suplantación.
[Verifica tu autenticación de email gratis →](/scan)
¿Tu empresa está protegida?
Diagnóstico gratuito de madurez digital en 5 minutos. Identifica riesgos antes de que se conviertan en incidentes.