SPF, DKIM y DMARC: Tu Email Va al Spam

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:

empresa.com.br.   IN   TXT   "v=spf1 ip4:200.150.100.10 include:_spf.google.com -all"

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:

"v=spf1 include:_spf.google.com -all"

Solo Microsoft 365:

"v=spf1 include:spf.protection.outlook.com -all"

Híbrido (M365 + servidor propio + marketing + transaccional):

"v=spf1 ip4:200.150.100.10 include:spf.protection.outlook.com include:_spf.mailgun.org include:sendgrid.net -all"

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

dig TXT empresa.com.br +short

# Herramientas:
# - mxtoolbox.com/spf.aspx
# - dmarcian.com/spf-survey/
# - kitterman.com/spf/validate.html

2.6 Errores comunes

1. +all o ?all — anula la protección
2. Múltiples registros SPF en el mismo dominio (solo puede haber uno)
3. Sintaxis errada (espacios, comillas, orden)
4. Olvidar incluir servicio nuevo
5. Exceder 10 lookups
6. include apuntando a dominio inexistente

Parte 3: DKIM — DomainKeys Identified Mail

3.1 Qué es

Firma digital criptográfica en cada correo enviado.

1. Generas un par de claves (privada + pública)
2. La clave pública va en DNS
3. La clave privada queda en el servidor de correo
4. El servidor firma cada correo enviado
5. 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.   IN   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7VK..."

• 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, Amazon SES: todos tienen wizards.

Servidor propio (Postfix con OpenDKIM):

sudo apt install opendkim opendkim-tools
sudo mkdir -p /etc/opendkim/keys/empresa.com.br
cd /etc/opendkim/keys/empresa.com.br
sudo opendkim-genkey -s mail -d empresa.com.br -b 2048
sudo chown opendkim:opendkim mail.private
cat mail.txt  # registro DNS para publicar

3.4 Cómo DKIM firma

Header DKIM-Signature agregado a cada correo:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=empresa.com.br; s=default;
    h=from:to:subject:date:message-id;
    bh=BASE64_HASH_DEL_CUERPO;
    b=BASE64_FIRMA

• d= — dominio que firmó
• s= — selector
• h= — headers firmados
• bh= — hash del cuerpo
• b= — firma

3.5 Los límites del DKIM

Se quiebra con modificación en el camino. Las listas de correo que agregan pie de página invalidan la firma.

Clave débil. Usa 2048 bits como mínimo. RSA 1024 se considera quebrado.

Rotación inexistente. Las buenas prácticas dicen rotar cada 6-12 meses. Casi nadie lo hace.

No protege el From: visible por sí solo — el d= puede ser diferente del From:. Ahí es donde entra DMARC.

3.6 Verificar DKIM

dig TXT default._domainkey.empresa.com.br +short

Mejor forma: envía un correo a check-auth@verifier.port25.com y recibe un informe completo.

Parte 4: DMARC

4.1 Por qué existe

SPF y DKIM verifican cosas técnicas pero no imponen decisiones. Y ninguno de los dos verifica si el From: visible coincide con el dominio autenticado.

DMARC resuelve:

1. Alineación — exige que el From: visible coincida con dominio autenticado
2. Política — dice qué hacer cuando la autenticación falla
3. Reportes — recibes reportes diarios

4.2 Cómo funciona

_dmarc.empresa.com.br.   IN   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@empresa.com.br; ruf=mailto:dmarc-forensic@empresa.com.br; fo=1; adkim=s; aspf=s; pct=100"

| Parámetro | Función | |---|---| | v=DMARC1 | Versión | | p= | Política: none, quarantine, reject | | sp= | Política para subdominios | | rua= | Correo para reportes agregados (XML diario) | | ruf= | Correo para reportes forenses | | pct= | % del tráfico que aplica la política | | adkim= | Alineación DKIM: r o s | | aspf= | Alineación SPF: r o s | | fo= | Cuándo generar reportes forenses |

4.3 Las tres políticas

p=none — modo monitoreo. No hace nada, pero envía reportes. Comienza siempre por aquí.

p=quarantine — cuarentena. Los correos que fallan van a spam.

p=reject — rechazo. Los correos que fallan son rechazados en la entrega. El objetivo final.

4.4 Alineación — el concepto clave

