La entregabilidad del email es una cuestión de rendimiento comercial, no solo una tarea de IT. Si la autenticación de tu dominio es débil o incoherente, incluso una buena prospección puede no llegar a la bandeja de entrada y no darle nunca a tu prospecto la oportunidad de interactuar. Esta guía explica el papel estratégico de DKIM, SPF y DMARC en la prospección en frío, cómo influyen en el alcance de los compradores y en la confianza en el remitente, y cómo plantear la autenticación como parte de una estrategia outbound escalable.

Importante: DKIM, SPF y DMARC se configuran en los ajustes DNS de tu dominio (GoDaddy, Namecheap, Cloudflare, Squarespace, etc.). lemlist no aloja estos registros, pero una autenticación correcta favorece una mejor llegada a la bandeja de entrada y resultados de campaña más constantes.

Los equipos de outbound suelen centrarse en la segmentación, los mensajes y los seguimientos, pero nada de eso importa si los proveedores de buzones de correo no confían en el dominio de envío. La autenticación ayuda a demostrar que tus emails son legítimos, reduce el riesgo de suplantación de identidad (spoofing) y da a los proveedores señales de confianza más claras cuando deciden si entregar, filtrar o rechazar tus mensajes.

Sin una configuración sólida, los cold emails pueden ser limitados, enviarse a spam o bloquearse por completo, lo que hace mucho más difícil optimizar la tasa de respuesta. Los equipos que tratan la entregabilidad como parte de su estrategia comercial suelen obtener resultados más estables, sobre todo cuando aumentan el volumen de envío o añaden nuevas herramientas a su stack.

Principio 1: la entregabilidad forma parte de tu sistema de ventas.

La llegada a la bandeja de entrada determina si tu propuesta de valor llega siquiera a verse. Una autenticación sólida no sustituye a un buen texto, pero crea las condiciones para que tu prospección compita en igualdad de condiciones en la bandeja de entrada.

Principio 2: la reputación de tu dominio se comparte entre herramientas.

Tu dominio puede enviar emails a través de Google o Microsoft, lemlist, herramientas de soporte, CRMs, sistemas de facturación y notificaciones del sitio web. Cuando una parte de ese sistema está mal configurada, puede generar problemas de confianza que afectan a toda tu estrategia outbound.

Principio 3: la autenticación es gestión de riesgos, no un growth hack.

DKIM, SPF y DMARC existen para reducir el fraude y el abuso. El verdadero objetivo es un rendimiento predecible: menos fallos de autenticación, menos suplantación de identidad y más confianza al escalar las campañas.

Principio 4: DMARC debe tener un efecto real, no ser simbólico.

Muchos equipos publican DMARC con p=none solo para poder decir que lo tienen. En la práctica, eso suele ofrecer poca protección real, porque no estás indicando a los servidores receptores que actúen cuando falla la autenticación.

Principio 5: la simplicidad reduce los fallos.

Los errores más comunes son operativos: registros SPF duplicados, remitentes olvidados y valores DNS copiados que no coinciden con el proveedor real. Una responsabilidad clara y un inventario de remitentes ordenado evitan la mayoría de estos problemas antes de que afecten a los resultados.

Cuándo usarla: antes de actualizar SPF, DKIM o DMARC, o cada vez que tu equipo añada una nueva herramienta de email.

Cómo funciona: haz una lista de todas las plataformas que envían emails con tu dominio, incluidos los proveedores de buzones de correo, las herramientas de prospección, los sistemas de soporte (helpdesk), los CRMs, las herramientas transaccionales y las notificaciones del sitio web. Después, identifica si cada una depende de SPF, de DKIM o de ambos.

Por qué funciona: la mayoría de los problemas de entregabilidad se deben a una visibilidad incompleta, no a malas intenciones. Si olvidas un remitente legítimo, puedes arreglar la prospección y, sin querer, romper los emails de soporte, las facturas o los restablecimientos de contraseña.

Ejemplo real: un equipo actualiza SPF para la prospección, pero olvida su proveedor de helpdesk. Los cold emails mejoran durante un tiempo, pero las respuestas del servicio de atención al cliente empiezan a fallar las comprobaciones de DMARC. El problema no era la nueva configuración en sí, sino la falta de un inventario de remitentes.

Cuándo usarla: cuando tu dominio ya tiene un registro SPF y necesitas añadir otra plataforma de envío.

Cómo funciona: SPF debe existir como un único registro TXT para el dominio. En lugar de crear un nuevo registro SPF para cada herramienta, combinas los include de todos los remitentes legítimos en un solo registro.

Por qué funciona: tener varios registros SPF puede invalidar por completo las comprobaciones de SPF. Desde el punto de vista comercial, eso significa que el correo outbound legítimo puede perder señales de confianza y sufrir más filtrado.

Ejemplo real:

Este enfoque protege todo el stack de envío en lugar de optimizarlo para una herramienta a costa de otra.

Cuándo usarla: siempre que configures o revises tu infraestructura de envío principal.

Cómo funciona: DKIM añade una firma criptográfica a los mensajes salientes para que los servidores receptores puedan verificar que el dominio autorizó el email y que no se modificó durante el envío.

