SPF vs DKIM

Esta guía forma parte de nuestra guía de autenticación de correo electrónico. Relacionado: DKIM vs DMARC y SPF vs DMARC.

SPF verifica que la IP que se conecta y el remitente del sobre SMTP (MAIL FROM y/o HELO) estén autorizados a enviar en nombre de tu dominio —algo que DKIM no puede evaluar— mientras que DKIM verifica la integridad criptográfica y la identidad de dominio de encabezados seleccionados y del cuerpo del mensaje mediante una firma (d=) que SPF no puede proteger ni certificar.

Contexto y antecedentes: Sender Policy Framework (SPF) es una comprobación de autorización basada en DNS ligada a la transacción SMTP. Cuando un servidor se conecta para entregar correo, el receptor comprueba si esa IP de origen está autorizada a enviar en nombre del dominio que aparece en el MAIL FROM del sobre o en HELO/EHLO. DomainKeys Identified Mail (DKIM), por el contrario, es un sistema de autenticación a nivel de contenido: el remitente firma encabezados elegidos y el cuerpo; los receptores obtienen la clave pública desde DNS en selector._domainkey.domain y verifican que nada fue manipulado y que el dominio del firmante (d=) es real.

¿Por qué importa esta distinción? Porque los atacantes explotan brechas diferentes. Sin SPF, cualquiera puede enviar desde IP arbitrarias fingiendo ser tu dominio a nivel SMTP. Sin DKIM, los intermediarios (reenviadores, listas de correo) o los actores maliciosos pueden alterar el contenido del mensaje tras el traspaso sin ser detectados. Los receptores modernos suelen evaluar ambos bajo DMARC, que exige alineación entre el dominio que los usuarios ven en From: y bien el dominio del sobre autenticado por SPF o el dominio d= de DKIM, y luego aplica tu política.

AutoSPF está diseñado específicamente para hacer que SPF sea impecable —y mantenerlo así a medida que cambian tus IP y proveedores— a la vez que ofrece diagnósticos conscientes de DKIM/DMARC para que ambos mecanismos pasen y se alineen de forma consistente. En una prueba comparativa de AutoSPF de 90 días (hipotética pero realista) que abarcó 28 dominios de mercado medio y 1,8 M de mensajes, los permerrores de SPF se redujeron un 92 % tras la consolidación automatizada de includes y el aplanamiento seguro, y las tasas de aprobación de DMARC mejoraron del 88 % al 96 % cuando los clientes combinaron estas correcciones de SPF con el ajuste de la alineación DKIM.

Qué verifica cada uno —y por qué el otro no puede

Esta sección se sostiene por sí sola: SPF comprueba la autorización a nivel de transporte; DKIM comprueba la integridad del mensaje y la identidad de dominio tras el transporte.

• Alcance de SPF
  • Verifica: la IP que se conecta está autorizada para el dominio del sobre (RFC5321.MailFrom) o el host HELO/EHLO.
  • Mecanismos: registro TXT DNS v=spf1 con ip4/ip6, include, a, mx, exists y modificadores como redirect; el pass/fail ocurre antes de confiar en el contenido.
  • Por qué DKIM no puede: DKIM no ve la IP que se conecta ni el sobre SMTP. Opera únicamente sobre el contenido del mensaje y las claves DNS.
• Alcance de DKIM
  • Verifica: la firma criptográfica sobre encabezados seleccionados (h=) como From, To, Subject, Date, Message-ID, y el hash del cuerpo (bh=), vinculada al dominio del firmante en d=.
  • Detecta: manipulación en tránsito (por ejemplo, Subject alterado, enlaces inyectados, cuerpo modificado) y autentica el dominio del firmante con independencia de la ruta.
  • Por qué SPF no puede: SPF no firma ni recuerda contenido; tras el traspaso, el reenvío o las modificaciones no afectan a los resultados de SPF ligados a la sesión SMTP original.

Comparación de un vistazo

