SPF frente a DKIM: ¿en qué se diferencian y es necesario tener ambos?

Introducción

Muchos errores de SPF no se deben a un registro mal configurado, sino a que el correo electrónico se ha reenviado.

Un administrador de TI configura correctamente el SPF, comprueba que la verificación se supera y da el trabajo por terminado; luego, un usuario reenvía un mensaje a través de un servidor de retransmisión externo. El servidor receptor detecta una dirección IP que no figura en la lista de direcciones autorizadas, la verificación falla, el administrador revisa el registro y todo parece estar en orden. El problema no es el registro, sino el funcionamiento del SPF.

El SPF por sí solo no es suficiente para la autenticación del correo electrónico, y el SPF y el DKIM no tienen la misma finalidad. Cada protocolo protege una capa diferente del proceso de entrega del correo electrónico. Si se elimina cualquiera de los dos, se dejan brechas que tanto la infraestructura de reenvío como los atacantes pueden aprovechar, de diferentes maneras y por diferentes motivos.

En este blog, descubrirás en qué se diferencian el SPF y el DKIM, por qué el reenvío afecta a uno pero no al otro, y por qué ambos son necesarios para que DMARC funcione.

¿Qué es el SPF y cómo funciona?

El SPF (Sender Policy Framework) es un protocolo de autenticación de correo electrónico que permite al propietario de un dominio especificar qué servidores de correo están autorizados a enviar mensajes en nombre de dicho dominio.

El dominio publica un registro SPF en su DNS como una entrada TXT que enumera las direcciones IP y los servidores autorizados. Cuando un servidor de correo receptor recibe un mensaje, compara el dominio del remitente con este registro publicado para confirmar que el servidor de envío está autorizado. 

En función del resultado, el destinatario decide si acepta, marca o rechaza el mensaje. El SPF existe para evitar que los spammers y los atacantes falsifiquen la dirección del remitente, lo que reduce el suplantación de identidad y el phishing. Funciona junto con DKIM y DMARC para verificar la legitimidad de los mensajes. 

Qué comprueba el SPF

El SPF comprueba si el servidor que envía un mensaje está autorizado a enviar correo en nombre del dominio del que dice proceder. Esto ocurre en el momento en que el servidor receptor acepta la conexión entrante, incluso antes de procesar el cuerpo del mensaje.

Sin embargo, el SPF no comprueba la dirección del remitente que ven realmente tus destinatarios. Solo comprueba el remitente del sobre, también denominado «Return-Path» o «MAIL FROM», que es la dirección que se utiliza en segundo plano durante la transacción SMTP. 

Así, un atacante puede superar la verificación SPF del dominio de la envoltura y, aun así, mostrar una dirección «De» falsificada en la bandeja de entrada. DMARC ayuda a subsanar esta deficiencia vinculando el resultado de la verificación SPF al dominio «De» visible.

El servidor receptor admite dos entradas: 

1. La dirección IP de origen
2. El dominio del remitente del sobre

A continuación, consulta el registro SPF de ese dominio en el DNS. Sigue el orden de los mecanismos del registro, como ip4, ip6, a, mx, y include. Si la IP remitente coincide con una fuente autorizada, el SPF pasa la prueba. Si llega hasta el cierre todos sin encontrar ninguna coincidencia, el resultado dependerá de cómo hayas configurado dicho mecanismo.

SPF no devuelve un simple «sí» o «no». Devuelve uno de los siguientes resultados:

• Aceptar: El servidor está autorizado.
• Fallo (-all): No autorizado. Desea que este correo sea rechazado.
• SoftFail (~todos): Probablemente no esté autorizado. Acéptalo, pero márcalo como sospechoso.
• Neutro (?todos): No estás afirmando nada en ningún sentido.
• Ninguno: No existe ningún registro SPF para el dominio.
• PermError / TempError: El registro está dañado o un problema de DNS ha bloqueado la búsqueda.

El servidor receptor considera este resultado como una señal más, junto con DKIM y DMARC, para determinar la legitimidad del correo electrónico antes de que tu mensaje se entregue, se marque o se rechace. 

