Cómo configurar SPF, DKIM y DMARC paso a paso (2026)

SPF, DKIM y DMARC son los tres registros DNS que separan tu cold email entre bandeja de entrada o carpeta de spam — sin ellos, la entregabilidad cae al 20-30% en 2026. Esta guía explica qué hace cada uno en lenguaje claro, da los valores exactos para Google Workspace, Microsoft 365 y cuentas SMTP genéricas, y cubre la configuración en los tres registradores DNS más comunes en habla hispana (GoDaddy, Cloudflare y Namecheap), terminando con cómo verificar con MXToolbox que los tres funcionan.

La sensación general de cualquiera que arranca con cold email es que esto es "técnico" y "de informáticos". No lo es. Son tres registros TXT en el panel DNS de tu dominio. Si tienes acceso a Cloudflare, GoDaddy o Namecheap, los puedes configurar tú mismo en 30-45 minutos. Lo único que requiere atención es el orden (SPF primero, DKIM después, DMARC al final) y empezar DMARC en modo conservador para no bloquear emails legítimos por error.

Por qué SPF, DKIM y DMARC son innegociables en 2026

Desde febrero de 2024 Google y Yahoo exigen autenticación SPF, DKIM y DMARC para cualquier remitente que envíe más de 5.000 emails al día a sus usuarios. Microsoft sigue la misma política. En 2026, sin estos tres registros, tu cold email simplemente no llega.

• Servidores de email modernos filtran por reputación y autenticación: si tu dominio no demuestra criptográficamente que el email sale de ti, va directo a spam o se rechaza. La reputación se construye con autenticación correcta, no con buen copy.
• Sin SPF/DKIM/DMARC tu email parece spoofing: los filtros lo interpretan como intento de suplantación de identidad, igual que cuando alguien envía phishing usando tu marca. La política agresiva por defecto desde 2024 es bloquearlo.
• Política Gmail/Yahoo de febrero 2024: rechazan automáticamente cualquier email sin autenticación DNS correcta si el remitente envía más de 5.000/día. Para volúmenes menores, los emails caen en spam con altísima probabilidad.
• Impacto medido en entregabilidad: con los tres bien configurados, entregabilidad típica del 70-85% en cold email. Sin ellos, baja al 20-40%. La diferencia entre rentable y tirar el dinero.
• No es opcional, es base técnica: cualquier herramienta de cold email seria (Instantly, Smartlead, Lemlist) avisa de que sin los tres registros no se puede empezar. Es el paso cero, no un "bonus".

Qué hace cada uno en lenguaje claro

Antes de tocar el DNS conviene entender qué hace cada registro y por qué los tres son necesarios. La analogía postal funciona bien: imagina que tu email es una carta que llega al servidor del destinatario, y los tres registros son tres comprobaciones distintas que hace el cartero.

• SPF (Sender Policy Framework): lista oficial de qué servidores están autorizados a enviar emails desde tu dominio. Dice "estos servidores son legítimos remitentes de @midominio.com". Si un email llega de un servidor no listado, falla SPF. Es el remitente autorizado en la analogía postal.
• DKIM (DomainKeys Identified Mail): firma digital criptográfica que se añade a cada email saliente. El servidor receptor verifica con la clave pública que está en tu DNS que el email fue firmado por ti y no fue manipulado. Es el sello firmado y lacrado de la carta.
• DMARC (Domain-based Message Authentication Reporting & Conformance): política que define qué hacer cuando un email falla SPF o DKIM. Las tres políticas posibles son `none` (solo monitoriza), `quarantine` (manda a spam) y `reject` (rechaza). Es la instrucción al cartero sobre qué hacer con cartas sospechosas.
• Los tres trabajan juntos: si falta SPF, DKIM no basta; si falta DKIM, SPF no basta; sin DMARC, los receptores no saben qué hacer con los fallos. Faltar uno de los tres tira entregabilidad un 30-50% en 2026.
• Tiempo para configurar los tres desde cero: 30-45 minutos para alguien sin experiencia técnica si sigue los pasos exactos, más 1-24 horas de propagación DNS antes de poder enviar el primer email.

Cómo configurar SPF: valores exactos por proveedor

SPF se configura como un único registro TXT en el dominio raíz. Solo puede haber un registro SPF por dominio — si tienes más de uno, los servidores receptores los ignoran todos y SPF falla. Si vas a usar varios proveedores (por ejemplo Google Workspace para envíos normales e Instantly.ai para cold email), tienes que combinarlos en un único registro con varios `include`.

