SPF, DKIM y DMARC: por qué tus emails caen en spam

Gastaste semanas escribiendo la newsletter perfecta. La enviaste a 5.000 contactos. Abriste el informe al día siguiente: tasa de entrega 62%. El resto fue a spam — o ni llegó.

La culpa rara vez es del contenido. Es de tres siglas que probablemente no configuraste bien: SPF, DKIM y DMARC.

El problema que estas siglas resuelven

El email es un protocolo de los años 1980. Cuando se creó, cualquier servidor podía enviar un mensaje diciendo ser cualquiera. Ahora mismo puedo configurar un servidor SMTP y enviar un email con From: presidente@gov.br — el protocolo no lo impide.

Por 40 años, eso fue la puerta de entrada de phishing, spam y fraudes corporativos. SPF, DKIM y DMARC son las tres capas que el sector añadió para que el servidor que recibe pueda verificar que el email vino realmente de quien dice que vino.

Quien no tiene estas tres configuradas hoy es tratado como sospechoso por defecto. Gmail y Yahoo, desde febrero de 2024, exigen las tres para remitentes que envían volumen.

SPF — "quién puede enviar email en mi nombre"

SPF (Sender Policy Framework) es un registro DNS que lista los servidores autorizados a enviar email con tu dominio en el From.

Aspecto típico:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Se lee: "los emails de mi dominio pueden venir de Google Workspace O de SendGrid. Cualquier otro servidor, márcalo como sospechoso (~all = softfail)."

Qué sale mal:

• El límite de 10 lookups DNS (RFC 7208 §4.6.4). Cada include: cuenta. Si tienes include:_spf.google.com include:sendgrid.net include:mailchimp.com include:mailgun.org include:_spf.mandrillapp.com… probablemente ya reventaste el límite. Resultado: toda validación SPF devuelve permerror y el email va a spam.
• +all al final — significa "cualquier servidor puede enviar en mi nombre". Es como dejar la puerta abierta. Nunca lo uses.
• Olvidar un servicio. Enviaste la factura por un sistema nuevo, olvidaste añadirlo al SPF, y la factura fue al spam del cliente. Pasó.

DKIM — "este email no fue alterado en el camino"

DKIM (DomainKeys Identified Mail) firma cada email enviado con una clave criptográfica. El servidor que recibe consulta el DNS, toma la clave pública correspondiente, y verifica la firma.

Si coinciden, dos hechos quedan comprobados:

1. El email vino realmente de quien tiene la clave privada (el servidor autorizado).
2. El contenido no fue modificado en tránsito.

Qué sale mal:

• No configurarlo. El servicio de envío genera las claves, pero tú necesitas añadir el registro DNS (un TXT en selector._domainkey.tudominio.com). Sin eso, no hay DKIM.
• Selector equivocado. Cada proveedor usa un nombre diferente: Google usa google, SendGrid usa s1/s2, Mailchimp usa k1/k2. Configuraste el selector equivocado, DKIM falla.
• Clave débil. Las claves DKIM de 1024 bits aún se aceptan pero el sector pide 2048+.

DMARC — "qué hacer cuando SPF o DKIM falla"

SPF y DKIM dicen "este email es legítimo" o "este email es sospechoso". Pero ¿quién decide qué hacer con el sospechoso? Sin DMARC, cada proveedor decide a su manera.

DMARC (Domain-based Message Authentication, Reporting and Conformance) es la política. Dices en el DNS:

v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com; pct=100

Se lee: "si SPF y DKIM fallan, rechaza el email. Y mándame un informe semanal sobre quién intenta hacerse pasar por mí."

Los tres modos de política:

• p=none — solo monitorea, no hace nada. Úsalo al inicio.
• p=quarantine — manda a spam cuando falla.
• p=reject — bloquea totalmente.

Qué sale mal:

• Saltar a p=reject directo sin monitorear. Descubres que tu propia herramienta de RR. HH. o sistema interno enviaba con tu dominio y nunca pasó SPF/DKIM. De repente ningún colaborador recibe el recibo de sueldo por email. Empieza siempre en p=none, lee los informes por 2-4 semanas, después sube.
• No publicar DMARC. Gmail y Yahoo ahora exigen al menos p=none para remitentes con volumen. Sin DMARC, tu entregabilidad va colapsando lentamente.
• Falta de alineamiento. El From: debe coincidir con el dominio firmado por DKIM y/o autorizado por SPF. Si envías como marketing@tudominio.com pero el SPF autoriza mail.servicio-tercero.com, no hay alineamiento y DMARC falla.

Cómo verificar ahora

Puedes comprobarlo manualmente:

dig +short TXT tudominio.com | grep spf
dig +short TXT _dmarc.tudominio.com
dig +short TXT google._domainkey.tudominio.com   # o el selector que uses

Pero para un diagnóstico continuo — porque el DNS cambia, se añaden servicios nuevos, y DKIM puede desactivarse en rotación de claves — lo ideal es monitorear desde fuera.

Qué comprueba Sentinela

El probe de Email de Sentinela analiza, en cada audit:

• SPF ¿existe? ¿Cuántos lookups DNS consume? ¿Está cerca o por encima del límite de 10? ¿Tiene +all? ¿Tiene múltiples registros (que viola la RFC)?
• DKIM — prueba selectors comunes (default, google, selector1, selector2, k1, k2, s1, s2, mail, etc.). Reporta cuáles existen, tamaño de la clave, si está revocada.
• DMARC ¿está publicado? ¿En qué policy (none, quarantine, reject)? ¿Tiene rua configurado para recibir informes?
• MX ¿apunta a servidores válidos y responsivos?
• DNSSEC ¿está habilitado para el dominio?

El resultado va en un PDF de auditoría con severidad por finding (critical/high/medium/low/info) — exactamente el tipo de documento que tu equipo de TI o tu cliente querrá ver.

Crea una cuenta gratis y corre el primer audit en menos de 1 minuto. Descubres al instante si tu entregabilidad está comprometida — antes de gastar la próxima campaña.

La regla simple

Si envías email por tu dominio — newsletter, transaccional, soporte, lo que sea — necesitas las tres configuradas. Ya no es opción. Los proveedores grandes (Gmail, Outlook, Yahoo, iCloud) ya lo tratan como obligatorio, y eso solo se va a apretar.

La buena noticia: configúralo una vez bien, monitoréalo periódicamente, y dura años. La mala: la mayoría de las empresas configuró la mitad, hace dos años, y nadie lo mira más. Míralo hoy.