¿Qué es DKIM y cómo funciona?

DKIM (DomainKeys Identified Mail) es un protocolo de autenticación de correo electrónico que adjunta una firma criptográfica a cada mensaje que envía un dominio. El servidor remitente firma el mensaje con una clave privada y añade la firma al encabezado del correo electrónico. El dominio publica la clave pública correspondiente en su DNS como un registro TXT. 

Cuando un servidor receptor recibe el mensaje, recupera esa clave pública y verifica la firma. Una firma válida confirma dos cosas: 

1. El mensaje procede realmente del dominio indicado
2. Su contenido no se modificó durante el transporte. 

El DKIM tiene como objetivo evitar la manipulación y la suplantación de remitentes, y funciona junto con el SPF y el DMARC para verificar la autenticidad de los mensajes. 

Qué firma DKIM

DKIM firma dos partes de cada mensaje: un conjunto seleccionado de campos de encabezado y el cuerpo del mensaje. No firma el sobre, la IP de conexión ni nada que se encuentre fuera de esas dos áreas. Esa es la diferencia fundamental entre ambos protocolos: SPF comprueba el sobre y el servidor de envío, mientras que DKIM firma el propio mensaje.

La firma no se aplica al texto sin formato. El servidor emisor calcula el hash del cuerpo del mensaje y de los encabezados seleccionados, y luego cifra ese hash con su clave privada. El resultado se incluye en el encabezado «DKIM-Signature», que el servidor añade al mensaje. Dentro de ese encabezado, varias etiquetas indican al destinatario exactamente qué se ha firmado:

• h= enumera los campos de encabezado incluidos en la firma, como De, Para, Asunto y Fecha.
• bh= contiene el hash del cuerpo del mensaje.
• b= contiene la firma propiamente dicha, el hash cifrado de los encabezados firmados.
• c= establece la canonicalización, que determina el grado de coincidencia que deben tener los espacios en blanco y el formato.

El encabezado «From» siempre está firmado. DKIM lo exige, ya que el objetivo es vincular la firma al dominio que el destinatario ve realmente.

Todo lo que no figure en h= no está protegido. Si un encabezado no aparece en esa lista, puede modificarse durante la transmisión sin que se rompa la firma. El cuerpo queda protegido en su totalidad, a menos que la etiqueta opcional l= limite la firma a la primera parte del mismo, razón por la cual, por lo general, se desaconseja el uso de l=. Cualquier contenido añadido después de la longitud firmada pasaría sin firmar.

Cuando un servidor receptor comprueba el DKIM, vuelve a calcular el hash del cuerpo y el hash del encabezado, descifra b= con tu clave pública publicada y compara ambos. Si coinciden, la firma es válida y las partes firmadas del mensaje han llegado sin alteraciones.

SPF frente a DKIM

SPF y DKIM resuelven dos problemas distintos. SPF autoriza qué servidores pueden enviar correo en nombre de tu dominio, mientras que DKIM demuestra, mediante una firma criptográfica, que un mensaje no ha sido alterado y que procede realmente de tu dominio. A continuación te ofrecemos una breve descripción de las diferencias entre SPF y DKIM.

Ninguno de los dos protocolos sabe lo que sabe el otro.

El SPF puede confirmar que un mensaje procede de un servidor autorizado, pero una vez que ese mensaje sale del servidor, el SPF no tiene forma de saber qué ha ocurrido con él. 

Del mismo modo, DKIM puede confirmar que el contenido ha llegado intacto y que el dominio firmante controlaba la clave privada, pero no dice nada sobre si ese servidor tenía permiso para enviar el mensaje en primer lugar.

Esto es lo que significa cuando un servidor receptor evalúa ambos resultados:

DMARC analiza ambos resultados y aplica la política publicada en función de la coincidencia con el dominio . Por eso, los dos protocolos están diseñados para complementarse entre sí, no para competir.

¿Por qué falla el SPF en el reenvío, pero no el DKIM?

El problema del reenvío del SPF

SPF falla cuando se se reenvía un correo electrónico. Es una de las razones más comunes por las que un mensaje legítimo no supera la verificación SPF, y se debe directamente al funcionamiento del protocolo.

