SPF, DKIM y DMARC para email en frío: lista de verificación de configuración

Por qué fallan los emails en frío cuando la autenticación DNS está mal

La autenticación de correo es la forma en que una bandeja de entrada comprueba si tu mensaje realmente está autorizado a venir de tu dominio. No se trata de escribir mejor copy. Se trata de probar identidad.

Cuando envías un email en frío, el servidor receptor mira el dominio en la dirección From y ejecuta tres comprobaciones principales:

• SPF: ¿lo envió un servidor autorizado?
• DKIM: ¿está el mensaje firmado por el dominio?
• DMARC: ¿qué debe hacer el receptor si esas comprobaciones fallan, y se alinean los dominios?

Los dominios de envío nuevos son juzgados con más rigor porque no tienen historial. Un dominio recién creado con señales DNS débiles o rotas parece arriesgado, aunque tu intención sea buena. Por eso los errores de autenticación perjudican el outreach en frío antes que a marcas ya establecidas.

Los registros DNS defectuosos suelen causar problemas de tres maneras silenciosas: tu correo se acepta pero llega a spam, se rechaza por completo (rebotes duros o bloqueos), o llega a veces pero tu dominio empieza a ganar mala reputación.

Los errores pequeños son a menudo la causa. Dos registros SPF TXT separados pueden provocar un fallo. Una clave DKIM pegada con un carácter faltante no verificará. Un DMARC con política agresiva antes de que todo esté alineado puede bloquear envíos normales.

Esta lista de verificación se centra en SPF, DKIM y DMARC en términos prácticos: qué publicar, qué evitar y cómo verificar resultados antes de escalar envíos. No cubre copywriting, calidad de listas, encaje de oferta ni cumplimiento local.

El modelo simple: qué se comprueba cuando envías

Cuando envías un email en frío, normalmente hay dos dominios implicados, y mezclarlos causa mucha confusión.

El dominio de envío es el que el destinatario ve en la dirección From ([email protected]). El dominio del buzón (a veces distinto) es el dominio que realmente envía el mensaje detrás de escena, como un subdominio dedicado de envío o un dominio propiedad del proveedor. Para buena entregabilidad, estos deben ser consistentes o al menos claramente conectados.

Del dominio From a la bandeja: las tres comprobaciones

La mayoría de las bandejas siguen el mismo flujo básico:

1. SPF comprueba el Return-Path oculto (también llamado envelope sender) y pregunta si este servidor está autorizado a enviar para ese dominio.
2. DKIM comprueba la firma DKIM y pregunta si el dominio que firma coincide con lo enviado.
3. DMARC mira el dominio visible en From y pregunta si SPF y/o DKIM se alinean con él, luego aplica tu política.

Alineación, sin jerga

Alineación es simplemente “¿coinciden los dominios?”. Hay tres lugares que mirar:

• From: lo que ven las personas (ejemplo: @yourdomain.com)
• Return-Path: lo que usa SPF (podría ser @mail.yourdomain.com u otro)
• DKIM d=: el dominio que firmó el mensaje (ejemplo: d=yourdomain.com)

DMARC pasa cuando el dominio From se alinea con SPF (dominio del Return-Path) y/o con DKIM (el dominio d=). No todo tiene que ser idéntico, pero debe ser intencional.

Qué pasa cuando las comprobaciones fallan

Los proveedores no reaccionan todos igual, pero los resultados son predecibles:

• p=none (monitorización): el correo suele seguir llegando y tú recoges informes.
• p=quarantine: el correo tiene más probabilidad de acabar en spam.
• p=reject: el correo se bloquea.

Incluso antes de que DMARC esté estricto, los fallos repetidos suelen reducir la colocación en bandeja con el tiempo.

Ejemplo: envías desde [email protected], pero SPF solo autoriza otro dominio y DKIM firma como d=anotherdomain.com. El mensaje puede parecer “sin dueño”, así que los filtros se muestran cautelosos.

Antes de tocar DNS: prepara una configuración limpia

La mayoría de los problemas de entregabilidad empiezan antes de que alguien añada un registro DNS. Prepárate bien y tu configuración será más rápida, limpia y fácil de depurar.