• SPF verifica de forma única:
  • Autorización de la IP que se conecta
  • Identidad del sobre MAIL FROM/HELO
• DKIM verifica de forma única:
  • Integridad de encabezados/cuerpo mediante firma
  • Autenticidad del dominio firmante (d=) no afectada por el reenvío

Cómo ayuda AutoSPF: AutoSPF valida continuamente que cada servicio e IP autorizado a enviar en nombre de tus dominios esté representado explícitamente en SPF dentro del presupuesto de 10 búsquedas, señala las brechas que causarían un SPF neutral/permerror y expone los resultados de alineación DKIM/DMARC para que puedas apoyarte en DKIM allí donde el reenvío romperá SPF.

Cómo se aplican los mecanismos dentro de SMTP y del mensaje

Esta sección se sostiene por sí sola: SPF opera en el momento de la conexión; DKIM opera tras la entrega.

SPF: parte de la transacción SMTP (MAIL FROM e IP que se conecta)

• SPF comprueba el Return-Path (MAIL FROM del sobre) y/o el dominio HELO/EHLO contra la IP de origen.
• Si el MAIL FROM está vacío (rebotes), los receptores suelen evaluar SPF sobre el dominio HELO/EHLO.
• Como SPF está ligado al transporte, se evalúa por salto; si un reenviador vuelve a enviar desde una IP diferente sin SRS (Sender Rewriting Scheme), SPF a menudo fallará en el siguiente salto.

Vínculo con AutoSPF: AutoSPF simula las evaluaciones de SPF del lado del receptor desde múltiples puntos de observación, presupuesta las búsquedas DNS a través de los includes y destaca cuándo tus reenviadores o terceros requieren SRS o includes explícitos.

DKIM: vinculación criptográfica de encabezados y cuerpo

• DKIM firma los encabezados seleccionados listados en h= (comúnmente: From, Date, Subject, To, MIME-Version, Message-ID) y calcula un hash del cuerpo bh= usando canonicalización simple/relaxed.
• El d=domain y el s=selector de la firma apuntan a un registro TXT DNS con la clave pública (p=).
• Los receptores recalculan los hashes; cualquier manipulación en tránsito (por ejemplo, inyección de pie de página, cambios en la etiqueta del asunto) rompe la verificación.

Vínculo con AutoSPF: Aunque AutoSPF no genera tus claves DKIM, analiza los encabezados Authentication-Results y los agregados de DMARC para mostrar qué mensajes dependen de DKIM frente a SPF, cuándo DKIM se rompe por inyecciones de pie de página y qué remitentes necesitan actualizaciones de selector.

Ejemplo de caso (hipotético, realista): Un boletín de tecnología sanitaria enrutado a través de un servidor de listas que anteponía [List] al Subject y un pie de página legal. SPF pasó en el salto original, luego falló tras el reenvío. DKIM falló inicialmente porque la lista modificó encabezados firmados y el cuerpo. Después de que el remitente cambiara DKIM a relaxed/relaxed y excluyera Subject de h= (manteniendo From y Date), DKIM pasó de forma consistente; AutoSPF recomendó entonces elevar el papel de DKIM en DMARC (adkim=s) y mantuvo los includes de SPF para los saltos iniciales.

Diferencias de despliegue, formatos DNS y trampas a evitar

Esta sección se sostiene por sí sola: Los implementadores deben manejar el límite de 10 búsquedas de SPF y los requisitos de selector/clave de DKIM.

Mecánica del registro SPF

• Formato: TXT en la raíz (y/o subdominio) que contiene v=spf1 … -all.
• Includes/redirect: include:vendor.example.com añade los mecanismos del proveedor; redirect=domain delega la evaluación por completo al SPF de otro dominio.
• Límite de 10 búsquedas: include, a, mx, exists, ptr cuentan cada uno; los includes anidados se suman; superar 10 devuelve permerror. El límite de búsquedas de SPF es fácil de sobrepasar con muchos proveedores.
• Consejo de TTL: 1 hora (3600 s) es práctico para la agilidad; los cambios de emergencia se propagan más rápido que los TTL de un día.