El SPF compara la dirección IP del servidor que se conecta con el registro SPF del dominio del remitente del sobre. Los reenvíos rompen esa coincidencia. Cuando un servidor reenvía un mensaje, ocurren tres cosas:

1. El servidor de reenvío se convierte en la nueva dirección IP de conexión.
2. El remitente del sobre sigue apuntando al dominio del remitente original.
3. El registro SPF del dominio original no incluye el servidor de reenvío, por lo que la comprobación da como resultado un error.

Por ejemplo, un mensaje procedente de tu dominio supera la verificación SPF en el primer salto. A continuación, el servidor del destinatario lo reenvía a una segunda dirección, como una cuenta de antiguos alumnos o una lista de correo. En ese segundo destino, la IP de conexión es ahora la del servidor de reenvío, pero el campo «Return-Path» sigue mostrando tu dominio. Tu registro SPF nunca autorizó a ese servidor, por lo que la verificación SPF falla aunque el mensaje sea auténtico.

Esto suele darse sobre todo en:

• Listas de correo
• Reglas de reenvío automático a nivel de cuenta en Gmail o Outlook
• Direcciones de reenvío de antiguos alumnos o basadas en funciones
• Filtros antispam y pasarelas que reenvían el correo

Hay dos factores que evitan que el correo reenviado sea rechazado:

1. SRS (Sender Rewriting Scheme): El servidor de reenvío reescribe el campo Return-Path con su propio dominio antes de retransmitir el mensaje. A continuación, el SPF comprueba el dominio del reenviador, que autoriza a ese servidor, por lo que la comprobación se supera. La mayoría de los servicios de reenvío de confianza aplican el SRS automáticamente.
2. DKIM y DMARC: Una firma DKIM se mantiene intacta tras el reenvío siempre que quien reenvía el mensaje no altere el contenido firmado. Por lo tanto, incluso cuando SPF falla en un mensaje reenviado, DKIM puede seguir pasando, y DMARC solo necesita que uno de los dos coincida. Esta es la razón principal por la que no se debe confiar únicamente en SPF.

Por qué DKIM sigue funcionando tras el reenvío

DKIM sigue siendo válido tras el reenvío porque firma el mensaje, no la ruta que este recorre. La firma se encuentra en el encabezado «DKIM-Signature», por lo que se transmite junto con el correo electrónico en cada paso del recorrido. Independientemente del número de servidores que retransmitan el mensaje, la firma sigue estando presente cuando este llega a su destino final.

La verificación tampoco depende del servidor de conexión. El destinatario obtiene la clave pública del dominio firmante a través del DNS de dicho dominio y la utiliza para comprobar la firma. La dirección IP desde la que se envió el mensaje es irrelevante. Esto es lo contrario de lo que ocurre con el SPF, que falla en el reenvío precisamente porque comprueba la dirección IP de conexión, y el reenvío modifica esa dirección IP.

Siempre que el reenviador transmita el mensaje sin modificar el contenido firmado, el hash del cuerpo y el hash del encabezado seguirán coincidiendo, y DKIM se validará.

DKIM resiste el reenvío sin modificaciones, pero no es inmune a todo. La firma se invalida cuando un intermediario modifica el contenido firmado. Los casos más habituales son las listas de correo, que a menudo:

• Añade un pie de página o un enlace para darse de baja al cuerpo del mensaje
• Añade una etiqueta como [nombre-de-la-lista] en el asunto del correo
• Reescribir o insertar los encabezados que se encuentren dentro de la firma

Cualquiera de estos cambios modifica el hash, y la firma deja de ser válida. ARC (Authenticated Received Chain) se creó precisamente para este caso, conservando los resultados de autenticación originales a medida que un mensaje pasa por intermediarios que lo modifican.

Por eso es importante el DKIM para los correos reenviados en el marco de DMARC. DMARC se considera válido cuando SPF o DKIM superan la comprobación y se alinean con el dominio del remitente. En los mensajes reenviados, SPF suele fallar, por lo que es el DKIM el que garantiza la alineación de DMARC . El dominio de firma permanece igual durante el reenvío, por lo que la alineación se mantiene. Si se confía únicamente en SPF y el correo reenviado desde tu dominio puede fallar en DMARC y acabar en la carpeta de spam.

