SPF, DKIM, DMARC: la guía completa para configurar tu email (2026)

SPF, DKIM y DMARC: si envías emails y, particularmente, emails de prospección, seguro te has cruzado con estos tres acrónimos. Y probablemente ya soltaste un suspiro de desesperación frente a la documentación técnica. En 2026, estos tres protocolos de autenticación de email ya no son opcionales: desde febrero de 2024, Google y Yahoo rechazan los emails no autenticados de los remitentes masivos, y Microsoft hizo lo mismo en mayo de 2025. Para los equipos que hacen cold email B2B, se convirtió en la condición mínima para llegar a la bandeja de entrada. En esta guía completa, te explicamos exactamente qué son SPF, DKIM y DMARC, cómo funcionan juntos y, sobre todo, cómo configurarlos correctamente en tu dominio. Con ejemplos concretos de registros DNS, los errores comunes que debes evitar y una FAQ para responder todas tus preguntas.

SPF, DKIM y DMARC son tres protocolos de autenticación de email complementarios. Cada uno cumple un rol diferente y preciso en la verificación de que un email enviado desde tu dominio es realmente legítimo.

• SPF (Sender Policy Framework): declara qué servidores están autorizados a enviar emails desde tu dominio.

• DKIM (DomainKeys Identified Mail): agrega una firma criptográfica a cada email para probar que no ha sido alterado.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): le indica a los servidores destinatarios qué hacer si SPF o DKIM fallan, y envía reportes de monitoreo.

Configurar los tres correctamente es la condición mínima para llegar a la bandeja de entrada en 2026. Si falta uno solo de los tres, tus emails corren el riesgo de caer en spam o, peor aún, de ser rechazados directamente por Gmail, Outlook o Yahoo.

SPF es el más antiguo de los tres protocolos (apareció oficialmente en 2006 con la RFC 4408, actualizado en 2014 con la RFC 7208). Su principio es simple: publicas en tu DNS la lista de servidores autorizados a enviar emails en nombre de tu dominio. Cuando un servidor recibe un email que dice venir de tu dominio, verifica que la dirección IP del remitente figure efectivamente en esa lista.

SPF se implementa mediante un registro TXT en tu zona DNS, en la raíz de tu dominio. Aquí tienes un ejemplo tipo:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Este registro dice: «Los emails desde este dominio pueden ser enviados por los servidores de Google Workspace o Microsoft 365. Cualquier otro servidor debe considerarse sospechoso (~all = soft fail).»

Si tu empresa utiliza varios servicios de envío (Google Workspace para los emails internos, una herramienta de cold email como Emelia, y una herramienta transaccional como SendGrid), tu SPF debe incluirlos a todos:

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

SPF impone una restricción técnica que a menudo se olvida: un registro SPF no puede generar más de 10 lookups DNS. Cada mecanismo include: dispara un lookup adicional, y algunos servicios (como Microsoft 365) consumen varios por sí solos. Más allá de 10, todo el SPF devuelve un error PermError y la verificación falla. Si tienes muchos servicios que autorizar, debes «aplanar» tu SPF (SPF flattening) con una herramienta dedicada.

El mecanismo final de tu SPF determina cómo los servidores tratan un email que falla la verificación.

• ~all (soft fail): el email falla SPF pero igual puede entregarse, generalmente marcado como sospechoso. Recomendado durante la fase de instalación y la mayor parte del tiempo en 2026.

• -all (hard fail): el email es rechazado por los servidores estrictos. Úsalo únicamente después de haber validado que todos tus servicios de envío legítimos están en el SPF.

En 2026, la práctica recomendada es comenzar con ~all y luego, después de validar mediante los reportes DMARC que todo está limpio, pasar a -all si quieres ser estricto.

DKIM (RFC 6376) agrega una firma criptográfica a cada email saliente. Esta firma, calculada con una clave privada, es verificada por el servidor destinatario gracias a una clave pública publicada en tu DNS. DKIM prueba dos cosas: que el mensaje viene efectivamente de tu dominio, y que no ha sido modificado en tránsito.

Cuando tu servidor de envío manda un email, calcula una huella criptográfica del contenido (encabezado + cuerpo) y la cifra con una clave privada. Esta firma se agrega en el encabezado DKIM-Signature del email. El servidor destinatario recupera la clave pública correspondiente en tu DNS, descifra la firma y verifica que coincida con el email recibido. Si una sola coma fue modificada en el camino, la verificación falla.

Un registro DKIM es un TXT publicado en un selector específico en tu DNS. El selector (selector) permite tener varias claves DKIM en paralelo, lo cual es útil para la rotación. Formato tipo:

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

Concretamente, tu proveedor de email (Google Workspace, Microsoft 365, o una herramienta como Emelia) genera el par de claves y te da el contenido exacto para pegar en tu zona DNS.