Por qué funciona: DKIM refuerza la confianza porque vincula el mensaje a una identidad de remitente aprobada. Para los equipos de outbound que envían secuencias y seguimientos, esa coherencia es importante, porque los proveedores de buzones de correo evalúan patrones a lo largo del tiempo, no mensajes aislados.

Ejemplo real: dos equipos envían cold emails con una redacción similar. Uno tiene DKIM válido en su proveedor de envío y el otro no. El equipo con DKIM tiene más probabilidades de lograr una llegada estable a la bandeja de entrada, porque los proveedores tienen una señal más sólida de que los mensajes son auténticos.

Cuándo usarla: una vez que SPF y DKIM están configurados y quieres una estrategia de protección del dominio más sólida.

Cómo funciona: DMARC indica a los servidores receptores qué hacer cuando SPF o DKIM fallan la alineación, y puede enviar informes que te ayudan a entender quién envía correo en nombre de tu dominio. Un punto de partida práctico es p=quarantine, que da a los proveedores una señal clara de aplicación sin pasar directamente a la opción más estricta.

Por qué funciona: DMARC conecta tu configuración de autenticación con una política real. Reduce el riesgo de suplantación de identidad, mejora la coherencia de la confianza y ayuda a los equipos a detectar problemas ocultos con los remitentes antes de que se conviertan en problemas de reputación mayores.

Ejemplo real:

Esto da a tu dominio una política de partida con efecto real y te deja margen para pasar más adelante a p=reject si tienes un proceso de informes que lo respalde.

Qué está pasando: es posible que el dominio tenga ahora dos registros SPF, o que se eliminara un remitente antiguo al añadir el nuevo.

Cómo responder: comprueba que solo haya un registro TXT de SPF y que incluya todos los servicios de envío aprobados. Revisa todos los remitentes críticos para el negocio, no solo el que se usa para la prospección en frío.

Mensaje para enviar internamente: “¿Puedes confirmar que tenemos un único registro SPF y que incluye nuestro proveedor de buzones de correo y todas las plataformas que envían desde nuestro dominio, incluidas las herramientas de CRM, soporte, transaccionales y de prospección?”

Qué está pasando: uno o varios remitentes fallan la alineación de SPF o DKIM, y DMARC ahora está aplicando ese fallo.

Cómo responder: identifica qué remitente falla y, después, actualiza su include de SPF o su configuración de DKIM. Si la aplicación es demasiado estricta para el estado actual de tu configuración, baja de p=reject a p=quarantine mientras lo corriges.

Mensaje para enviar internamente: “¿Qué remitente falla la alineación de DMARC y necesita un include de SPF, configurar DKIM o ambas cosas antes de volver a una aplicación más estricta?”

Qué está pasando: las migraciones de proveedor suelen requerir nuevos selectores DKIM e include de SPF actualizados. Es posible que los registros antiguos sigan existiendo y generen confusión.

Cómo responder: vuelve a auditar el stack de remitentes, publica los registros que exige el nuevo proveedor y confirma la alineación de DMARC antes de aplicar políticas más estrictas. No des por hecho que un cambio de proveedor afecta solo a una parte de tu flujo de trabajo outbound.

Mensaje para enviar internamente: “Ahora que hemos cambiado de proveedor, ¿podemos verificar la alineación de DKIM, SPF y DMARC en todos los servicios de envío antes de escalar la prospección?”

Error 1: tratar la autenticación como la configuración de una sola herramienta.

Por qué es contraproducente: tu dominio suele dar servicio a varios sistemas de la empresa. Optimizar los DNS solo para la prospección puede romper otros remitentes legítimos y generar problemas de reputación más amplios.

Qué hacer en su lugar: gestiona la autenticación a nivel de dominio y mantén un inventario completo de remitentes antes de hacer cambios.

Error 2: crear varios registros SPF.

Por qué es contraproducente: los servidores receptores pueden considerar SPF no válido, lo que debilita la confianza y puede provocar más fallos de autenticación.

Qué hacer en su lugar: mantén un único registro SPF y combina en él todos los include necesarios.

Error 3: copiar valores DNS sin comprobar la configuración real del proveedor.

Por qué es contraproducente: los selectores DKIM y los requisitos de SPF varían según el proveedor y la configuración. Los valores genéricos pueden dejarte con una configuración que parece completa, pero que falla en la práctica.

Qué hacer en su lugar: verifica siempre los valores con la documentación oficial de tu proveedor de email.

Error 4: dejar DMARC en p=none indefinidamente.

Por qué es contraproducente: ofrece poca aplicación real y puede tratarse de forma similar a no tener una política de DMARC real. Obtienes menos protección y señales de confianza más débiles.

Qué hacer en su lugar: usa como mínimo p=quarantine como punto de partida práctico y pasa a p=reject solo si puedes gestionar el trabajo de informes y alineación.

Ejercicio 1: crea tu inventario de remitentes.

Haz una lista de todos los sistemas que envían emails con tu dominio. Para cada uno, anota el responsable, el caso de uso y si depende de SPF, de DKIM o de ambos. Esta lista será tu referencia cada vez que se añada una nueva herramienta.