¿Cómo funcionan conjuntamente SPF, DKIM y DMARC?

SPF y DKIM resuelven cada uno un problema diferente, pero ninguno de los dos impone nada por sí solo. DMARC vincula sus resultados a una acción y relaciona ambas comprobaciones con el dominio que ven realmente tus destinatarios.

Esto es lo que ocurre cuando un servidor receptor analiza un mensaje entrante:

1. El SPF se ejecuta primero: El servidor lee el remitente del sobre, el MAIL FROM intercambiada durante la sesión SMTP, no el encabezado «De» que ve el destinatario, y compara la IP de envío con tu registro SPF. Si la IP está autorizada, el SPF pasa la comprobación. Si no, falla.
2. A continuación se ejecuta DKIM: El servidor lee el encabezado DKIM-Signature , busca tu clave pública en el DNS utilizando las etiquetas de selector y dominio, y verifica la firma criptográfica con respecto al contenido del mensaje. Una firma válida confirma que el mensaje procede de un dominio que controla la clave privada y que no ha sido alterado durante el tránsito.
3. DMARC se evalúa en último lugar: Recupera el registro de tu póliza y comprueba que todo esté en orden:
   1. ¿El dominio que ha superado la verificación SPF coincide con tu dominio de remitente? 
   2. ¿El etiqueta d= de la firma DKIM coincide con tu dominio «De»? 

Si alguno de los dos coincide, DMARC se supera. A continuación, la política publicada determina qué ocurre con el mensaje.

Qué significa la alineación en la práctica

SPF puede validar cualquier dominio que figure en el remitente del sobre. DKIM puede validar cualquier dominio que cuente con una clave de firma válida. Ninguna de estas comprobaciones por sí sola confirma el encabezado «From», el campo que muestra [email protected] en la bandeja de entrada del destinatario, sea legítimo. DMARC añade esa verificación comparando el dominio autenticado con el dominio «De».

La alineación funciona en dos modos:

1. En el modo relajado, que es el predeterminado, basta con que coincida el dominio de la organización, donde mail.tuempresa.com se corresponde con tuempresa.com. 
2. En el modo estricto, los dominios deben coincidir exactamente. La mayoría de las organizaciones utilizan una configuración menos estricta, ya que el modo estricto genera problemas de entrega en los subdominios, a menos que cada origen de envío esté configurado con precisión.

Resultados sobre el correo legítimo frente al correo suplantado

En el caso de un mensaje legítimo correctamente configurado:

• La dirección IP del remitente coincide con tu registro SPF → El SPF se supera
• La firma DKIM es válida, d= coincide con tu dominio «De» → DKIM pasa
• Ambos resultados coinciden con tu dominio de origen → DMARC: superado
• Tu p=rechazar → el mensaje se entrega

En el caso de un mensaje falsificado enviado desde un servidor no autorizado y sin una clave de firma válida:

• Dirección IP no autorizada → Fallo de SPF
• Firma no válida → Fallo de DKIM
• Ninguno de los dos resultados coincide con tu dominio de origen → Fallos de DMARC
• Tu p=rechazar → el mensaje es rechazado antes de llegar a cualquier bandeja de entrada

Por eso, SPF y DKIM juntos son más eficaces con DMARC que cada uno por separado. DMARC puede dar el visto bueno en función del resultado de cualquiera de ellos, de modo que, cuando SPF falla en el correo reenviado, la validación de DKIM hace que DMARC siga dando el visto bueno a los mensajes legítimos. Cuando ambos fallan en el correo falsificado, DMARC actúa según tu política.

Una vez que tu dominio llegue a p=cuarentena o p=rechazo con SPF y DKIM aprobados y alineados, también habrás cumplido el requisito previo de aplicación para BIMI, el estándar que muestra el logotipo verificado de tu marca en bandejas de entrada compatibles como Gmail y Apple Mail.

¿Necesitas tanto SPF como DKIM?