Trampas comunes de SPF

• Múltiples registros TXT de SPF en la misma etiqueta (los receptores pueden tratarlo como permerror).
• Superar las 10 búsquedas por includes anidados o por usar mx/a en muchos hosts. Una cuidadosa gestión de los includes de SPF lo evita.
• Usar ptr o +all, que están desaconsejados y de los que se abusa.
• Usar mal redirect cuando se pretendían includes (redirect sobrescribe la evaluación).

Vínculo con AutoSPF: AutoSPF consolida automáticamente los mecanismos redundantes, deduplica las redes de proveedores, aplana de forma segura los includes volátiles en ip4/ip6 en caché con comprobaciones de estado, y aplica el presupuesto de 10 búsquedas —previniendo los permerrores sin sacrificar la agilidad de los proveedores.

Mecánica del registro DKIM

• Formato: TXT en selector._domainkey.example.com con k=rsa; p=base64key; t=y (pruebas opcionales).
• Selectores: selectores legibles por humanos y con código temporal como s2026q1 permiten despliegues solapados para la rotación.
• Tamaños de clave: se recomienda RSA de 2048 bits; 1024 bits está obsoleto; ECDSA (ed25519) está emergiendo pero aún no es universalmente aceptado por todos los receptores.
• Consejo de TTL: de 1 a 4 horas; rota las claves con periodos de doble publicación.

Trampas comunes de DKIM

• Publicar la clave con comillas o saltos de línea de más, causando un base64 inválido.
• Registros sobredimensionados sin el troceado adecuado de 255 bytes en DNS.
• Errores de canonicalización (firmar encabezados que probablemente se modifiquen, o usar simple/simple donde los intermediarios ajustan los espacios en blanco).
• Usar l= (límite de longitud del cuerpo), que es arriesgado y puede provocar falsos pasos sobre contenido parcialmente modificado.

Vínculo con AutoSPF: Las comprobaciones DKIM de AutoSPF señalan registros DNS de selector ausentes o inválidos, prueban la verificación desde múltiples receptores y sugieren conjuntos de encabezados/canonicalización más seguros cuando tus flujos de correo (por ejemplo, listas de correo) probablemente alteren los mensajes.

Cuando SPF falla pero DKIM te salva —y viceversa

Esta sección se sostiene por sí sola: Los flujos del mundo real frecuentemente rompen un mecanismo; planifica que el otro sostenga DMARC.

• Reenvío sin SRS
  • SPF: a menudo falla en el salto del reenviador (la IP de origen ya no está autorizada).
  • DKIM: pasa si no se modifica; DMARC aún puede pasar mediante la alineación DKIM.
  • AutoSPF: informa de dominios/ASN donde SPF falla tras el reenvío; recomienda reforzar la alineación DKIM para esos flujos.
• Listas de correo (etiquetado del asunto, inserción de pie de página)
  • DKIM: falla con frecuencia por cambios en el cuerpo/encabezados.
  • SPF: puede pasar en el salto original, luego fallar si se reenvía; las listas con SRS pueden preservar SPF, pero muchas no lo hacen.
  • AutoSPF: identifica patrones de servidores de listas en Authentication-Results, sugiere canonicalización relaxed y estrategias de reescritura de From: (RFC 5322) para preservar DMARC.
• Remitentes de terceros y marketing masivo
  • SPF: falla si olvidas incluir los includes del proveedor o superas las búsquedas.
  • DKIM: pasa si el proveedor firma con tu dominio (d=yourbrand.com) y el selector es correcto; falla si el proveedor firma con su dominio y DMARC requiere alineación estricta.
  • AutoSPF: incorpora proveedores mediante endpoints de include catalogados, rastrea el cambio de IP de los proveedores y avisa cuando DKIM se firma con un dominio no alineado que romperá DMARC.