Empieza por decidir qué dominio aparecerá en la dirección From. Muchos equipos usan un dominio de envío dedicado (o un subdominio) para que su dominio principal no sea lo primero en peligro si algo sale mal.

Después, elige cómo vas a enviar y recoge los valores exactos de registro que necesitas. Tu proveedor de email te dará un valor SPF específico, nombres de selectores DKIM y claves, y un registro DMARC sugerido. No adivines ni reutilices registros de otro dominio.

Antes de hacer cambios, confirma cuatro cosas básicas: qué dominio From usarás exactamente, qué proveedor(es) enviarán correo, dónde se gestiona realmente el DNS y quién tiene permiso para publicar registros TXT y CNAME.

Asegúrate también de estar en el panel correcto. La gente suele comprar un dominio en un sitio, alojar DNS en otro y editar registros en el lugar equivocado. Si no estás seguro, comprueba qué nameservers usa el dominio e inicia sesión en el proveedor que los controla.

Un plan de cambios simple ayuda a prevenir ediciones “útiles” que rompen el correo existente. Normalmente actualizarás SPF (con cuidado, especialmente si ya existe), añadirás DKIM y publicarás DMARC en modo monitorización. Deja los registros MX, A y los del sitio web fuera salvo que sepas por qué los cambias.

SPF: añade los servidores correctos y evita el límite de búsquedas

SPF es un registro TXT en DNS que dice a los proveedores qué servidores pueden enviar correo para tu dominio. En outreach en frío, SPF es una de las primeras comprobaciones que decide si tu mensaje parece normal o sospechoso.

Un buen registro SPF es una pequeña lista blanca que cubre todos los lugares que pueden enviar como tu dominio: tu remitente de cold email, Google Workspace o Microsoft 365 (si los usas) y cualquier herramienta de soporte o CRM que envíe correo en tu nombre.

Qué poner en tu registro SPF

La mayoría de los dominios nuevos solo necesitan unos pocos elementos:

• include: cuando un proveedor te indica que incluyas su SPF. Mantén los include al mínimo porque consumen búsquedas DNS.
• ip4:/ip6: cuando tienes una IP de envío fija. Esto evita búsquedas, pero solo funciona si las IPs son realmente estables.
• a y mx: solo si el servidor propio de tu dominio o el intercambiador de correo envía correo directamente (muchas configuraciones de cold email no los necesitan).

Aquí hay una forma limpia de ejemplo (tus valores variarán):

v=spf1 include:YOUR-SENDER-SPF ip4:203.0.113.10 ~all

Elige el final correcto: -all vs ~all

La última parte es tu regla por defecto para todo lo que no está listado.

~all (soft fail) es un inicio más seguro mientras pruebas y puede que hayas olvidado un remitente. -all (hard fail) es mejor cuando tienes confianza, porque indica claramente a los proveedores que rechacen los remitentes no autorizados.

Para dominios nuevos de salida, empieza con ~all durante la configuración y los envíos iniciales, y luego cambia a -all después de verificar que nada legítimo está fallando.

Mantente por debajo del límite de 10 búsquedas

SPF tiene un límite duro de 10 búsquedas DNS. Demasiados include pueden romper SPF y perjudicar silenciosamente la entregabilidad.

Para mantenerte dentro del límite, reduce los include, evita cadenas de include anidadas, elimina herramientas antiguas de las que ya no envías y asegúrate de publicar un solo registro SPF TXT por dominio. Múltiples registros SPF pueden causar un permerror.

DKIM: publica claves correctamente y mantén selectores ordenados

DKIM añade una firma digital a cada correo que envías. Los servidores receptores usan la clave pública en tu DNS para verificar que el mensaje no se modificó y que tu dominio está autorizado a firmar correo. DKIM es a menudo lo que hace que un dominio nuevo parezca consistente con el tiempo.

Cómo funcionan los selectores (y por qué los nombres importan)

Un selector DKIM es una etiqueta que apunta a una clave pública específica. Tu sistema de envío firma los correos con ese selector, y el receptor busca un registro DNS en:

selector._domainkey.yourdomain.com

