SPF, DKIM y DMARC explicados (en lenguaje claro) | Scanthra

Scanthra · 7 min de lectura · Actualizado Mayo de 2026

La explicación en 30 segundos

• SPF — una lista de servidores autorizados a enviar correo desde tu dominio.
• DKIM — una firma digital en cada mensaje que demuestra que realmente vino de tu dominio y no fue manipulado.
• DMARC — tu política que indica a los receptores qué hacer con el correo que falla SPF o DKIM (permitir, poner en cuarentena, rechazar) y dónde enviar los reportes.

Los tres son registros TXT en DNS. Los añades una vez y los olvidas (hasta que cambias de proveedor de correo).

Por qué debería importarle a una pequeña empresa

Dos consecuencias concretas de no tener SPF/DKIM/DMARC, ambas comunes:

• Los clientes ven «via mailer.scanthra.net» en Gmail en lugar de tu dominio. Sutil, pero mata la confianza en el primer correo electrónico.
• Cualquiera puede hacerse pasar por ti. Un estafador envía «Factura vencida — paga esta cuenta» desde facturacion@tutienda.com a tus clientes. Con DMARC estricto, el mensaje se rechaza antes de llegar. Sin él, llega a la bandeja de entrada.

Microsoft y Google ahora exigen SPF + DKIM + DMARC para remitentes masivos (desde febrero de 2024). Si envías cualquier volumen de correo electrónico — incluso recibos transaccionales de una tienda WordPress — la ausencia de registros empezará a afectar la entregabilidad.

SPF — la lista de permitidos

Un registro SPF tiene este aspecto:

tudominio.com.  IN TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Tres cosas que saber:

• v=spf1 — siempre requerido, marcador de versión.
• include: — apunta al SPF de tu buzón o remitente transaccional. Cada proveedor te indica qué valor usar.
• ~all — la política para cualquier otro. Usa ~all (softfail) mientras pruebas, -all (hardfail) cuando esté estable.

Límite: 10 consultas DNS. Cada include: cuenta. Acumular demasiados proveedores rompe SPF silenciosamente. Si alcanzas el límite, usa un aplanador de SPF como el que incluyen EasyDMARC, Postmark o Cloudflare.

DKIM — la firma

DKIM firma cada mensaje saliente con una clave privada que vive en el servidor de correo, y publica la clave pública correspondiente en DNS:

selector1._domainkey.tudominio.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Cada proveedor tiene su propio selector (selector1, google, k1, etc.). Sigue las instrucciones de tu proveedor al pie de la letra — ellos generan el valor exacto que debes pegar. Puedes tener varios registros DKIM, uno por proveedor, uno al lado del otro.

DMARC — tu política

Un registro DMARC de inicio:

_dmarc.tudominio.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; pct=100; adkim=s; aspf=s"

Campos clave:

• p=none — recibe reportes, sin tomar acción. Empieza siempre aquí.
• p=quarantine — el correo que falla va a spam.
• p=reject — el correo que falla se rechaza. El estado objetivo.
• rua=mailto:... — reportes agregados diarios. Canalízalos a un lector gratuito como Postmark DMARC Digests o dmarcian.

El despliegue seguro

1. Añade SPF y DKIM para cada remitente legítimo (tu proveedor de buzón, remitente transaccional, herramienta de marketing, helpdesk).
2. Publica DMARC con p=none. Espera 2–4 semanas leyendo los reportes agregados.
3. Cuando todas las fuentes legítimas estén alineadas (sin líneas «fail» de tus propios servicios), pasa a p=quarantine.
4. Tras otras 2–4 semanas de reportes limpios, pasa a p=reject.

Este despliegue escalonado es lo que hace toda gran empresa. Saltar directamente a p=reject funciona — hasta el día en que Marketing compra una nueva herramienta y deja de recibir correos. Entonces es una crisis.

Errores comunes

• Dos registros SPF en el mismo hostname — no se suman, se anulan mutuamente. Siempre fúndelos en uno.
• Olvidar añadir SPF/DKIM para tu remitente de marketing (Mailchimp, Brevo, HubSpot). Esos también salen bajo tu dominio.
• Política de subdominio DMARC incorrecta (sp=) — si tienes p=reject pero no sp=, los subdominios heredan la política relajada. Sé explícito.
• Usar ?all en SPF. Es efectivamente «sin política» — los receptores lo ignoran.

Cómo Scanthra comprueba esto

Nuestro módulo Seguridad del Correo hace consultas DNS pasivas para SPF, DKIM (selectores habituales) y DMARC. Señalamos registros ausentes, políticas débiles (p=none solo después del período de gracia), desbordamiento del recuento de consultas SPF y registros SPF con ?all o +all. Verás el problema exacto en tu informe PDF.