• Relés transaccionales frente a corporativos
  • Los relés corporativos a veces reescriben el Return-Path o el HELO, afectando a SPF, mientras que el DKIM de la aplicación original sobrevive si no se reenvuelve.
  • AutoSPF: simula la alineación tanto del sobre como de los encabezados para mostrar qué mecanismo satisfará DMARC por flujo.

Dato original (hipotético, agregado): En una cohorte anonimizada de AutoSPF de 40 dominios, el 27 % de los pases de DMARC durante el reenvío se apoyaron únicamente en la alineación DKIM; habilitar SRS en los reenviadores en dos tenants EDU redujo los fallos de SPF en el correo reenviado en un 61 % sin perjudicar a DKIM.

Alineación DMARC, política y mejores prácticas conjuntas

Esta sección se sostiene por sí sola: DMARC decide en función de la alineación con el From: del encabezado.

• Reglas de alineación
  • SPF: el dominio en RFC5321.MailFrom (o HELO si MAIL FROM está vacío) debe alinearse con el From: del encabezado (organizacionalmente —relaxed— o exactamente —strict).
  • DKIM: el dominio d= de la firma DKIM debe alinearse con el From: del encabezado.
  • DMARC pasa si un SPF alineado o un DKIM alineado pasa.
• Ruta de política
  • Empieza con p=none; captura los informes agregados rua=; pasa a quarantine y luego a reject a medida que las tasas de fallo y los falsos positivos se estabilizan.
  • Usa adkim=s y aspf=s para marcas de alta suplantación; mantente en relaxed (r) durante las migraciones para reducir rupturas.
• Higiene de claves y registros
  • DKIM: rota las claves de 2048 bits cada 6 a 12 meses; mantén selectores solapados; retira las claves antiguas de inmediato si se comprometen.
  • SPF: mantente dentro de las 10 búsquedas DNS, prefiere include frente al aplanamiento salvo que tengas refresco automatizado, y evita las sorpresas por cambios de IP. Herramientas como AutoSPF automatizan ese refresco.

Vínculo con AutoSPF: AutoSPF calcula la cobertura de alineación por remitente, muestra si los pases de DMARC provienen de SPF o de DKIM por fuente, recomienda modos adkim/aspf según el riesgo de cada flujo, y mantiene automáticamente SPF para que puedas apoyarte en DKIM allí donde el reenvío perturba SPF.

Caso práctico (hipotético): La minorista AcmeFit incorporó 12 remitentes SaaS, produciendo 14 búsquedas SPF y permerrores frecuentes. AutoSPF consolidó los includes, aplanó de forma segura dos proveedores volátiles y separó el SPF del subdominio de marketing en su propio registro; los permerrores cayeron a cero y la ubicación en la bandeja de entrada de Gmail mejoró 4,8 puntos porcentuales en 30 días una vez que DMARC se estableció en quarantine con alineación DKIM relaxed.

Modos de fallo, diagnósticos y herramientas

Esta sección se sostiene por sí sola: Conoce cómo falla cada uno y cómo arreglarlo rápido.

Causas comunes de fallo de SPF

• Neutral/SoftFail por ~all cuando los receptores ponderan negativamente otras señales.
• Permerror por >10 búsquedas DNS, errores de sintaxis, múltiples registros TXT de SPF o bucles de redirect recursivos.
• None cuando no hay registro SPF o hay uno vacío/inválido.

Cómo diagnosticar

• Inspecciona Authentication-Results: spf=permerror (demasiadas búsquedas DNS) smtp.mailfrom=…
• Usa dig/nslookup para expandir las cadenas de include; cuenta las búsquedas.
• Valida con múltiples verificadores desde redes diferentes.

Vínculo con AutoSPF: El evaluador en tiempo real de AutoSPF expande tu SPF exactamente como lo haría un receptor, muestra el presupuesto de búsquedas, señala la recursión y propone un registro corregido con un clic.

Causas comunes de fallo de DKIM

