DNS, SPF, DKIM, DMARC: Por Qué Tu Correo Va a Spam (y Cómo Los Atacantes Se Hacen Pasar por Ti) Todo lo que necesitas saber sobre los tres protocolos que separan tu correo legítimo de la carpeta de spam — y que separan tu marca de ser usada por estafadores. Introducción Envías un correo importante al cliente.
DNS, SPF, DKIM, DMARC: Por Qué Tu Correo Va a Spam (y Cómo Los Atacantes Se Hacen Pasar por Ti) Todo lo que necesitas saber sobre los tres protocolos que separan tu correo legítimo de la carpeta de spam — y que separan tu marca de ser usada por estafadores. Introducción Envías un correo importante al cliente. Responde dos días después: "disculpa, fue a spam". Envías otro a un lead, y simplemente nunca llega. Y mientras tanto, alguien en internet está enviando correo haciéndose pasar por tu empresa , pidiendo transferencias a tus clientes, y solo lo descubres cuando el cliente llama para reclamar. Bienvenido al mundo de la autenticación de correo. Un lugar donde tres siglas — SPF , DKIM y DMARC — deciden si existes digitalmente o no. La buena noticia es que estos tres protocolos resuelven el 95% de los problemas de entregabilidad y de spoofing. La mala noticia es que la absoluta mayoría de los dominios en internet no tienen ni uno de ellos configurado correctamente . Y desde febrero de 2024, Google y Yahoo pasaron a exigir DMARC para remitentes que envían más de 5.000 correos por día. Parte 1: El problema fundamental del correo El protocolo de correo (SMTP) fue creado en 1982 y no tenía ningún mecanismo de autenticación . Literalmente ninguno. Cualquier servidor puede enviar un correo diciendo ser de cualquier dirección. Durante décadas esto funcionó porque internet era pequeño. Llegó el spam, llegó el phishing, llegó el fraude organizado. La solución no fue reescribir SMTP — fue agregar capas de autenticación por encima, usando DNS: SPF (2006) — qué servidores pueden enviar correo en nombre de tu dominio DKIM (2007) — firma criptográficamente cada correo enviado DMARC (2012) — dice qué hacer cuando SPF y DKIM fallan, y te da reportes Los tres trabajan juntos. Solos, tienen agujeros. Combinados, forman defensa razonable. La autenticación de correo no es "seguridad opcional". Es infraestructura básica. Sin ella: los correos legítimos van a spam, los atacantes pueden hacerse pasar por ti, y Google/Yahoo simplemente rechazan mucho del tráfico de quién no autentica. Parte 2: SPF — Sender Policy Framework 2.1 Qué es Publicas en DNS una lista de servidores autorizados a enviar correo en nombre de tu dominio. El servidor de destino consulta esa lista y verifica si la IP de origen está autorizada. 2.2 Cómo configurar Un único registro TXT: Desglosando: v=spf1 — versión ip4:200.150.100.10 — autoriza esta IP include: spf.google.com — autoriza IPs de Google Workspace -all — cualquier otra IP es rechazada Mecanismos comunes: Mecanismo Qué hace ip4:1.2.3.4 IP específica ip4:1.2.3.0/24 Rango de IPs a IP del registro A mx IPs de los MX include:dominio.com Incluye SPF de otro dominio redirect=otro.com Reemplaza con SPF de otro Calificadores: Sintaxis Significado +all Acepta todo (NUNCA uses) -all Rechaza todo lo que no está en la lista all SoftFail — acepta pero marca ?all Neutral (igual a no tener SPF) 2.3 Ejemplos reales Solo Google Workspace: Solo Microsoft 365: Híbrido (M365 + servidor propio + marketing + transaccional): 2.4 Los límites del SPF Límite de 10 lookups DNS. Cada include, a, mx, exists cuenta. ¿Lo superaste? SPF se quiebra con permerror y para muchos servidores eso equivale a fallar. El límite es recursivo — si incluyes el SPF de Google, y Google incluye otros, todos cuentan. Se quiebra con reenvío. El correo reenviado viene de un servidor que no está en tu SPF. Falla. No protege el "From:" visible. SPF verifica el MAIL FROM (sobre), no el From: que aparece para el usuario. El atacante puede pasar SPF perfectamente y mostrar From: ceo@tuempresa.com.br. No tiene criptografía. Solo verifica IP. ¿Servidor autorizado comprometido? El atacante envía lo que quiera. 2.5 Verificar SPF 2.6 Errores comunes +all o ?all — anula la protección Múltiples registros SPF en el mismo dominio (solo puede haber uno) Sintaxis errada (espacios, comillas, orden) Olvidar incluir servicio nuevo Exceder 10 lookups include apuntando a dominio inexistente Parte 3: DKIM — DomainKeys Identified Mail 3.1 Qué es Firma digital criptográfica en cada correo enviado. Generas un par de claves (privada + pública) La clave pública va en DNS La clave privada queda en el servidor de correo El servidor firma cada correo enviado El servidor de destino obtiene la clave pública y verifica matemáticamente Garantiza autenticidad (vino realmente del dueño de la clave) e integridad (no fue alterado en el camino). 3.2 Cómo funciona un registro DKIM default. domainkey.empresa.com.br — formato [selector]. domainkey.[dominio] v=DKIM1 — versión k=rsa — algoritmo p=... — clave pública en Base64 El selector permite tener múltiples claves DKIM activas simultáneamente. Cada servicio usa su propio selector. 3.3 Cómo configurar Google Workspace: Admin Console → Apps → Gmail → Authenticate email → Generate. Publica el registro que te da. Microsoft 365: Defender → Email & collaboration → Threat policies → DKIM → activar (usa CNAMEs). Mailgun, SendGrid, Mailchimp, Amazo…