Aquí está la razón por la que DKIM es tan importante: a diferencia de SPF, DKIM sobrevive al reenvío de email. Cuando un destinatario reenvía tu mensaje a alguien más, la dirección IP del remitente cambia (ya no es tu servidor, sino el servidor de la persona que reenvía). En consecuencia, SPF falla mecánicamente. Pero la firma DKIM permanece intacta mientras el contenido no sea modificado. Es por eso que, en 2026, DKIM se convirtió en la piedra angular de la autenticación de email.

Las claves DKIM existen históricamente en 1024 bits o 2048 bits. En 2026, la recomendación clara de la industria es usar 2048 bits. Las claves de 1024 todavía son aceptadas pero cada vez más penalizadas por los filtros antispam. Idealmente, rota tus claves DKIM cada 6 a 12 meses para limitar la ventana de riesgo en caso de fuga de la clave privada.

DMARC (RFC 7489) no reemplaza ni a SPF ni a DKIM. Se agrega por encima para responder a dos preguntas: «¿Qué debe hacer el servidor destinatario si SPF o DKIM fallan?» y «¿Cómo sé quién intenta enviar emails en nombre de mi dominio?».

DMARC se apoya en un concepto llamado alineación. Para que un email pase DMARC, es necesario que SPF o DKIM tenga éxito Y que el dominio verificado por uno de los dos coincida con el dominio visible en el campo «From» del email (el que ve el destinatario). Sin esa alineación, un atacante podría pasar SPF con su propio dominio mientras se hace pasar por ti en el From, lo cual es exactamente la técnica de suplantación que DMARC impide.

DMARC se publica como un TXT en _dmarc.tudominio.com:

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

La etiqueta p= define lo que los servidores deben hacer en caso de fallo:

• p=none: monitoreo únicamente, el email se entrega normalmente. Es el modo de arranque recomendado para recolectar reportes sin romper nada.

• p=quarantine: los emails no autenticados van a spam. Etapa intermedia tras algunas semanas de monitoreo limpio.

• p=reject: los emails no autenticados son rechazados directamente. Es el modo objetivo final, que ofrece la mejor protección contra la suplantación.

La progresión normal en 2026: comenzar en p=none durante 4-6 semanas, analizar los reportes DMARC, corregir todas las fuentes de email legítimas que fallan, luego pasar a p=quarantine durante 2-4 semanas, y finalmente p=reject.

Las etiquetas aspf= y adkim= controlan el nivel de alineación requerido entre los dominios.

• Modo relaxed (r): los subdominios son aceptados. Si tu From es «contact@tudominio.com» y SPF pasa con «mail.tudominio.com», la alineación está OK. Es el modo recomendado para la mayoría de las organizaciones.

• Modo strict (s): se necesita una coincidencia exacta. «contact@tudominio.com» y «mail.tudominio.com» ya no están alineados. Úsalo únicamente si tienes control total sobre todos tus subdominios de envío.

Es sin duda el beneficio más subestimado de DMARC. Con rua=mailto:dmarc@tudominio.com, recibes diariamente reportes XML agregados que detallan quién intenta enviar emails en nombre de tu dominio, desde qué IPs, y con qué tasa de éxito SPF/DKIM. Estos reportes revelan los servicios olvidados (que envían por ti sin autenticación), los intentos de suplantación y los errores de configuración. Varias herramientas gratuitas o de pago como dmarcian, Postmark DMARC o URIports parsean estos XML en dashboards legibles.

Cada protocolo cubre un hueco que los otros no llenan:

• SPF solo no alcanza: verifica la IP del servidor de envío (Return-Path), no el From visible. Un atacante puede pasar SPF con su propio dominio mientras spoofea el tuyo en el From.

• DKIM solo no alcanza: prueba que el mensaje no ha sido alterado, pero no le indica al servidor destinatario qué hacer en caso de fallo. Y no todos los remitentes firman con DKIM.

• DMARC solo no tiene efecto: se apoya en SPF o DKIM para funcionar. Sin ellos, DMARC no tiene nada que evaluar.

Juntos, los tres forman un sistema completo: SPF verifica la IP, DKIM verifica la integridad del contenido, DMARC aplica la política y ofrece la visibilidad. Es exactamente por eso que Google, Yahoo, Outlook y Apple ahora exigen los tres para los remitentes masivos.

El orden lógico de implementación es: SPF primero (el más rápido), DKIM después (requiere la generación de un par de claves), DMARC al final (depende de los otros dos). Aquí está el procedimiento.