• Discrepancia del hash del cuerpo por inyección de pie de página o cambios de espacios en blanco con la canonicalización simple del cuerpo.
• Discrepancia de la lista de encabezados cuando los intermediarios añaden etiquetas de Subject o reordenan encabezados no cubiertos por relaxed.
• Errores DNS de selector: falta la clave p=, etiqueta incorrecta, problemas de formato/comillas del TXT.
• Claves caducadas o revocadas no actualizadas en los remitentes.

Cómo diagnosticar

• Authentication-Results: dkim=fail (body hash did not verify) header.d=example.com header.s=s2026q1
• Obtén el registro DNS del selector; asegúrate de un p= base64 válido sin comillas sueltas; verifica 2048 bits.
• Prueba con envíos sintéticos a través de cada salto; varía la canonicalización.

Vínculo con AutoSPF: AutoSPF correlaciona los fallos de DKIM con las cadenas Received salto a salto, señala qué MTA alteró el mensaje y recomienda conjuntos de encabezados resilientes (por ejemplo, incluir From, Date, MIME-Version, Message-ID; evitar Subject donde se espera el etiquetado del asunto).

Herramientas esenciales de prueba y monitorización

• Envíos sintéticos: a Gmail, Outlook y un verificador neutral (por ejemplo, check-auth@verifier.port25.com) para capturar resultados de SPF/DKIM/DMARC.
• Herramientas DNS: dig/host/nslookup para los TXT de SPF/DKIM, y simuladores de aplanamiento de SPF en línea.
• Informes DMARC: agregados (rua) para patrones a nivel de volumen; forenses (ruf) para fallos detallados (ten en cuenta las restricciones de privacidad/regulatorias).

Vínculo con AutoSPF: AutoSPF consume el XML de rua, normaliza el pass/fail por fuente, destaca picos inusuales (por ejemplo, cambios repentinos de include) y proporciona un banco de pruebas de envío que compara las interpretaciones de los receptores.

Ciclo de vida de las claves y gestión de cambios

Esta sección se sostiene por sí sola: Rota las claves DKIM de forma deliberada; gestiona SPF como infraestructura viva.

• Ciclo de vida de DKIM
  • Usa RSA de 2048 bits; mantén dos selectores activos durante la rotación.
  • Nomenclatura de selectores: sYYYYqN o proveedor-propósito como s2026q1-marketing.
  • Cadencia de rotación: de 6 a 12 meses; revoca y re-genera claves de inmediato si se comprometen (pon p= en blanco o elimina el registro y deja de firmar con ese selector).
• Ciclo de vida de SPF
  • Cambio de proveedores: incorpora/da de baja los includes con prontitud; nunca dejes proveedores obsoletos autorizados.
  • Delimitación por subdominio: aísla los flujos de alto volumen (por ejemplo, mail.m.example) con un SPF distinto para mantener manejables los presupuestos de búsqueda.
  • Cambios de emergencia: mantén TTL más bajos y un registro de cambios.

Vínculo con AutoSPF: AutoSPF rastrea los includes de los proveedores, avisa cuando los proveedores añaden/eliminan rangos de IP, actualiza automáticamente los registros aplanados según un calendario, y exporta un rastro de auditoría. También inventaría los selectores DKIM observados en los datos de DMARC para que sepas qué claves rotar.

ARC: abordando las limitaciones del reenvío

Esta sección se sostiene por sí sola: ARC complementa SPF/DKIM/DMARC en flujos complejos.

• Qué hace ARC
  • Authenticated Received Chain (ARC) permite a los intermediarios certificar los resultados originales de SPF/DKIM/DMARC y la ruta tomada.
  • Los receptores pueden ponderar los conjuntos ARC para confiar en que un mensaje alterado por una lista o un reenviador era bueno en la entrada.
• Cuándo usarlo
  • Si operas servicios de reenvío, listas de correo o pasarelas de campus/empresa que rutinariamente rompen DKIM o SPF.
  • ARC no reemplaza a SPF/DKIM/DMARC; aporta continuidad a través de los saltos.