Relajado (r): los dominios organizacionales coinciden. email.empresa.com.br se alinea con empresa.com.br. Estándar.

Estricto (s): tiene que ser exactamente igual.

Para pasar DMARC, el correo necesita:

1. Pasar SPF Y el MAIL FROM alinearse con el From:, O
2. Pasar DKIM Y el d= alinearse con el From:

4.5 Los reportes — el secreto de DMARC

Cuando defines rua=, recibes XMLs diarios de Google, Microsoft, Yahoo, etc. con:

• Cuántos correos fueron recibidos viniendo de tu dominio
• De qué IPs
• Cuántos pasaron SPF/DKIM/alineación
• Qué hizo el servidor de destino

Descubres cosas como:

• Esa herramienta de marketing contratada en 2022 que nadie te avisó
• El servidor de la sucursal que todavía usa el dominio principal sin autenticar
• Atacantes intentando spoofear tu dominio
• Proveedores legítimos enviando cosas en tu nombre

Los XMLs son horribles de leer. Usa servicios que hacen parsing: Postmark DMARC Monitoring (gratuito), Dmarcian, EasyDMARC, Valimail, OnDMARC.

4.6 El viaje recomendado

1. Configura SPF y DKIM primero.

2. Comienza con p=none:

"v=DMARC1; p=none; rua=mailto:dmarc@empresa.com.br; fo=1"

3. Monitorea por 2-4 semanas con Dmarcian/Postmark.

4. Migra a p=quarantine con pct=10:

"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@empresa.com.br; fo=1"

5. Aumenta el pct= gradualmente — 25%, 50%, 75%, 100%.

6. Pasa a p=reject:

"v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@empresa.com.br; ruf=mailto:dmarc-forensic@empresa.com.br; fo=1; adkim=s; aspf=s"

El viaje toma 1-3 meses para hacer con calma. No saltes a reject directamente a menos que quieras pasar la noche explicando al CEO por qué los correos se detuvieron.

4.7 Errores comunes

1. Saltar a p=reject directamente
2. Ignorar los reportes (todo el valor está en ellos)
3. DMARC sin SPF y DKIM funcionando
4. Olvidar sp= para subdominios
5. RUA en el mismo dominio sin fallback externo

Parte 5: Cómo funcionan realmente los ataques de spoofing

5.1 Spoofing directo

El atacante envía un correo diciendo From: ceo@empresa.com.br. Sin SPF/DKIM/DMARC, llega normalmente.

Defensa: SPF con -all + DMARC con p=reject.

5.2 Spoofing por subdominio

empresa.com.br tiene DMARC. Pero vendas.empresa.com.br no. El atacante usa el subdominio.

Defensa: siempre sp=reject en el DMARC del principal.

5.3 Dominio parecido (cousin)

El atacante registra empressa.com.br (dos s), empresa.com.co, empresa-soporte.com. Técnicamente es suyo, pasa todos los checks, parece el tuyo.

Defensa: monitoreo de dominios similares (DomainTools, DNSTwist), capacitación, BIMI, herramientas de protección de marca.

5.4 Spoofing de nombre de visualización

El atacante usa su propio correo pero coloca "Ceo Empresa" en el nombre de visualización. El cliente móvil solo muestra "Ceo Empresa".

Defensa: capacitación + filtros que detectan spoofing de nombre de visualización.

5.5 Toma de cuenta

El atacante obtiene acceso a la cuenta legítima (phishing, contraseña filtrada). Todo pasa todos los checks porque es realmente legítimo.

Defensa: MFA, monitoreo de comportamiento anómalo.

5.6 Compromiso de cadena de suministro

El atacante compromete a tu proveedor. Envía correos del servidor real del proveedor, frecuentemente respondiendo threads existentes.

Defensa: vigilancia, capacitación, verificación fuera del canal para solicitudes financieras.

Parte 6: Las otras siglas

6.1 MTA-STS

"HSTS del correo". Garantiza entrega via TLS criptografado, impide degradación. La configuración tiene dos partes: registro DNS + página HTTPS en mta-sts.empresa.com.br.

6.2 TLS-RPT

Reportes sobre fallos de TLS en la entrega.

_smtp._tls.empresa.com.br.   IN   TXT   "v=TLSRPTv1; rua=mailto:tls-reports@empresa.com.br"

