El email sin SPF, DKIM y DMARC es como un sobre sin remitente verificado: cualquiera puede falsificarlo y meterlo en el buzón de tus clientes. Estos tres protocolos de autenticación email son el estándar actual para proteger dominio email contra spoofing, phishing y bombardeo de spam que dañe tu reputación. Configurarlos bien determina si tus facturas llegan a la bandeja de entrada o si un estafador suplanta tu dominio para vaciar la cuenta de un cliente. La buena noticia: son tres registros DNS. La mala: si los pones mal, te autobloqueas el correo legítimo. Vamos a desmontar cómo funciona el anti spoofing moderno sin tecnicismos innecesarios, con los comandos exactos y los errores típicos que verás en cualquier auditoría.
Qué es exactamente cada uno y por qué los necesitas los tres
Los tres protocolos resuelven problemas distintos y se complementan. Ninguno funciona solo del todo bien.
- SPF (Sender Policy Framework): lista blanca de servidores autorizados a enviar correo desde tu dominio. Definido en el RFC 7208 (2014). Responde a la pregunta "¿esta IP puede enviar como @tudominio.com?".
- DKIM (DomainKeys Identified Mail): firma criptográfica en la cabecera del mensaje. RFC 6376. Garantiza que el contenido no se ha alterado en tránsito y que viene de quien dice venir.
- DMARC (Domain-based Message Authentication, Reporting and Conformance): política que le dice al receptor qué hacer si SPF o DKIM fallan. RFC 7489. También genera informes diarios de quién está intentando suplantarte.
Google y Yahoo lo dejaron claro en febrero de 2024: cualquier remitente que envíe más de 5.000 correos diarios a sus usuarios necesita los tres configurados o el correo va directo a spam (o se rechaza). Microsoft aplica una política equivalente para Outlook desde 2025. Si tienes negocio, esto ya no es opcional.
SPF: la lista de invitados de tu dominio
El registro SPF es un TXT en tu DNS que enumera qué servidores tienen permiso para enviar correo en tu nombre. Un ejemplo típico para un dominio que usa Google Workspace y un Mailchimp:
v=spf1 include:_spf.google.com include:servers.mcsv.net -all
El -all final es la parte importante. Significa "rechaza todo lo demás". Mucha gente pone ~all (softfail) por miedo, pero eso solo marca el correo como sospechoso, no lo bloquea. Si quieres protección real, -all. Solo si estás en fase de pruebas usa ~all.
Tres errores que veo cada semana auditando dominios:
- Más de 10 lookups DNS: SPF tiene un límite duro. Cada
include:cuenta. Si encadenas Google + Microsoft + Mailchimp + SendGrid + tu propio servidor, te pasas y SPF deja de validar. - Dos registros SPF en el mismo dominio: rompe la validación entera. Solo puede haber uno, combina todos los
include:en una línea. - Olvidar el servidor real de envío: si tu Plesk envía facturas desde la IP del VPS pero no la incluyes, esos correos fallan SPF.
Para comprobar tu registro actual, en terminal: dig TXT tudominio.com +short. O usa MXToolbox si prefieres web.
DKIM: la firma digital que nadie puede falsificar
DKIM añade una cabecera DKIM-Signature a cada email saliente, firmada con una clave privada que solo tú tienes. El receptor consulta tu DNS, recupera la clave pública y verifica la firma. Si alguien modifica el mensaje en tránsito (o lo falsifica entero), la firma no cuadra y el correo se marca.
La configuración depende del proveedor. En Google Workspace: Admin → Apps → Gmail → Autenticar correo electrónico → Generar nueva clave (2048 bits, no 1024). Te da un registro TXT que pegas en tu DNS con el selector google._domainkey.
Microsoft 365: Defender → Policies → DKIM → seleccionas el dominio y activas. Crea dos selectores (selector1 y selector2) para rotación de claves sin downtime.
Un detalle que se escapa: si usas múltiples servicios (Google + Mailchimp + un CRM que envíe en tu nombre), cada uno necesita su propio selector DKIM. No se solapan, conviven. Por eso verás dominios con cinco o seis registros _domainkey distintos. Es normal.
DKIM también es la base de otras protecciones. El cifrado de extremo a extremo protege el contenido, pero DKIM protege la integridad y origen del mensaje cuando viaja por servidores intermedios.
DMARC: el árbitro que decide qué hacer cuando algo falla
SPF y DKIM son detectores. DMARC es el ejecutor. Le dice al receptor: "si SPF falla Y DKIM falla, rechaza el mensaje y mándame un informe".
El registro va en _dmarc.tudominio.com como TXT:
v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com; ruf=mailto:dmarc@tudominio.com; fo=1; aspf=s; adkim=s
Las tres políticas posibles son:
| Política | Qué hace | Cuándo usarla |
|---|---|---|
p=none | Monitoriza, no bloquea nada | Primeras 2-4 semanas, solo para recoger informes |
p=quarantine | Manda a spam los fallos | Fase intermedia, cuando ya sabes qué legítimo fallaba |
p=reject | Rechaza el mensaje directamente | Objetivo final, protección completa |
El truco está en rua=: ahí recibes los informes XML diarios de Google, Microsoft, Yahoo y compañía. Te llegan estadísticas de cuántos correos pasaron, cuántos fallaron y desde qué IPs intentaron suplantarte. Son ilegibles a pelo (XML comprimido), pero hay servicios gratuitos como Postmark DMARC o Dmarcian que te los traducen.
Empezar con p=reject sin pasar por p=none es el error más caro. Acabas bloqueando tu propio Mailchimp porque olvidaste autorizarlo. La progresión sensata es: 4 semanas en none, 4 en quarantine al 25%, subir gradualmente al 100%, después saltar a reject.
Cómo se ejecuta una suplantación cuando estos protocolos faltan
Para entender por qué importa, conviene saber cómo se hace el ataque. Un atacante registra un dominio parecido (caixa-banc.com vs caixabank.es), o directamente falsifica el From: poniendo el dominio real de la víctima. Si el dominio real no tiene DMARC con p=reject, el correo entra en la bandeja del destinatario como si fuera legítimo.
Los esquemas más comunes que aprovechan esta debilidad son las estafas de suplantación bancaria y el fraude del CEO (BEC, Business Email Compromise). Según el informe IC3 del FBI de 2024, las pérdidas globales por BEC superaron los 2.900 millones de dólares. La mayoría se previene con DMARC bien puesto.
Antes de hacer clic en cualquier enlace de un correo, conviene verificar manualmente que el enlace es seguro, pero la primera línea de defensa es que el correo malicioso no llegue a entrar.
El stack completo: BIMI, MTA-STS y TLS-RPT
Cuando ya tienes SPF + DKIM + DMARC con p=reject, hay tres añadidos que llevan la autenticación al siguiente nivel:
- BIMI (Brand Indicators for Message Identification): muestra tu logo verificado en la bandeja de entrada de Gmail y Yahoo. Requiere DMARC reject y un certificado VMC emitido por DigiCert o Entrust (aproximadamente 1.500€/año según estimaciones de 2025). Solo compensa para marcas con mucho volumen.
- MTA-STS: obliga al envío por TLS entre servidores. Evita ataques de downgrade. Configuración: registro DNS + archivo en
https://mta-sts.tudominio.com/.well-known/mta-sts.txt. - TLS-RPT: informes diarios de problemas de cifrado en tránsito. Complementa MTA-STS.
La AEPD recomienda la implementación de DMARC como medida técnica adecuada bajo el artículo 32 del RGPD para responsables de tratamiento que gestionan correo electrónico con datos personales. No es una obligación literal, pero en caso de brecha por phishing, no tenerlo configurado puede agravar la sanción.
Herramientas reales para auditar y mantener la configuración
No hace falta gastar dinero para tener una buena auditoría:
- MXToolbox (mxtoolbox.com/SuperTool.aspx): comprueba SPF, DKIM y DMARC de un dominio en segundos. Gratis.
- Mail-tester.com: envías un correo a la dirección que te da y te puntúa el envío sobre 10. Detecta SPF roto, DKIM mal firmado, contenido sospechoso.
- Postmark DMARC (dmarc.postmarkapp.com): procesa los informes XML de
rua=y te los muestra en gráficos legibles. Gratis hasta 1 dominio. - DMARC Analyzer / Dmarcian: versión profesional para múltiples dominios. Plan gratuito con un dominio.
- Have I Been Pwned (haveibeenpwned.com): no es de DMARC pero conviene tenerlo monitorizado para saber si tu dominio aparece en filtraciones, lo que aumenta el riesgo de suplantación.
Si gestionas varios dominios de clientes (agencias, hostings, freelancers), automatizar la monitorización con un script que llame a una API DMARC ahorra horas cada semana. Servicios como soluciones de IA aplicadas a la gestión de infraestructura permiten cruzar informes DMARC con alertas en Slack o WhatsApp cuando aparece un nuevo origen sospechoso.
Preguntas frecuentes
¿Puedo tener SPF y DKIM sin DMARC?
Técnicamente sí, pero pierdes la mitad del beneficio. Sin DMARC, los receptores deciden cada uno qué hacer cuando SPF o DKIM fallan, y tú nunca sabes quién intenta suplantarte. Configurar los tres lleva entre 30 y 60 minutos si tienes acceso al DNS.
¿Cuánto tarda en propagarse un cambio en SPF, DKIM o DMARC?
Depende del TTL del DNS, pero normalmente entre 15 minutos y 4 horas. Si tu DNS tiene TTL de 86400 segundos (24h), espera hasta un día. Antes de hacer cambios, baja el TTL a 300 segundos unas horas antes.
¿DMARC bloquea los correos de mi Mailchimp o newsletter?
Solo si no has autorizado a Mailchimp ni en SPF ni en DKIM. Si añades include:servers.mcsv.net al SPF y activas la firma DKIM dentro del panel de Mailchimp, todo pasa sin problema. Lo mismo aplica a SendGrid, Brevo, Mailgun y similares.
¿Vale la pena configurar DMARC en un dominio que no envía correo?
Sí, y es de las cosas más infravaloradas. Un dominio "parado" pero registrado es un objetivo perfecto para suplantación porque nadie monitoriza nada. Pon v=DMARC1; p=reject; rua=mailto:... y olvídate. Bloqueas el 100% de intentos de envío en su nombre.
¿Qué pasa si mi proveedor de hosting no soporta DKIM 2048 bits?
Cámbiate de proveedor. Las claves de 1024 bits están desaconsejadas desde 2018 y muchos receptores grandes las marcan como inseguras. Cualquier hosting profesional moderno soporta 2048 bits sin coste adicional.
El siguiente paso
Entra ahora en mxtoolbox.com/SuperTool.aspx, escribe tu dominio y ejecuta los tests "SPF Record Lookup", "DKIM Lookup" y "DMARC Lookup". En menos de un minuto sabrás exactamente qué te falta y con qué política estás trabajando. Si aparece "No DMARC Record found", tienes la primera tarea de la semana.