Sí, necesitas tanto SPF como DKIM. 

Un dominio que utiliza SPF sin DKIM carece de verificación de la integridad a nivel de mensaje. No hay forma de confirmar que el contenido no haya sido alterado durante el tránsito. Al no haber alineación con DKIM para ofrecer DMARC, esto significa que, si SPF falla (y lo hará, en cualquier correo reenviado), DMARC no tiene ningún plan de contingencia. Basta con una sola regla de reenvío entre la bandeja de entrada del trabajo de un usuario y su cuenta personal para que la autenticación falle en un correo que era totalmente legítimo.

Google y Yahoo las hicieron obligatorias en febrero de 2024.

Google exige un registro SPF, DKIM y DMARC para todos los remitentes masivos que envíen 5.000 mensajes o más al día. Yahoo exige al menos uno de los registros SPF o DKIM, además de DMARC, aunque implementar solo uno de ellos supone incumplir los requisitos de Google al mismo tiempo. Si envías mensajes a destinatarios de ambas plataformas, configurar ambos es la única forma de cumplir todos los requisitos a la vez.

Incluso por debajo del umbral de los 5 000 mensajes, estos requisitos se han convertido, en la práctica, en la norma de entrega para los principales proveedores de correo electrónico. 

Lo que cada uno cubre y el otro no:

El SPF falla en los correos reenviados, tal y como está diseñado, según la RFC 7208. La IP del servidor de reenvío sustituye a la original; esa IP no figura en tu lista de direcciones autorizadas, por lo que la comprobación falla aunque no haya ocurrido ningún error. A DKIM no le afectan los cambios de IP. La firma viaja junto con el mensaje y se valida independientemente de los servidores por los que haya pasado, siempre y cuando el contenido no haya sido modificado.

DKIM confirma que el mensaje está intacto y que el dominio firmante controlaba la clave privada, pero no indica si el servidor que lo envió contaba con autorización a nivel de red para hacerlo. SPF se encarga de esa comprobación.

Ninguno de los dos sabe lo que sabe el otro. Al ejecutar ambos, el servidor receptor que evalúa tu correo dispone de la información completa, la ruta autorizada y el contenido íntegro, en lugar de solo la mitad.

Cómo configurar SPF y DKIM: guía paso a paso

Si aún no tienes configurados los protocolos SPF y DKIM en tu dominio, el proceso de configuración es muy sencillo. Los pasos que se indican a continuación te explican lo que necesitas para configurar y verificar ambos protocolos. 

Paso 1: Crea tu registro SPF

Empieza por hacer una lista de todos los servicios autorizados para enviar correos electrónicos desde tu dominio, como:

1. Tu servidor de correo principal
2. Plataforma de marketing
3. CRM
4. Herramienta de asistencia técnica
5. Proveedor de correo electrónico transaccional y cualquier otro servicio que envíe mensajes en tu nombre.

Cada servicio autorizado recibe un incluye: un mecanismo en tu registro SPF, o un rango de IP directo utilizando ip4: o ip6:. Cierra el registro con -all para indicar a los servidores receptores que cualquier IP que no figure en la lista no está autorizada.

Antes de añadir rangos de IP directamente con ip4: o ip6:, confirma que los rangos pertenecen al servicio de envío correcto. La búsqueda de IP WHOIS de PowerDMARC te permite verificar la titularidad de la IP antes de que se incorpore a tu registro. 

Un registro SPF básico tiene este aspecto:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Presta atención al número de consultas DNS a medida que añades servicios. El RFC 7208 limita la evaluación del SPF a 10 consultas. Cada inclusión: consume al menos una, y las inclusiones anidadas cuentan para el mismo límite. La mayoría de los dominios alcanzan el límite más rápido de lo esperado una vez que ejecutan cuatro o cinco remitentes de terceros simultáneamente.

Utiliza el generador gratuito de generador de SPF para crear tu registro sin tener que escribir la sintaxis manualmente, y PowerSPF para mantenerlo automáticamente por debajo del límite de 10 consultas a medida que cambia tu infraestructura de envío.

Paso 2: Genera y publica tus claves DKIM