Los selectores permiten rotar claves sin romper el correo, pero también pueden crear confusión. Si reutilizas el mismo selector siempre, las rotaciones se vuelven riesgosas. Si creas selectores constantemente, tu DNS se llena.

Un enfoque simple es usar un selector estable y descriptivo como s1, mail o 2026q1, y rotar de forma intencional cuando sea necesario.

TXT vs CNAME: lo que verás en DNS

Algunos proveedores publican DKIM como un registro TXT con la clave completa. Otros te dan un CNAME que apunta a un registro alojado. Ambos funcionan si (y solo si) publicas exactamente lo que tu proveedor espera.

Los problemas más comunes de DKIM son sencillos: tipo de registro erróneo (TXT vs CNAME), comillas extra o saltos de línea ocultos, pegar solo parte de la clave, poner el registro en el dominio raíz en lugar de selector._domainkey, o dejar selectores antiguos activos con registros en conflicto.

Si la verificación DKIM falla, no adivines. Vuelve a copiar el valor desde el proveedor, republícalo limpio y vuelve a probar tras la actualización DNS.

DMARC: empieza con monitorización y luego endurece la política

DMARC es la capa de “qué deberían hacer los receptores con los fallos”. SPF y DKIM dicen a Gmail u Outlook qué comprobar. DMARC añade una política clara (none, quarantine, reject) y exige alineación con el dominio visible en From.

Una forma práctica de empezar es con monitorización. Publica DMARC con p=none para que puedas ver qué pasa sin arriesgar caídas de entregabilidad por una política demasiado estricta. Déjalo correr unos días mientras envías volúmenes pequeños y luego endúrécelo por pasos.

Aquí hay un patrón de registro inicial seguro (ajusta correos y dominio):

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100; fo=1"

Mantén las opciones simples. La alineación estricta (adkim=s y aspf=s) es una buena opción por defecto para dominios dedicados de salida donde controlas el remitente. pct=100 mantiene el comportamiento consistente. fo=1 es una configuración razonable para pedir un informe cuando algo falla.

Ten cuidado con las direcciones de reporte. Los informes agregados (rua) pueden ser útiles, pero solo si alguien los revisa. Los informes forenses (ruf) suelen bloquearse y pueden crear problemas de privacidad y ruido, por lo que suele ser mejor omitir ruf por completo.

Paso a paso: autentica un dominio de envío totalmente nuevo

Trata un dominio nuevo como una sala limpia. Tus registros DNS deben coincidir con tu remitente real, así que decide de entrada desde dónde vas a enviar.

1) Limpia la zona DNS primero

En tu host DNS, busca registros TXT existentes que mencionen SPF, DKIM o DMARC. Los dominios nuevos a veces traen registros iniciales, pruebas antiguas o duplicados de intentos previos. Elimina lo que no reconozcas y asegúrate de tener solo un registro SPF TXT para el dominio raíz.

2) Añade la autenticación en un orden seguro

Agrega un tipo de registro a la vez y confirma que esté visible antes de pasar al siguiente:

1. SPF: publica un solo registro SPF TXT que incluya solo los servicios que enviarán correo para este dominio.
2. DKIM: añade los registros DKIM que tu remitente proporciona (a menudo CNAMEs, a veces un TXT). Asegúrate de que el selector coincida con la configuración de firma del remitente.
3. DMARC: publica un registro DMARC TXT en _dmarc.tudominio con p=none para empezar.

3) Espera y vuelve a comprobar los valores exactos

Los cambios DNS no siempre son instantáneos. Tras publicar registros, vuelve a comprobar qué está realmente en vivo. Confirma que hay un solo registro SPF, que DKIM coincide exactamente y que DMARC está en el subdominio _dmarc.

4) Envía emails reales y verifica "pass" en los encabezados

Envía unos pocos correos sencillos (sin adjuntos, sin HTML pesado) a cuentas que controles, como Gmail y Outlook. Abre los detalles del mensaje y busca Authentication-Results. Quieres spf=pass, dkim=pass y dmarc=pass.

Si SPF falla, suele ser un include equivocado o dos registros SPF. Si DKIM falla, suele ser un selector desajustado o un error tipográfico en el valor DNS.

Cuando consigas pases consistentes, sigue con el calentamiento y volúmenes de envío controlados.