6.3 BIMI

Logo verificado de tu marca apareciendo en la bandeja de entrada del destinatario. Requiere DMARC con p=quarantine o p=reject + logo SVG + idealmente VMC (certificado de pago).

Diferencial visual enorme de credibilidad.

6.4 ARC

Resuelve el problema de reenvío/listas que quiebran SPF/DKIM. Los servidores intermediarios atestiguan la autenticación original. Implementado automáticamente por los grandes proveedores.

6.5 DNSSEC

Protege contra falsificación del propio DNS. Firma criptográficamente los registros. Capa extra esencial.

Parte 7: Por qué los correos van a spam

En orden de frecuencia:

1. Falta de SPF/DKIM/DMARC
2. SPF excediendo 10 lookups
3. Sintaxis errada en SPF/DKIM/DMARC
4. Reputación de la IP (verifica en mxtoolbox.com/blacklists.aspx)
5. Reputación del dominio (dominios nuevos son sospechosos)
6. Contenido problemático (palabras gatillo, exceso de imágenes, HTML mal formado)
7. Falta de DNS inverso (PTR)
8. HELO/EHLO incorrecto
9. Volumen súbito (sin warming)
10. Lista mala (muchos bounces)

7.1 Herramientas de diagnóstico

Análisis completo:

• mxtoolbox.com/SuperTool.aspx
• dmarcian.com/dmarc-inspector/
• mail-tester.com (recibe calificación 0-10)
• check-auth@verifier.port25.com (envía correo, recibe informe)
• mecsa.jrc.ec.europa.eu

Terminal:

dig TXT empresa.com.br +short | grep spf
dig TXT default._domainkey.empresa.com.br +short
dig TXT _dmarc.empresa.com.br +short
dig MX empresa.com.br +short
dig -x 200.150.100.10 +short

Headers de correo recibido: Gmail → tres puntitos → "Mostrar original". Busca Authentication-Results::

Authentication-Results: mx.google.com;
    spf=pass smtp.mailfrom=sender@empresa.com.br;
    dkim=pass header.i=@empresa.com.br header.s=default;
    dmarc=pass (p=REJECT) header.from=empresa.com.br

pass en los tres es lo que quieres.

Parte 8: Recomendaciones prácticas

1. Verifica tu estado actual en mxtoolbox.com ahora
2. Lista todos los servicios que envían correo en tu nombre
3. Configura SPF correctamente — todos los servicios, -all, debajo de 10 lookups
4. Configura DKIM en todos los servicios — claves de 2048 bits
5. Configura DMARC en p=none — comienza monitoreando
6. Lee los reportes DMARC por 2-4 semanas
7. Migra a p=quarantine gradualmente
8. Llega a p=reject
9. Configura sp=reject para subdominios
10. Considera MTA-STS, TLS-RPT, BIMI
11. Habilita DNSSEC
12. Monitorea continuamente

Consideraciones finales

La autenticación de correo parece complicada hasta que lo haces una vez. SPF, DKIM y DMARC juntos resuelven el 95% de los problemas de entregabilidad e impiden el 95% de los ataques de spoofing directo.

No hacer esto, en 2026, es negligencia. Google y Yahoo ya están rechazando masivamente a quién no autentica. En algunos años, enviar correo sin SPF/DKIM/DMARC será tan impensable como modem discado.

Y lo mejor: no es caro. Los tres protocolos son gratuitos, la documentación es abundante, las herramientas de monitoreo tienen tier gratuito, el resultado es inmediato.

El SentinelHub barre exactamente esto: monitorea SPF, DKIM, DMARC, MTA-STS, DNSSEC y todos los registros DNS críticos de tu dominio. Cuando algo cambia — alguien agrega un servicio nuevo y sobrepasa el límite de SPF, alguien elimina accidentalmente el registro DMARC, alguien olvida renovar una clave DKIM — te enteras. En portugués.

Cliente que recibe tu correo en la carpeta de spam es cliente que pierdes confianza. Cliente que recibe correo de estafador haciéndose pasar por ti es cliente que pierdes.

¿Te pareció útil? Comparte con tu equipo de marketing y con el sysadmin que cuida del servidor de correo. Especialmente si todavía envían correos marcados como "[SPAM]" a la propia bandeja.