Para cada servicio que envíe mensajes en tu nombre, necesitas un par de claves DKIM: 

1. Una clave privada que utiliza el servidor de envío para firmar el correo saliente
2. Una clave pública correspondiente publicada en tu DNS para que los servidores la verifiquen.

Si un servicio como Google Workspace o Microsoft 365 se encarga de la firma DKIM, ellos proporcionan el registro de la clave pública y el nombre del selector. Publica el registro en el DNS en selector._domainkey.sudominio.com y habilita la firma en la consola de administración del servicio.

En entornos en los que generes las claves tú mismo, utiliza RSA de al menos 2048 bits; 1024 bits ya no se considera suficiente. El generador gratuito de PowerDMARC generador DKIM gratuito de PowerDMARC genera un registro DNS listo para publicar sin necesidad de herramientas de línea de comandos.

Si gestionas DKIM en varios servicios de envío, Hosted DKIM se encarga de la generación de claves, la publicación en el DNS y la rotación desde un único lugar, sin necesidad de realizar modificaciones manuales en el DNS cada vez que hay que cambiar una clave.

Paso 3: Añadir un registro DMARC

Una vez que tengas configurados SPF y DKIM, añade un registro DMARC a tu DNS. Empieza por p=none para recopilar datos de informes agregados sin afectar al envío de correo.

Un historial inicial mínimo:

v=DMARC1; p=none; rua=mailto:[email protected];

p=none no bloquea los mensajes falsificados. Pone DMARC en modo de supervisión, por lo que recibirás informes agregados que muestran qué fuentes superan y cuáles no superan la autenticación, pero no se pone en cuarentena ni se rechaza ningún correo. 

Utiliza esos datos para identificar errores de configuración y problemas de alineación, y luego pasa a p=cuarentena y, finalmente, p=rechazar.

Un dominio ubicado en p=none indefinidamente no está protegido contra la suplantación de identidad. La fase de supervisión necesita un punto final definido, no un plazo abierto.

Paso 4: Comprueba tu configuración

Una vez publicados los registros, comprueba que todos se resuelvan correctamente antes de dar por finalizada la configuración.

Aunque es necesario que los registros se resuelvan correctamente, eso por sí solo no es suficiente. Envía una prueba en tiempo real para confirmar que los encabezados de autenticación pasan correctamente de principio a fin. La herramienta de prueba SMTP de PowerDMARC te permite probar la conexión de tu servidor de correo y verificar SPF, DKIM y DMARC se aplican al correo saliente real, no solo en el DNS. 

Errores comunes

Los dos errores más comunes que provocan fallos de autenticación en el entorno de producción son: 

SPF 10: límite de consultas

El SPF permite un máximo de 10 consultas DNS cuando un servidor receptor evalúa tu registro, un límite establecido por el RFC 7208. Mecanismos como «include», «a» y «mx» activan cada uno una consulta, y se anidan. 

La mayoría de los dominios superan el límite de 10 al acumular remitentes de terceros, ya que cada servicio que autorizas mediante una inclusión consume consultas. Una vez superado el límite, SPF devuelve un PermError, y los servidores receptores lo tratan como un registro dañado que ya no autoriza tu correo. 

La optimización lo soluciona sustituyendo tus mecanismos de inclusión por los rangos IPv4 e IPv6 reales a los que se resuelven, reduciendo así tu recuento de búsquedas a cero.

Rotación de claves DKIM

La rotación de claves DKIM consiste en sustituir el par de claves DKIM según un calendario establecido, retirando la antigua clave privada de firma y publicando una nueva clave pública en su lugar. La rotación limita el tiempo durante el que una clave concreta queda expuesta, de modo que, si alguna vez se ve comprometida, el alcance del daño es mínimo. La mayoría de los equipos realizan la rotación cada trimestre o dos veces al año, y algunos proveedores rotan sus propias claves de forma automática.

La mayoría de los fallos en la rotación se deben a los pasos relacionados con el intercambio. Esto es lo que los administradores suelen pasar por alto con mayor frecuencia.

Eliminar la clave pública antigua demasiado pronto