Errores comunes de DNS que perjudican silenciosamente la entrega

La mayoría de los problemas con un dominio nuevo no son fallos dramáticos. Son detalles DNS pequeños que aún permiten enviar correo, pero hacen que los receptores confíen menos en ti.

Dos problemas aparecen constantemente:

Primero, publicar dos registros SPF en el mismo dominio. Un dominio debe tener solo un registro SPF TXT. Si necesitas Google y una herramienta de envío, fusiona todo en un único registro v=spf1 y mantén un solo final (~all o -all).

Segundo, golpear el permerror de SPF por demasiadas búsquedas. Los include añaden búsquedas, y los include anidados añaden aún más. Recorta herramientas no usadas, mantén el registro corto y evita apilar proveedores “por si acaso”.

En DKIM, la falla más común es el desajuste de selector. Tu proveedor firma con un selector específico (como s1 o default). Si tu DNS publica otro selector, los receptores no pueden verificar DKIM aunque exista un registro.

Las fallas de DMARC suelen confundir porque SPF puede pasar y DMARC seguir fallando. DMARC requiere alineación con el From visible. Si envías desde [email protected] pero el Return-Path es brand-mail.com y DKIM firma como d=brand-mail.com, puedes tener SPF en pass y DMARC en fail.

Lista rápida: verificación final en 10 minutos

Antes de enviar volumen real, haz una pasada rápida para asegurarte de que los registros están limpios y que tus mensajes realmente se autentican.

Confirma que hay exactamente un registro SPF TXT en el dominio raíz. Confirma que DKIM está publicado para el dominio desde el que envías y que el selector coincide con lo que usa tu herramienta de envío. Confirma que hay exactamente un registro DMARC en _dmarc.example.com y empieza con p=none.

Si acabas de cambiar registros, espera un poco. Muchos momentos de “sigue fallando” son caché DNS.

Luego envía un email de prueba real a una bandeja que puedas inspeccionar y revisa Authentication-Results. Buscas spf=pass, dkim=pass y dmarc=pass.

Arreglos rápidos cuando algo falla:

• SPF falla: include equivocado, dominio equivocado (raíz vs subdominio) o dos registros SPF.
• DKIM falla: desajuste de selector, espacios/comillas extra o firma desactivada.
• DMARC falla: registro DMARC ausente, publicado en el raíz en vez de _dmarc, o SPF/DKIM no alineados con el dominio From.

Ejemplo y próximos pasos para un dominio nuevo de cold email

Una configuración simple sería: compras un dominio nuevo solo para outbound y creas unos cuantos buzones (alex@, sam@, info@). Mantienes separado el dominio principal de la empresa para que un error no afecte el correo diario.

Un cronograma realista:

• Día 0: Publicar SPF, DKIM y DMARC en modo monitorización (p=none).
• Día 1: Enviar emails de prueba y verificar que SPF/DKIM/DMARC pasen. Corregir errores tipográficos y nombres de host equivocados.
• Días 2-3: Empezar con volumen muy bajo mientras comienza el calentamiento.
• Fin de la semana 1: Revisar informes DMARC y rebotes, luego corregir cualquier desalineación.
• Semana 2+: Si todo está estable, mover a p=quarantine y después a p=reject.

Si ves SPF en pass pero DMARC en fail, normalmente significa que la alineación está rota, no que el DNS esté totalmente equivocado. La solución más rápida suele ser asegurarte de que DKIM está habilitado y firma con tu dominio de envío, ya que la alineación DKIM suele ser más estable que SPF cuando cambian herramientas.

Tras que la autenticación sea correcta, los resultados dependen del comportamiento, no solo de los registros. Calienta lentamente, mantiene el volumen inicial bajo, documenta cambios DNS, evita cambiar de proveedor en el primer mes y vigila de cerca rebotes y bajas.

Si quieres reducir el número de herramientas implicadas, LeadTrain (leadtrain.app) combina configuración de dominio, configuración SPF/DKIM/DMARC, calentamiento, secuencias multi-paso y clasificación de respuestas en una sola plataforma, lo que puede facilitar mantener la alineación consistente al añadir dominios y buzones.