Lista todos los servicios que envían emails en nombre de tu dominio: tu proveedor de mensajería (Google Workspace, Microsoft 365), tus herramientas de cold email, tus servicios transaccionales, tus newsletters. Pídele a cada uno el valor de include: a usar. Combínalos en un solo registro TXT en la raíz de tu dominio. Comienza con ~all (soft fail). Luego verifica mediante una herramienta como MXToolbox que el registro sea sintácticamente correcto y se mantenga dentro del límite de los 10 lookups.

Para cada servicio de envío, sigue el procedimiento de generación de clave DKIM en su interfaz (Google Workspace: Apps → Gmail → Autenticar el email → Generar un nuevo record en 2048 bits). Copia el TXT proporcionado y publícalo en tu DNS en el selector indicado. Espera la propagación DNS (5 a 60 minutos), luego activa la autenticación en la interfaz del proveedor. Repite para cada herramienta de envío.

Comienza con una política permisiva para recolectar reportes sin arriesgarte a bloquear tráfico legítimo:

v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; pct=100; aspf=r; adkim=r

Durante 4 a 6 semanas, lee los reportes diarios e identifica todas las fuentes de email legítimas que fallan. Corrígelas (agrega el include SPF faltante, activa DKIM en el servicio olvidado, etc.). Una vez que tus reportes estén limpios, pasa a p=quarantine durante 2-4 semanas, luego p=reject.

Varias herramientas gratuitas permiten probar tu configuración:

• MXToolbox: verificación SPF, DKIM, DMARC y diagnóstico completo del dominio.

• Google Admin Toolbox: diagnóstico específico para los dominios Google Workspace.

• dmarcian: análisis de los reportes DMARC en dashboard legible.

• Comando dig en local: «dig TXT tudominio.com» para SPF, «dig TXT _dmarc.tudominio.com» para DMARC.

Incluso con las mejores intenciones, ciertos errores se repiten constantemente en las configuraciones SPF, DKIM y DMARC.

• Superar el límite de los 10 lookups DNS en SPF: tu registro devuelve un error PermError y todo falla. Aplana tu SPF si es necesario.

• Publicar varios registros SPF distintos: solo puedes tener un único TXT SPF por dominio. Varios registros = fallo automático.

• Olvidar alinear el dominio de envío: si DMARC está en modo strict y tu From está en el dominio raíz mientras que SPF pasa con un subdominio, la alineación falla.

• No monitorear los reportes DMARC: publicar un DMARC en p=none sin leer nunca los reportes es inútil. Es precisamente el momento en que se identifican los problemas.

• Usar una clave DKIM demasiado corta (1024 bits): cada vez más penalizada por los filtros modernos. Prioriza 2048 bits.

• Pasar a p=reject demasiado rápido: sin monitoreo previo, bloqueas tus propios emails legítimos. Cuenta mínimo 6 semanas antes del enforcement.

Si haces cold email B2B en 2026, configurar correctamente SPF, DKIM y DMARC no es una opción: es la condición de supervivencia de tus campañas. Los umbrales de tolerancia de los filtros antispam se endurecieron radicalmente desde 2024: Gmail, Outlook y Yahoo ahora rechazan los emails no autenticados en lugar de simplemente clasificarlos como spam como antes. Concretamente, un cold email enviado desde un dominio sin SPF/DKIM/DMARC correctos tiene una probabilidad cercana a cero de llegar a la bandeja de entrada.

El otro punto crítico: tu reputación de dominio se construye sobre el conjunto de los emails enviados. Si una parte de tus envíos está mal autenticada, todo tu dominio se ve afectado. Por eso los profesionales del cold email suelen usar dominios dedicados a la prospección (por ejemplo «empresa-contacto.com» en lugar del dominio principal «empresa.com»), con su propio SPF/DKIM/DMARC, para aislar su reputación.

En Emelia, la autenticación SPF/DKIM/DMARC se gestiona automáticamente cuando conectas tus buzones de correo a la plataforma. La configuración DNS queda de tu lado (mantienes el control de tu dominio), pero la herramienta te guía paso a paso y verifica la validez de tu setup antes de cada envío de campaña.

SPF, DKIM y DMARC ya no son una opción en 2026: son la base técnica sobre la cual descansa la entregabilidad de tus emails. Ya sea que hagas cold email, newsletters, emails transaccionales o simplemente comunicación interna, estos tres protocolos determinan si tus mensajes llegan a la bandeja de entrada o desaparecen en los spams.

La buena noticia: la implementación es una inversión puntual que rinde en el tiempo. Una vez configurados correctamente y pasados a p=reject, proteges tu dominio contra la suplantación, impulsas significativamente tu entregabilidad y ganas la visibilidad que ofrecen los reportes DMARC. Si comienzas hoy una estrategia de prospección email B2B, empieza por aquí antes incluso de pensar en el copywriting o en la secuencia.