Los mensajes que ya están en tránsito se han firmado con la clave antigua, y el destinatario necesita la clave pública correspondiente en el DNS para verificarlos. Elimina el registro antiguo en el momento en que realices el cambio, ya que el correo en tránsito no superará la verificación DKIM. Mantén publicada la clave antigua durante un periodo de transición hasta que se haya completado el procesamiento de todo el correo firmado con ella.

Reutilizar el mismo selector

Rota los selectores, no sobrescribas uno. Publica la nueva clave bajo un nuevo selector, traslada la firma a él y, a continuación, retira el selector antiguo una vez finalizado el periodo de solapamiento. Sobrescribir el registro de un solo selector crea un vacío en el que el correo firmado con la clave antigua ya no se puede validar.

Cambiar antes de que se propague el DNS

Si firmas con la nueva clave antes de que se haya propagado la nueva clave pública, los destinatarios no podrán encontrarla y DKIM fallará. Publica primero el nuevo registro, espera a que expire el TTL del registro y, a continuación, cambia la firma.

Olvidarse de los remitentes externos

Cada servicio de envío, como tu ESP o CRM, gestiona sus propias claves y selectores DKIM. La rotación de la clave de tu dominio principal no afecta a esos elementos. Rota la clave de cada servicio por separado o comprueba que el proveedor se encarga de ello por ti.

División incorrecta de un registro de 2048 bits

Una clave pública de 2048 bits —el estándar actual, al que conviene actualizarse si aún se utiliza una de 1024— suele superar el límite de 255 caracteres de una sola cadena TXT de DNS, por lo que debe dividirse en varias cadenas entre comillas. Una división incorrecta invalida el registro, y la clave no se validará aunque parezca estar presente.

Girar sin supervisión

Los informes agregados de DMARC te permiten comprobar si la nueva clave se está validando correctamente. Sin ellos, una rotación fallida se traduce en una disminución de la capacidad de entrega, en lugar de generar una alerta. Revisa tus informes después de cada rotación.

Ambos errores se deben a registros que cambian más rápido de lo que se puede actualizar manualmente. PowerDMARC mantiene tu SPF simplificado por debajo del límite de 10 consultas y tus claves DKIM rotando correctamente, y te avisa en el momento en que algo falla, antes de que te cueste la capacidad de entrega.

Empieza tu prueba gratuita para ver cuál es la situación actual de tu dominio.

Preguntas frecuentes

¿DKIM sustituye a SPF?

No. DKIM verifica la integridad del mensaje mediante una firma criptográfica, pero no confirma que el servidor remitente estuviera autorizado. SPF se encarga de esa comprobación, por lo que ambos son necesarios para garantizar una protección completa. 

¿Por qué mi correo electrónico no supera la verificación SPF después de reenviarlo?

El SPF comprueba la dirección IP del servidor remitente con tu lista de direcciones autorizadas, mientras que el reenvío sustituye la dirección IP original por la del servidor de reenvío, que no figura en tu registro. Este es el comportamiento previsto según el RFC 7208, y el DKIM está diseñado para funcionar correctamente en este caso, ya que valida el contenido, no la ruta. 

¿Qué es más importante: SPF o DKIM?

Ninguna de las dos cosas. SPF realiza la autenticación a nivel de servidor, DKIM la verificación a nivel de mensaje, y ambas son necesarias para una alineación DMARC fiable. Contar con ambas garantiza que tu correo siga pasando aunque una de ellas falle durante el reenvío. 

¿Cuántos selectores DKIM puedo tener?

No hay ningún límite. Publica tantos como necesites; por lo general, uno por servicio de envío o ciclo de rotación de claves. Cada uno se almacena como un registro TXT de DNS independiente en selector._domainkey.tudominio.com. 

¿Qué pasa si solo tengo SPF pero no DKIM?

Se pierde la integridad a nivel de mensaje y no se dispone de una solución alternativa para la alineación DKIM, por lo que DMARC puede dar error en correos reenviados legítimos cuando falla SPF. Las normas de Google para remitentes masivos también exigen el uso de DKIM, lo que hace que los remitentes de gran volumen incumplan la normativa.