1. Accede al panel DNS de tu dominio (Cloudflare, GoDaddy, Namecheap o el registrador donde tengas el dominio). Busca la sección "DNS", "DNS Management" o "Records".
2. Crea un nuevo registro TXT con nombre `@` (que representa el dominio raíz) o el nombre del dominio según el registrador.
3. Valor si usas Google Workspace: `v=spf1 include:_spf.google.com ~all`. El `~all` (soft fail) es lo recomendado al empezar; pasar a `-all` (hard fail) cuando esté todo estable.
4. Valor si usas Microsoft 365: `v=spf1 include:spf.protection.outlook.com ~all`.
5. Si usas también Instantly.ai u otra herramienta de cold email: combinar en un solo registro: `v=spf1 include:_spf.google.com include:spf.instantly.ai ~all`. Lo mismo con Smartlead (`include:spf.smartlead.ai`) o Lemlist.
6. TTL (Time To Live): 3600 segundos (1 hora) es el estándar recomendado. Permite cambios rápidos sin esperar 24h de propagación.
7. Guarda y espera propagación: entre 15 minutos y 24 horas según registrador. Cloudflare propaga en minutos; GoDaddy y Namecheap pueden tardar varias horas.

Cómo configurar DKIM con tu proveedor de email

DKIM funciona distinto a SPF: cada proveedor de email genera su propia clave criptográfica que tú copias en tu DNS. El nombre del registro varía según el proveedor (`google._domainkey` para Workspace, `selector1._domainkey` para Microsoft 365). El paso que más confunde a la gente es que tienes que generar la clave en el proveedor antes de añadirla al DNS.

1. Google Workspace: ve a Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Selecciona tu dominio y clic en "Generate new record". Copia el valor TXT generado (es una cadena criptográfica larga, 1.024 o 2.048 bits).
2. Microsoft 365: Microsoft 365 admin center → Security → Policies → DKIM. Selecciona dominio, activa DKIM signing y copia los dos selectores que se generan (`selector1` y `selector2`).
3. Cuenta SMTP genérica (Brevo, SendGrid, Mailgun, etc.): el proveedor da en su panel de configuración el valor exacto del registro DKIM, normalmente bajo "Sender authentication" o "Domain verification".
4. En tu DNS, crea un registro TXT con el nombre exacto que indica el proveedor (`google._domainkey`, `selector1._domainkey`, etc.) y pega el valor copiado tal cual, sin saltos de línea ni espacios añadidos.
5. Si la cadena DKIM es muy larga: algunos paneles DNS la cortan automáticamente con comillas (`"parte1" "parte2"`). Eso está bien siempre que las comillas estén balanceadas. Si tu panel no soporta comillas, comprueba que el registrador permita registros TXT largos (>255 caracteres).
6. Espera propagación (15 minutos en Cloudflare, hasta varias horas en otros).
7. Vuelve a tu proveedor y verifica: en Google Workspace, clic en "Start authentication" tras añadir el registro. Debe pasar de "Not authenticating" a "Authenticating email". En Microsoft 365, el panel DKIM mostrará los selectores en verde.

Cómo configurar DMARC sin romper nada

DMARC es el último paso y el más delicado: si lo configuras con política agresiva (`reject`) sin haber validado antes que SPF y DKIM funcionan al 100%, puedes bloquear emails legítimos tuyos. La regla es empezar siempre con `p=none` durante 1-2 semanas, leer los reportes y luego escalar a `quarantine` y finalmente `reject`.

1. Crea un nuevo registro TXT en DNS con nombre `_dmarc` (el guion bajo es importante). Algunos paneles requieren `_dmarc.tudominio.com`.
2. Valor inicial conservador (monitorización): `v=DMARC1; p=none; rua=mailto:tu@tudominio.com; ruf=mailto:tu@tudominio.com; fo=1`. Política `none` significa "no rechaces nada, solo envíame reportes".
3. `rua=`: dirección de email donde quieres recibir los reportes agregados (resumen diario de emails enviados, qué pasaron SPF/DKIM, cuáles fallaron).
4. `ruf=`: dirección de email donde recibir reportes forenses individuales por cada email que falla (opcional, genera mucho ruido).
5. TTL: 3600 segundos.
6. Tras 1-2 semanas con `p=none` funcionando y sin sorpresas en los reportes: subir a `p=quarantine; pct=50` (manda a spam el 50% de los emails que fallan). Esperar otra semana.
7. Una vez todo limpio: subir a `p=quarantine; pct=100` durante 2 semanas y finalmente `p=reject; pct=100` para máxima seguridad.
8. Saltar a `p=reject` el día uno es el error más común: si SPF o DKIM tienen un fallo menor, bloqueas tus propios emails sin saberlo. Mejor escalar gradual.

Configuración por registrador DNS: GoDaddy, Cloudflare, Namecheap

El concepto es idéntico en los tres registradores, pero los nombres de los campos cambian un poco. Estas son las particularidades a tener en cuenta en cada uno en 2026, basadas en las interfaces actuales (pueden cambiar — si algo no cuadra, mira la documentación oficial de Cloudflare DNS que es la más mantenida).