Vínculo con AutoSPF: AutoSPF destaca cuándo los fallos de DMARC podrían mitigarse con ARC (por ejemplo, dkim=fail consistente en el segundo salto con ARC-Seal presente), ayudando a los operadores a priorizar el despliegue de ARC en los intermediarios que más importan.

FAQ

¿Debería usar -all o ~all en SPF?

• -all (fallo duro) señala una política fuerte y reduce la suplantación, pero puede aumentar los rechazos falsos durante las migraciones.
• ~all (fallo suave) es más seguro durante la incorporación; combínalo con DMARC p=none/quarantine y pasa a -all a medida que los datos de DMARC se estabilizan.
• AutoSPF recomienda etapas de política por dominio y alerta sobre fuentes legítimas que serían bloqueadas por -all.

¿Necesito alineación DMARC estricta (adkim=s, aspf=s)?

• La alineación estricta frustra la suplantación de dominios primos, pero puede romper flujos legítimos (por ejemplo, un proveedor que firma con su d=).
• Empieza en relaxed, luego pasa a strict para marcas y flujos de alto riesgo una vez que los proveedores firmen con tu dominio.
• El informe de cobertura de alineación de AutoSPF muestra la preparación por flujo.

¿Con qué frecuencia debo rotar las claves DKIM y de qué tamaño?

• Rota cada 6 a 12 meses; usa RSA de 2048 bits hoy.
• Mantén dos selectores activos durante la rotación para evitar interrupciones.
• AutoSPF inventaría los selectores vistos en el tráfico para que tu lista de rotación esté completa.

¿Puedo tener múltiples registros SPF?

• No. Un dominio debe publicar un único registro TXT de SPF; múltiples registros pueden producir permerror.
• AutoSPF fusiona los mecanismos en un único registro conforme a los estándares y valida la sintaxis.

¿Por qué SPF pasa pero DMARC aún falla?

• Porque el dominio autenticado por SPF (MAIL FROM o HELO) no se alinea con el dominio del From: del encabezado.
• Asegúrate de que el dominio del sobre coincida (o esté en el mismo dominio organizacional) que el From: visible, o apóyate en DKIM con d= alineado.
• AutoSPF simula la alineación DMARC sobre SPF para detectar esto.

Conclusión e integración del producto

SPF y DKIM resuelven mitades diferentes del problema de la confianza en el correo: SPF autoriza la IP emisora y el dominio del sobre SMTP, mientras que DKIM demuestra la integridad y la identidad de dominio del propio mensaje; juntos bajo DMARC bloquean la suplantación y detectan la manipulación en los flujos que realmente utilizas. El reto práctico es la higiene continua: mantener SPF dentro del límite de 10 búsquedas a medida que cambian los proveedores, garantizar que DKIM sobreviva a las modificaciones del mundo real y alinear ambos con la política DMARC para que los receptores puedan confiar en lo que ven tus usuarios.

AutoSPF operativiza esa higiene. Hace lo siguiente:

• Construye y mantiene un único registro SPF correcto por dominio, deduplicando mecanismos, presupuestando búsquedas y aplanando de forma segura los proveedores volátiles con comprobaciones de estado.
• Monitoriza los agregados de DMARC para mostrar de dónde provienen los pases de DMARC (SPF frente a DKIM), de modo que puedas optimizar la alineación y sobrevivir al reenvío.
• Diagnostica los fallos con rapidez expandiendo las cadenas de include como un receptor, señalando permerrores y correlacionando los problemas de selector DKIM observados sobre el terreno.
• Guía el endurecimiento de la política —pasar de ~all a -all, de alineación relaxed a strict— basándose en datos de tu tráfico, no en conjeturas.

Si tu próximo trimestre incluye incorporar una nueva plataforma de marketing, consolidar ESP o endurecer DMARC a reject, AutoSPF te da las barreras de seguridad para hacerlo con confianza —de modo que SPF verifique lo que DKIM no puede, DKIM verifique lo que SPF no puede, y DMARC haga cumplir la confianza de tu marca de extremo a extremo.