El protocolo SMTP (Simple Mail Transport Protocol) con el que enviamos correos electrónicos se diseñó en una época en la que internet era un lugar pequeño, académico y, sobre todo, confiado. Por defecto, SMTP no verifica si la persona que dice enviar un correo es realmente quien dice ser. Falsificar el remitente de un email (hacer spoofing) es tan fácil como escribir el nombre de otra persona en el remite de una carta postal.
Para parchear esta carencia de seguridad, a lo largo de los años se ha desarrollado una «tríada» de protocolos de autenticación: SPF, DKIM y DMARC. Hoy en día, configurar esto ya no es una medalla al mérito para los más puristas; proveedores como Google y Yahoo han endurecido sus políticas de recepción y, si no tienes esto bien montado, tus correos corporativos legítimos acabarán rebotados o acumulando polvo en la carpeta de spam.
En esta guía no nos vamos a quedar en las definiciones teóricas de la Wikipedia. Vamos a mancharnos las manos: veremos cómo auditar tus registros desde la terminal, cómo interpretar los temidos reportes XML de DMARC y cuáles son las trampas clásicas en las que cae casi cualquier administrador de sistemas al implementar estas políticas.
Índice de contenidos
La tríada de la entregabilidad de correo: Por qué necesitas los tres
Para entender por qué necesitamos tres protocolos distintos y no solo uno, hay que comprender qué problema exacto soluciona cada uno. Si lo pensamos como una fiesta exclusiva:
- SPF (Autorización): Es la lista de invitados en la puerta. Responde a la pregunta: «¿Tiene la IP de este servidor permiso para enviar correos en nombre de mi dominio?».
- DKIM (Integridad): Es el sello de lacre en la invitación. Responde a la pregunta: «¿Ha sido alterado este correo o sus cabeceras desde que salió del servidor de origen?».
- DMARC (Política y Visibilidad): Es el jefe de seguridad. Responde a la pregunta: «Si el SPF o el DKIM fallan, ¿qué demonios hago con este correo? ¿Lo dejo pasar, lo mando a la basura o lo rechazo?».
Ninguno de los tres funciona mágicamente por sí solo. Es la combinación de los tres lo que protege tu dominio contra el phishing y el fraude del CEO (ataques BEC – Business Email Compromise).
Troubleshooting inicial: Cómo auditar tus registros desde la terminal
Antes de tocar nada en tu panel de DNS, necesitas saber qué tienes configurado actualmente. Los administradores de sistemas no dependemos (solo) de páginas web de terceros; usamos la terminal.
Consultar el SPF y DMARC con dig y nslookup
Tanto SPF como DMARC no son más que registros de texto (TXT) públicos en las DNS de tu dominio.
Para ver el SPF en Linux/macOS usa dig:
dig TXT midominio.com +shortDeberías ver una línea que empieza por v=spf1...
Para consultar DMARC, debes preguntar por un subdominio específico llamado _dmarc:
dig TXT _dmarc.midominio.com +shortEl truco del selector DKIM
Auditar el DKIM es un poco más tramposo. No puedes simplemente preguntar por el dominio, porque un dominio puede tener múltiples firmas DKIM (una para Google Workspace, otra para Mailchimp, otra para Zendesk…). Necesitas conocer el selector.
El selector suele indicártelo tu proveedor de correo (por ejemplo, Google suele usar google, Microsoft suele usar selector1). La consulta se hace al subdominio selector._domainkey.midominio.com:
dig TXT google._domainkey.midominio.com +shortSi la respuesta es una cadena enorme que empieza por v=DKIM1; k=rsa; p=MIIBIjAN..., enhorabuena, tienes una clave pública configurada.
SPF (Sender Policy Framework): La lista de IPs autorizadas
El registro SPF le dice al mundo qué servidores (IPs o dominios) pueden enviar en tu nombre.
Un registro típico tiene este aspecto:
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
Sintaxis básica y el peligro del +all
La parte final del registro define qué pasa con los correos que no vienen de las IPs listadas:
~all(Softfail): «Acepta el correo, pero márcalo como sospechoso (probablemente vaya a Spam)». Es el estándar recomendado durante la configuración.-all(Hardfail): «Rechaza el correo directamente». Es lo más seguro, pero debes estar 100% seguro de haber incluido todos tus servicios.?all(Neutral): No hace nada. Es casi como no tener SPF.+all(Pass): ¡Peligro rojo! Significa «Cualquier IP de internet está autorizada a enviar en mi nombre». Si tienes esto, estás facilitando el trabajo a los spammers.
El límite de los 10 lookups DNS (El error más peligroso)
Este es el motivo número uno por el que un SPF aparentemente bien configurado falla.
El protocolo SPF estipula que, para resolver tu registro, el servidor receptor no puede hacer más de 10 consultas DNS (lookups). Cada vez que usas un include:, fuerzas una consulta. Si incluyes a Google (que a su vez tiene otros includes internos), a Mailchimp, a tu CRM y a tu ERP, es facilísimo superar el límite de 10.
Si te pasas de 10, el SPF devuelve un error PermError y falla. Si tu empresa usa muchos servicios, la solución pasa por una técnica llamada SPF Flattening (Aplanamiento de SPF), que consiste en sustituir los dominios por sus bloques de IPs estáticas para ahorrar consultas DNS. Es algo un poco más avanzado que sale del alcance de este artículo, pero en el mundo empresarial es muy común que te lo encuentres.
DKIM (DomainKeys Identified Mail): El sello criptográfico
Mientras SPF se basa en direcciones IP, DKIM utiliza criptografía asimétrica.
- Tu servidor (o proveedor de correo) tiene una clave privada con la que firma criptográficamente las cabeceras y el cuerpo de cada correo saliente.
- Tú publicas la clave pública en las DNS de tu dominio (como vimos con el selector).
- El servidor receptor usa la clave pública de tus DNS para verificar la firma del correo. Si la firma cuadra, el correo es íntegro y viene de ti.
Por qué DKIM es vital para los reenvíos (Forwarding)
Imagina que envías un correo a [email protected], pero este usuario tiene una regla para reenviar todo su correo a su cuenta personal de Gmail.
El servidor de empresa.com reenvía el correo a Gmail. Cuando Gmail evalúa el SPF, ve que el correo le llega desde la IP de empresa.com, la cual no está en tu registro SPF. Resultado: el SPF falla.
Aquí es donde DKIM te salva la vida. Como la firma criptográfica va incrustada en las cabeceras del correo y el cuerpo no ha cambiado, la firma DKIM sigue siendo válida a pesar del salto de servidor. Por eso configurar solo SPF es insuficiente en la red moderna.
DMARC: El estándar que da sentido a todo
DMARC es el pegamento que une SPF y DKIM, y te permite decirle al mundo qué hacer cuando ambos fallan. Su estructura es simple, por ejemplo:
v=DMARC1; p=quarantine; rua=mailto:[email protected];
Alineación de dominios (El concepto crítico)
DMARC introduce el concepto más incomprendido del correo electrónico: la alineación.
Para que DMARC pase, no basta con que el SPF o el DKIM sean válidos. El dominio que valida el SPF (llamado Return-Path o Envelop From) debe coincidir con el dominio visible que ve el usuario en su cliente de correo (Header From).
Si usas un servicio de newsletter masivo sin configurar su DKIM personalizado, el Return-Path será el de la herramienta (ej. bounces.mailchimp.com), pero el remitente visible será tu dominio ([email protected]). SPF pasará para Mailchimp, pero DMARC fallará estrepitosamente porque los dominios no están alineados.
Las tres políticas de DMARC (p=)
p=none(Monitorización): No bloquea nada. Solo envía reportes para que veas quién está usando tu dominio.p=quarantine: Los correos que fallen van directos a la carpeta de Spam del destinatario.p=reject: El objetivo a conseguir. Los correos que fallen son rechazados a nivel de servidor y nunca llegan al usuario final.
Descifrando los reportes DMARC (RUA y RUF)
Al configurar la etiqueta rua= con un correo, empezarás a recibir archivos ZIP diarios. Dentro hay un archivo XML. Leer ese XML «a pelo» es un suplicio, pero si te toca hacerlo, busca estas etiquetas:
<source_ip>: La IP desde la que salió el correo.<spf>y<dkim>: Su estado de paso o fallo.<disposition>: Qué política se aplicó (none, quarantine, reject).
Consejo: No te quemes los ojos leyendo XMLs. Usa un parseador de reportes DMARC. Hay herramientas gratuitas y de pago (como Postmark DMARC, MXToolBox o dmarc-report) que ingieren estos correos y te los muestran en gráficas limpias, diciéndote exactamente qué IPs legítimas están fallando y qué IPs de Rusia están intentando suplantarte.
Guía de implementación: De 0 a p=reject en 4 fases seguras
Nunca pases directamente a p=reject. Si lo haces, vas a bloquear correos legítimos de departamentos de tu propia empresa que no sabías que enviaban emails (el clásico ERP de contabilidad o el escáner de la oficina). Sigue estas fases:
Fase 1: Auditoría y configuración base
Asegúrate de que tienes SPF y DKIM configurados y validados para tus servicios principales (Google Workspace, Microsoft 365, etc.). Usa las herramientas de terminal para confirmarlo.
Fase 2: DMARC en modo monitor (p=none)
Publica tu registro DMARC con p=none y añade un correo para reportes. v=DMARC1; p=none; rua=mailto:[email protected];
Fase 3: Análisis de datos y caza del Shadow IT
Deja pasar de 2 a 4 semanas. Revisa los reportes en tu parseador. Aquí descubrirás el Shadow IT: el equipo de marketing usando un software nuevo que no te avisaron, un servidor web antiguo enviando alertas de logs, etc. Ve a esos servicios y configúrales el DKIM o añádelos a tu SPF.
Fase 4: El salto a políticas estrictas
Cuando veas que el 99% de tus correos legítimos pasan DMARC, cambia la política a p=quarantine. Espera un par de semanas más monitorizando y, si nadie grita en la oficina porque no le llegan los correos, da el salto definitivo a p=reject.
Es un proceso quizás largo (más que poner una nueva regla en un firewall), pero no requiere conocimiento técnico avanzado y tiene impacto real en la seguridad de tu empresa. ¡A por ello!
Errores frecuentes (Checklist de supervivencia)
A modo de resumen, repasa no estar cometiendo estos crímenes contra el DNS:
- Tener múltiples registros SPF: Tener dos líneas
v=spf1distintas en tu DNS es ilegal según el estándar. El servidor receptor se rendirá y fallarán los dos. Debes unificarlos en un solo registro con variosinclude:. - Olvidar los subdominios: Las políticas de DMARC se heredan. Si alguien falsifica
ventas.midominio.com, le afectará el DMARC principal, salvo que uses la etiquetasp=(subdomain policy) en tu registro. - DMARC en
p=noneeternamente: Dejarlo en modo monitorización para siempre es el equivalente a poner una cámara de seguridad en tu empresa pero dejarla apagada. Tienes que llegar aquarantiney finalmente areject.
Conclusión
La seguridad del correo electrónico no es un botón de «siguiente, siguiente, finalizar». Es un proceso continuo de autenticación y monitorización.
Implementar correctamente SPF, DKIM y DMARC es la línea de defensa más efectiva no solo para proteger el prestigio de tu marca frente a suplantaciones, sino para garantizar que tus comunicaciones lleguen de forma fiable a tus clientes.
Haz la prueba hoy mismo: abre tu terminal, tira un dig a tu dominio y comprueba si tu casa está en orden antes de que las políticas de los grandes proveedores lo hagan por ti.