• Cloudflare: panel "DNS" → "Records" → "Add record". Tipo TXT, nombre `@` (raíz) o `_dmarc`. Pega el valor en "Content". TTL en "Auto". Es el más rápido en propagación (5-15 minutos). Recomendado para cualquier uso serio de email.
• GoDaddy: "My Products" → tu dominio → "DNS" → "Add Record". Tipo TXT. En "Host" pon `@` o `_dmarc`. En "TXT Value" pega el valor. TTL 1 hora. Propagación más lenta (1-12 horas). Cuidado: el campo "Host" no admite el dominio completo, solo `@` o el subdominio.
• Namecheap: "Domain List" → "Manage" → "Advanced DNS". Add new record TXT. En "Host" `@` o `_dmarc`. "Value" el contenido del registro. TTL 1 hora. Propagación 1-6 horas habitualmente.
• Particularidad en GoDaddy con SPF: si el dominio tiene email de GoDaddy por defecto, GoDaddy auto-añade un SPF con `include:secureserver.net`. Si vas a usar Workspace o Microsoft, ese SPF se queda obsoleto y hay que reemplazarlo completo, no añadir un segundo.
• Particularidad en Cloudflare con TTL: el modo "Auto" funciona bien para registros nuevos, pero cambia automáticamente según el plan. Si necesitas un TTL fijo, ponlo a 3600 manualmente.

Cómo verificar que los tres funcionan con MXToolbox

Una vez configurados los tres registros y pasadas las horas de propagación, hay que verificar que efectivamente están bien. La herramienta de referencia es MXToolbox, gratis y exhaustiva. Complementarla con un test real desde mail-tester.com da el cuadro completo.

• MXToolbox SPF Record Lookup: introduces tu dominio y devuelve el registro SPF, valida sintaxis, marca si hay múltiples records (error grave), comprueba que los `include` resuelven correctamente. Objetivo: todo en verde, un solo registro SPF.
• MXToolbox DKIM Lookup: requiere conocer el selector (`google`, `selector1`, etc.). Comprueba que la clave pública existe en DNS y es válida. Objetivo: "DKIM record found" en verde.
• MXToolbox DMARC Lookup: valida el registro `_dmarc`, comprueba sintaxis y muestra la política actual. Objetivo: política reportada correctamente (`p=none` al principio, `p=quarantine` o `p=reject` más adelante).
• mail-tester.com: envías un email de prueba desde tu dominio a la dirección que te da. Devuelve un score de 0-10. Objetivo: 9-10/10. Cualquier puntuación por debajo de 8 indica algún problema (autenticación, contenido, reverso DNS, etc.).
• Instantly.ai Settings → Email Health Check o equivalente en otras herramientas: dentro de la propia herramienta de cold email, todos los emails conectados deben pasar el check de SPF/DKIM/DMARC con tick verde antes de empezar campañas.
• Reportes DMARC (rua): a las 24-48h de tener DMARC configurado, empiezan a llegar reportes diarios en XML. Servicios como Postmark DMARC Digests o Dmarcian los convierten en informes legibles gratis.

Errores típicos en la configuración DNS y cómo detectarlos

Estos cinco errores son responsables del 80% de los problemas de autenticación que vemos en cuentas que han hecho "todo bien" pero siguen yendo a spam. Conviene revisarlos uno por uno cuando algo no cuadra.

• Múltiples registros SPF en el mismo dominio: solo puede haber un SPF por dominio. Si tienes dos (típico al añadir Instantly sin quitar el anterior), los servidores los ignoran todos y SPF falla en silencio. Solución: combinar todos los `include` en un único registro.
• Alineación DKIM mal configurada: DKIM solo es válido si el dominio firmante coincide con el dominio del remitente (alineación estricta) o pertenece a la misma organización (alineación relajada). Cuando una herramienta envía con `From: tu@tudominio.com` pero firma con `mailgun.org`, la alineación falla y DMARC marca el email como sospechoso aunque DKIM técnicamente pase.
• TTL demasiado alto (86400): si pones TTL de 24h, cualquier cambio tarda un día en propagar. Mientras tanto envías con configuración mixta y los resultados son erráticos. Mejor TTL 3600 (1h) durante toda la fase de setup y luego subir si quieres.
• Cadena DKIM cortada al copiar: los registros TXT largos (más de 255 caracteres) se cortan en algunos paneles DNS. Si pegas la clave DKIM y solo se guardan los primeros 255 caracteres, DKIM falla. Solución: usar comillas dobles para concatenar (`"v=DKIM1; k=rsa;" "p=MIGfMA0..."`).
• DMARC `p=reject` desde el día uno sin validar: si SPF o DKIM tienen un fallo menor (alineación, include olvidado), `p=reject` bloquea tus propios emails legítimos. Siempre empezar con `p=none` 1-2 semanas, leer reportes y luego escalar.

Una vez los tres registros pasan en MXToolbox, queda el otro pilar de la entregabilidad: calentar el dominio. Está cubierto en qué es el warm-up de un dominio y cómo se hace y cómo hacer el warm-up con Instantly. Para verificar la salud global del dominio antes de empezar campañas, mira la checklist de salud de dominio para cold email.

Preguntas frecuentes

[Accede a los recursos](https://chat.whatsapp.com/Jfp2uay7DxeBE77ZnYrEn5).