Ejercicio 2: revisa tu estrategia de DNS con los equipos de ventas e IT a la vez.

Haz una sola pregunta: “Si el mes que viene añadimos una nueva herramienta de envío, ¿cómo actualizaremos la autenticación sin romper nada?”. Si no hay una respuesta clara, tu proceso es demasiado frágil.

Ejercicio 3: define la hoja de ruta de tu política de DMARC.

Decide si la política estable de tu equipo será p=quarantine o p=reject. Si piensas usar reject, documenta quién revisa los informes de DMARC y cómo se escalarán los fallos de los remitentes legítimos.

Ejercicio 4: haz una auditoría trimestral de autenticación.

Una vez por trimestre, confirma que SPF sigue siendo un único registro, que DKIM está activado para los remitentes principales y que DMARC corresponde al nivel de aplicación que pretendes. Esto ayuda a evitar que la entregabilidad se deteriore poco a poco.

Envío escalable: una vez que la autenticación de tu dominio está bien configurada, lemlist puede funcionar sobre una base de entregabilidad más sólida. Así, el rendimiento de tus campañas es más estable a medida que aumentas el volumen.

Mejores pruebas de la calidad de la prospección: cuando la autenticación está en buen estado, es más probable que los cambios en la tasa de respuesta reflejen tu segmentación, tu posicionamiento y tus mensajes, y no problemas técnicos de confianza.

Coordinación más segura con los administradores: si los equipos de ventas e IT trabajan juntos en la entregabilidad, lemlist da a los equipos de outbound un motivo claro para priorizar la autenticación como parte de la preparación de las campañas, y no como algo secundario.

Estabilidad de la llegada a la bandeja de entrada: busca menos caídas repentinas del rendimiento de las campañas cuando aumenta el volumen de envío o se añaden nuevas bandejas de entrada. Si los resultados siguen siendo inestables, revisa la autenticación antes de reescribir los textos.

Bounces relacionados con la autenticación: comprueba si los registros de bounces o los mensajes de los proveedores muestran menos fallos de política, alineación o autenticación con el tiempo. Una reducción en este punto es una clara señal de que tu configuración es cada vez más fiable.

Visibilidad de DMARC: si usas informes, fíjate en si hay menos remitentes desconocidos y mayores tasas de alineación. Si los informes siguen mostrando mucho ruido, es probable que tu dominio todavía tenga fuentes sin controlar o mal configuradas.

Confianza operativa: tu equipo debería poder añadir un nuevo remitente sin tener que adivinar cómo afecta a la entregabilidad. Si cada cambio en los DNS parece arriesgado, el proceso todavía necesita mejoras.

Ejemplo 1: el problema del SPF duplicado

Situación: un equipo añadió un segundo registro TXT de SPF al incorporar una nueva plataforma de envío.

Enfoque: auditaron todos los remitentes, eliminaron el registro duplicado y combinaron ambos servicios en una sola entrada SPF.

Qué pasó: los errores de autenticación disminuyeron tras la propagación de los DNS y el rendimiento de las campañas se estabilizó.

Resultado: el problema no era la calidad de los mensajes, sino un fallo de confianza causado por una estructura SPF no válida.

Ejemplo 2: la política quarantine de DMARC descubrió un remitente oculto

Situación: una empresa activó DMARC con quarantine para reducir la suplantación de identidad y mejorar la protección del dominio.

Enfoque: poco después, notaron que algunos emails relacionados con el soporte se estaban filtrando. Los informes de DMARC mostraron que la plataforma de helpdesk no estaba bien alineada mediante SPF ni DKIM.

Qué pasó: tras actualizar la configuración del remitente, el email de soporte y el outbound pudieron coexistir de forma más segura en el mismo dominio.

Resultado: el equipo mantuvo la aplicación de DMARC sin sacrificar el correo legítimo de la empresa.

DKIM: confirma que el mensaje se firmó y no se modificó.

SPF: confirma que el remitente está autorizado a enviar en nombre del dominio.

DMARC: indica a los servidores receptores qué hacer cuando SPF o DKIM fallan la alineación.

Mejor punto de partida: usa DKIM + un único registro SPF + DMARC configurado como mínimo en p=quarantine.

Recuerda: un dominio puede tener muchos remitentes, pero solo un registro SPF.

Antes de hacer cambios: audita todas las plataformas que envían desde el dominio.

Antes de usar reject: asegúrate de que alguien pueda revisar los informes de DMARC e investigar los fallos.

Pasar de p=quarantine a p=reject puede ofrecer una protección más sólida contra la suplantación de identidad, pero también aumenta lo que está en juego a nivel operativo. Si un remitente legítimo no está alineado, reject puede bloquear ese correo por completo en lugar de solo filtrarlo de forma más agresiva.

Los informes de DMARC suelen ser complejos y normalmente llegan como archivos XML dentro de archivos adjuntos comprimidos. Si tu equipo no tiene un proceso de postmaster ni una herramienta de informes para interpretarlos, p=quarantine suele ser la política más segura a largo plazo.