Puntos clave
- A selector DKIM es el valor s= en el encabezado DKIM-Signature que indica a los servidores de correo receptores dónde encontrar la clave pública correspondiente en el DNS.
- Los selectores DKIM permiten utilizar varias claves de firma al mismo tiempo en diferentes proveedores de servicios de correo electrónico (ESP), como Microsoft 365, Google Workspace, HubSpot y SendGrid.
- Una gestión adecuada de los selectores es fundamental para la verificación DKIM, la alineación con DMARC, la rotación de claves y el mantenimiento de la capacidad de entrega del correo electrónico a gran escala.
- Comunes fallos de DKIM suelen deberse a selectores que faltan, registros DNS mal formados, claves de 2048 bits truncadas o discrepancias en la alineación de DMARC.
- Las organizaciones que utilicen varios proveedores de servicios de correo electrónico (ESP) deben mantener un inventario centralizado de los selectores activos, los calendarios de rotación y los dominios de firma para evitar problemas de entrega y de cumplimiento normativo.
¿Qué es un selector DKIM?
Un selector DKIM es una pequeña cadena de texto incluida en el encabezado de un correo electrónico firmado con DKIM que indica al servidor de correo receptor dónde encontrar la clave pública correspondiente en el DNS. Se define en la etiqueta `s=` del encabezado DKIM-Signature.
Cada firma DKIM incluye un valor de selector. El selector, junto con el dominio de firma de la etiqueta `d=`, forma una ruta de consulta DNS que apunta a un registro TXT específico que contiene la clave pública utilizada para verificar la firma.
Así es como se ve el selector dentro del encabezado de un correo electrónico:
Firma DKIM: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123…=; b=xyz789…=
En este ejemplo, `selector1` es el selector DKIM. El servidor receptor consultará `selector1._domainkey.example.com` para recuperar la clave pública.
Las organizaciones suelen utilizar varias claves de firma al mismo tiempo, en función de sus necesidades de correo electrónico. Cada clave tiene su propio selector, por lo que ambas pueden coexistir en el mismo dominio sin que se produzcan conflictos.
Los selectores también permiten la rotación de claves sin tiempo de inactividad. Se puede publicar una nueva clave bajo un nuevo selector mientras el antiguo permanece activo, y luego realizar la conmutación una vez que se haya completado la propagación.
¿Cómo funcionan los selectores DKIM?
Cuando un servidor de correo receptor recibe un correo electrónico firmado con DKIM, lee el selector (`s=`) y el dominio (`d=`) del encabezado del correo, consulta el DNS en `{selector}._domainkey.{domain}`, recupera la clave pública del registro TXT resultante y utiliza esa clave para verificar la firma criptográfica del mensaje.
Aquí tienes los pasos a seguir:
Paso 1: El servidor de envío firma el correo electrónico
Antes de que el correo electrónico salga del servidor de correo emisor (o ESP), el servidor utiliza su clave privada para generar una firma criptográfica sobre determinados campos del encabezado y el cuerpo del mensaje. Esta firma, junto con el valor del selector y el dominio de firma, se añade al correo electrónico como el encabezado `DKIM-Signature`.
Paso 2: El servidor receptor extrae el selector y el dominio
Cuando el correo electrónico llega a la bandeja de entrada, el servidor receptor analiza el encabezado `DKIM-Signature` y extrae dos valores:
- El selector de `s=`
- El dominio a partir de «d=».
Paso 3: El servidor receptor consulta el DNS
The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record
Por ejemplo, si `s=google` y `d=example.com`, la consulta DNS es: google._domainkey.example.com
Paso 4: El DNS devuelve la clave pública
El registro TXT en esa ruta DNS contiene la clave pública y los parámetros asociados:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…
Paso 5: El servidor receptor verifica la firma
El servidor utiliza la clave pública para verificar la firma criptográfica que figura en el encabezado del correo electrónico.
- Si la firma coincide, DKIM se supera.
- Si falta la clave, el registro está mal formado.
- Si la firma no coincide, DKIM falla.
El selector vincula el encabezado del correo electrónico con el registro DNS , ya que sin el registro DNS, el servidor receptor no tendría forma de localizar la clave pública correcta, especialmente cuando un dominio publica varias claves DKIM para diferentes servicios.
Sintaxis y formato del selector DKIM
Los selectores DKIM deben ajustarse a las reglas sintácticas específicas definidas en RFC 6376.
Caracteres permitidos:
- Caracteres alfanuméricos (a–z, A–Z, 0–9)
- Guiones (-)
- Puntos (.) para los selectores de tipo subdominio
Restricciones:
- En la resolución de DNS, los selectores no distinguen entre mayúsculas y minúsculas, aunque lo habitual es utilizar minúsculas.
- En el RFC 6376 no se establece una longitud máxima, pero se aplican las limitaciones prácticas del DNS. La mayoría de las implementaciones mantienen los selectores por debajo de los 63 caracteres (la longitud máxima de una etiqueta DNS).
- Los selectores no pueden empezar ni terminar con un guión.
- Los puntos en los selectores crean jerarquías de subdominios en la consulta DNS. Por ejemplo, `2024.jan._domainkey.example.com` es una ruta de consulta válida si el selector es `2024.jan`.
El formato del registro TXT del DNS en la ruta del selector contiene las siguientes etiquetas:
| Etiqueta | Importancia | Descripción |
|---|---|---|
| v= | Recomendado | Versión (debe ser DKIM1) |
| k= | Opcional | Tipo de clave (por defecto «rsa»; también admite «ed25519») |
| p= | Requerido | Clave pública codificada en Base64 (un valor vacío revoca la clave) |
| t= | Opcional | Parámetros (por ejemplo, «t=s» para la alineación estricta de dominios, «t=y» para el modo de prueba) |
| h= | Opcional | Algoritmos de hash aceptables |
| s= | Opcional | Tipo de servicio (por defecto «*», lo que significa todos los servicios) |
Nota: Las claves RSA de 2048 bits generan cadenas de clave pública que superan el límite de 255 caracteres para una sola cadena TXT de DNS. El DNS gestiona esto mediante registros TXT de varias cadenas, en los que el valor se divide en varias cadenas entre comillas que el resolutor concatena según la RFC 6376. Sin embargo, no todas las interfaces de gestión de DNS gestionan esto de manera eficiente, lo que es una causa habitual de fallos de DKIM.
Cómo encontrar su selector DKIM
Existen cuatro métodos fiables para averiguar qué selectores DKIM se utilizan en un dominio determinado. Cada uno tiene sus propias ventajas, dependiendo de si controlas el dominio, tienes acceso a los encabezados de los correos electrónicos o estás realizando una auditoría desde fuera.
Método 1: Revisar los encabezados del correo electrónico
La forma más directa de hacerlo es revisar los encabezados del correo electrónico. Abre un mensaje enviado desde el dominio en cuestión y consulta los encabezados completos del correo electrónico.
- En Gmail: Abre el mensaje → haz clic en el menú de los tres puntos → «Mostrar original».
- En Outlook: Abre el mensaje → Archivo → Propiedades → «Encabezados de Internet».
- En Apple Mail: Ver → Mensaje → Todos los encabezados.
Busca el encabezado «DKIM-Signature» y localiza la etiqueta «s=». Ese valor es el selector.
Si el correo electrónico ha pasado por varios servicios de firma, es posible que aparezca más de un encabezado `DKIM-Signature`, cada uno con un selector diferente.
Método 2: Utilizar una herramienta de consulta DKIM
Si conoces el nombre del selector, puedes consultar el registro DKIM directamente en selector._domainkey.example.com. Búsqueda de registros DKIM de PowerDMARC, MXToolbox o herramientas de línea de comandos de DNScomo dig y nslookup pueden devolverel registro TXT publicado para ese selector.
Usando dig:
bash
dig TXT selector1._domainkey.example.com +short
Uso de nslookup:
bash
nslookup -q=TXT selector1._domainkey.example.com
Este método requiere que ya conozcas el nombre del selector o que pruebes con los valores predeterminados más habituales.
La herramienta de consulta DKIM de PowerDMARC también puede detectar automáticamente selectores para muchos dominios, validar la sintaxis DKIM, identificar registros que faltan o que están mal formados, y ayudar a resolver problemas comunes de configuración de DKIM.
Método 3: Comprueba la consola de administración de tu ESP
La mayoría de los proveedores de servicios de correo electrónico muestran el selector DKIM y la clave pública en su configuración de autenticación. Por ejemplo:
- Google Workspace: Consola de administración → Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico
- Microsoft 365: Portal de Defender → Políticas y reglas → Políticas de amenazas → Autenticación de correo electrónico → DKIM
- Mailchimp: Sitio web → Dominios → Autenticación → Configuración de DKIM
Método 4: Informes agregados de DMARC
Este es el método más eficaz para detectar todos los selectores que firman activamente el correo de tu dominio, incluidos aquellos de los que quizá no tengas constancia.
Informes agregados de DMARC (informes RUA) incluyen los resultados de la autenticación DKIM de cada mensaje recibido por los servidores de correo que envían los informes. Cada resultado incluye el selector utilizado, el dominio de firma y el estado de aprobado/fallido.
Si tu organización utiliza varios proveedores de servicios de correo electrónico (ESP) o si hay servicios de terceros que envían mensajes en tu nombre, los informes DMARC revelarán selectores que quizá no detectarías solo con la inspección de los encabezados. Esto resulta especialmente útil para descubrir servicios de correo electrónico de «TI en la sombra» que se autorizaron en su momento y nunca se han desactivado.
El analizador DMARC de analizador DMARC analiza estos informes agregados automáticamente y muestra todos los selectores DKIM activos por dominio en un único panel de control, lo que elimina la necesidad de extraer y cruzar manualmente datos XML de múltiples fuentes de informes.
Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.
5. Selectores DKIM predeterminados de ESP: Tabla de referencia 2026
Una de las tareas más habituales en la gestión de DKIM es identificar qué selector corresponde a cada servicio de correo electrónico. En la tabla siguiente se enumeran los selectores DKIM predeterminados que utilizan los 14 principales proveedores de servicios de correo electrónico (ESP) a principios de 2026.
Importante: Los ESP pueden cambiar los selectores predeterminados en cualquier momento, y algunas plataformas asignan selectores específicos para cada cuenta o aleatorios. Comprueba siempre el selector que aparece en tu propia consola de administración del ESP con esta tabla.
| ESP/Plataformas de correo electrónico | Selector(es) predeterminado(s) | Tipo de clave | Nota |
|---|---|---|---|
| Espacio de trabajo de Google | RSA de 2048 bits | Configurable a través de la consola de administración | |
| Microsoft 365 | `selector1`, `selector2` | RSA de 2048 bits | Utiliza dos selectores para la rotación automática. La rotación puede tardar hasta 96 horas en completarse. |
| Amazon SES | El formato varía según la región; por ejemplo, `224i4yxa5dv7c2xz3..` | RSA de 2048 bits | Único por conjunto de configuración. Compruébalo en la consola SES |
| Mailchimp | `k1` | RSA de 2048 bits | Comprueba la configuración de autenticación del dominio de la cuenta |
| SendGrid (Twilio | `s1`, `s2` | RSA de 2048 bits | Rotación automática de claves entre `s1` y `s2` |
| Matasellos | Basado en la fecha, p. ej., `20221121 | RSA de 2048 bits | Basado en CNAME; el selector cambia según la rotación |
| Salesforce Marketing Cloud | Depende de la configuración de la cuenta | RSA | La configuración de DKIM en SFMC varía considerablemente en función del tipo de cuenta, la configuración de SAP y la configuración del dominio de envío. Compruébalo con tu cuenta específica. |
| HubSpot | `hs1`, `hs2` | RSA de 2048 bits | Configurado a través de los ajustes de conexión del dominio |
| Zohomail | `zoho` | RSA de 1024 bits (predeterminado) | 1024 bits de forma predeterminada; se puede ampliar a 2048 bits en la configuración de administración |
| Contacto permanente | Compruébalo en la configuración de la cuenta | RSA | El nombre del selector puede variar según la cuenta. Compruébalo en tu panel de autenticación. |
| Klaviyo | Compruébalo en la configuración de la cuenta | RSA | El nombre del selector puede variar. Compruébalo en la configuración de autenticación de dominio de Klaviyo. |
| Campaña activa | Compruébalo en la configuración de la cuenta | RSA | El nombre del selector puede variar. Compruébalo en la página de autenticación por correo electrónico de tu cuenta. |
| Brevo (antes Sendinblue) | Compruébalo en la configuración de la cuenta | RSA | Confirma el selector en el panel de configuración del dominio de Brevo |
| Mimecast | `mimecast20190104` (formato de ejemplo) | RSA de 2048 bits | Formato con fecha. Selector real emitido durante el proceso de incorporación |
Si tu dominio envía correos electrónicos a través de tres o cuatro de estas plataformas al mismo tiempo, tendrás tres o cuatro selectores DKIM activos en tu DNS, y cada uno de ellos debe ser supervisado, verificado y renovado de forma independiente.
La gestión de múltiples selectores DKIM en varios proveedores de servicios de correo electrónico (ESP) se complica a gran escala, sobre todo cuando cada plataforma tiene diferentes calendarios de rotación, formatos de selector y requisitos de DNS.
PowerDMARC Hosted DKIM ayuda a centralizar la gestión de selectores a través de un único panel de control, lo que facilita añadir, rotar, validar y supervisar los selectores DKIM sin tener que modificar repetidamente los registros DNS de forma manual.
Convenciones de nomenclatura y buenas prácticas
Los selectores DKIM pueden recibir prácticamente cualquier nombre, siempre que se respeten las reglas sintácticas. Sin una convención de nomenclatura coherente, la gestión de los selectores se complica rápidamente a medida que se añaden servicios y se renuevan las claves.
Patrones de nomenclatura recomendados
Un sistema de nomenclatura estructurado facilita enormemente la identificación de la propiedad, el seguimiento de las rotaciones, la resolución de fallos y la prevención de confusiones operativas en el futuro.
Patrón 1: ESP + Fecha
Ejemplos:
- google-2026q1
- sendgrid-202601
- hubspot-4º trimestre de 2025
Este es el patrón más útil desde el punto de vista operativo. De un solo vistazo, puedes identificar qué servicio es el propietario de la clave y cuándo se rotó por última vez. Durante una auditoría, puedes señalar inmediatamente cualquier selector cuya fecha tenga más de 12 meses de antigüedad.
Patrón 2: Función de servicio + Secuencia
Ejemplos:
- marketing-01
- transaccional-01
- corporativo-01
Resulta útil cuando varios proveedores de servicios de correo electrónico (ESP) prestan servicio al mismo dominio y se desea organizar los selectores por flujo de correo en lugar de por proveedor.
Plantilla 3: Configuración predeterminada de ESP (sin nombres personalizados)
Muchos proveedores de servicios de correo electrónico (ESP) no permiten personalizar los nombres de los selectores. Google Workspace utiliza siempre «google». Microsoft 365 utiliza «selector1» y «selector2». En estos casos, hay que trabajar con lo que ofrece la plataforma y gestionar la correspondencia de forma externa.
Prácticas de denominación que deben evitarse
Los nombres mal estructurados o demasiado genéricos pueden generar confusión durante las auditorías, la resolución de problemas y las rotaciones de claves, especialmente en entornos con múltiples ESP y un gran número de selectores activos. Evita las siguientes prácticas de denominación:
- Nombres genéricos sin contexto: `key1`, `test`, `dkim` no proporcionan información sobre el ESP ni sobre el estado de rotación.
- Selectores que contienen información confidencial: No incluyas detalles de la infraestructura interna, nombres de host de servidores ni identificadores de empleados en los nombres de los selectores. Los nombres de los selectores son visibles públicamente a través del DNS.
- Selectores excesivamente largos: Aunque técnicamente se permiten hasta 63 caracteres, los selectores de más de 30 caracteres añaden una complejidad innecesaria a los registros DNS y a los comandos de búsqueda.
La configuración de un único dominio y un único proveedor de servicios de correo electrónico (ESP) es sencilla. Basta con generar un par de claves, publicar la clave pública bajo el selector del ESP y ya está. Las dificultades operativas surgen cuando ese mismo dominio envía correos electrónicos a través de varias plataformas.
Un marco práctico de gestión
El siguiente ciclo de vida de cinco etapas ofrece un enfoque estructurado para la gestión de selectores:
Fase 1: Inventario
Documenta todos los selector DKIM para cada dominio que gestione, incluyendo el ESP, la longitud de la clave, la fecha de publicación y la persona o equipo responsable. Los informes agregados de DMARC son la forma más rápida de crear este inventario, ya que revelan todos los selectores que actualmente firman el correo de su dominio, incluidos aquellos que nadie recuerda haber configurado.
Fase 2: Validar
Para cada selector de tu inventario, consulta el DNS para confirmar que la clave pública está publicada y tiene el formato correcto. Envía un correo electrónico de prueba a través de cada proveedor de servicios de correo electrónico (ESP) y comprueba que la validación DKIM sea satisfactoria. Comprueba la longitud de las claves y marca cualquier selector que utilice una clave de 1024 bits.
Etapa 3: Estandarizar
Adopta una convención de nomenclatura y aplícala a todos los selectores que controles. En el caso de los ESP que utilicen nombres de selectores fijos, documenta claramente la correspondencia. Establece un calendario de rotación y asigna la responsabilidad.
Etapa 4: Supervisar.
Utiliza los informes agregados de DMARC para supervisar de forma continua las tasas de éxito y fracaso de DKIM por selector. Un aumento repentino de la tasa de fracaso en un selector concreto suele indicar un cambio en el DNS, la caducidad de una clave o un cambio de configuración en el proveedor de servicios de correo electrónico (ESP).
Fase 5: Desmantelamiento
Cuando dejes de utilizar un ESP, revoca su clave DKIM publicando un valor `p=` vacío en el registro DNS del selector. No te limites a eliminar el registro DNS. Un valor `p=` vacío indica explícitamente a los servidores receptores que la clave ha sido revocada. Eliminar el registro por completo provoca un error en la consulta DNS, lo cual es ambiguo y puede interpretarse de forma diferente según el receptor.
PowerDMARC ofrece un panel de control centralizado que muestra todos los selectores DKIM activos en todos los dominios de su cuenta, extrayendo datos simultáneamente de los informes agregados de DMARC y de la supervisión del DNS. Para los MSP que gestionan grandes carteras de clientes, esto sustituye al seguimiento basado en hojas de cálculo, que se vuelve inmanejable cuando se superan unas pocas docenas de dominios.
Rotación de claves DKIM y estrategia de selección
La rotación de claves DKIM consiste en generar un nuevo par de claves y publicar la nueva clave pública bajo un selector nuevo (o actualizado), para luego configurar el servicio de envío para que firme con la nueva clave privada.
Una clave privada DKIM que no se cambia durante años supone un riesgo cada vez mayor. Si la clave se ve comprometida debido a una brecha de seguridad en el servidor, una amenaza interna o una vulnerabilidad en el sistema de almacenamiento de claves, un atacante podría firmar correos electrónicos que superen la autenticación DKIM en nombre de tu dominio. La rotación periódica de las claves limita el periodo de exposición.
Cómo rotar las claves DKIM sin interrupciones del servicio
El proceso de rotación estándar utiliza dos selectores en secuencia:
- Generar un nuevo par de claves: Crea un nuevo par de claves RSA (o Ed25519) de 2048 bits.
- Publica la nueva clave pública bajo un nuevo selector: Por ejemplo, si su selector actual es `google-2025q3`, publique la nueva clave bajo `google-2026q1`.
- Espera a que se propague el DNS: Espere entre 24 y 48 horas a que el nuevo registro TXT se propague a nivel mundial. En el caso concreto de Microsoft 365, espere hasta 96 horas para que se propague por completo.
- Actualiza la configuración de firma: Configure el ESP o el servidor de correo para que firme los mensajes salientes utilizando la nueva clave privada y el nuevo selector.
- Comprueba: Envía mensajes de prueba y comprueba que DKIM se supera con el nuevo selector.
- Revoca la clave antigua: Tras un periodo de transición (normalmente de 7 a 14 días, para permitir que se entreguen los mensajes en tránsito firmados con la clave antigua), publique un valor `p=` vacío para el selector antiguo.
Rotación de claves DKIM en entornos con múltiples proveedores de servicios de correo electrónico
Cada ESP tiene su propio mecanismo de rotación:
- Microsoft 365: ofrece una rotación de selectores integrada entre `selector1` y `selector2`. Inicie la rotación a través del portal de Defender.
- SendGrid: alterna automáticamente entre `s1` y `s2`.
- Google Workspace: requiere la regeneración manual de la clave a través de la Consola de administración.
- La mayoría de las plataformas de marketing: requieren una rotación manual a través de su configuración de autenticación de dominio.
Rotar todos los selectores el mismo día crea un periodo de riesgo concentrado y dificulta la resolución de problemas si se produce alguna avería. Distribuye las rotaciones a lo largo de diferentes semanas o meses.
La función de DKIM alojada de PowerDMARC se encarga de la generación de claves, la publicación en el DNS y la rotación de selectores para todos los dominios de tu cuenta, con calendarios de rotación configurables por dominio y por ESP.
Errores habituales en los selectores DKIM y cómo solucionarlos
Cuando falla DKIM, la causa suele deberse casi siempre a uno de los pocos errores de configuración del selector o del DNS. En la tabla siguiente se recogen los fallos más habituales, sus síntomas y cómo solucionarlos.
| Error | Síntoma | Causa | Fijar |
|---|---|---|---|
| No se ha encontrado el selector | Resultado de DKIM: «permerror» o «none»; la consulta DNS devuelve NXDOMAIN | El registro TXT de DNS del selector no existe o se ha publicado en una ruta incorrecta. | Verify the full DNS path: `{selector}._domainkey.{domain}`. Check for typos in the selector name and domain. Confirm the record exists using `dig TXT {selector}._domainkey.{domain}`. |
| La clave pública está vacía | Resultado de DKIM: `fail` | El registro TXT existe, pero contiene «p=» sin ningún valor, lo que indica que la clave ha sido revocada | Esto es intencionado en el caso de los selectores desactivados. Si la clave debe estar activa, vuelve a publicar el valor completo de la clave pública. |
| La clave pública está truncada | Resultado de DKIM: «fail»; el valor «p=» parece estar cortado | Las claves RSA de 2048 bits generan cadenas Base64 que superan el límite de 255 caracteres de los registros TXT del DNS. Algunas interfaces de gestión del DNS truncan silenciosamente los valores largos en lugar de dividirlos en varios registros, tal y como establece el RFC 6376. | Comprueba que tu proveedor de DNS gestione correctamente los registros TXT de varias cadenas. El valor de la clave pública debe dividirse en varias cadenas entre comillas dentro de un único registro TXT (por ejemplo, `"v=DKIM1; k=rsa; p=MIIBIjAN..." "BgkqhkiG9w0B..."`). Algunos proveedores de DNS requieren que introduzcas el valor como una sola cadena sin interrupciones y se encargan de la división automáticamente. Otros requieren la división manual. Prueba con `dig TXT` y confirma que se devuelve la clave completa. Si tu proveedor de DNS la trunca sin avisar, considera cambiar de proveedor o utilizar una configuración DKIM basada en CNAME en la que el ESP aloje el registro TXT. |
| Discrepancia en el tipo de clave | Resultado de DKIM: `fail` | La etiqueta `k=` del registro DNS indica un algoritmo diferente al utilizado por el servidor de firma. Por ejemplo, `k=rsa` en el DNS, pero el correo electrónico se firmó con Ed25519 | Asegúrate de que la etiqueta `k=` coincida con el algoritmo de firma. Si utilizas tanto RSA como Ed25519, cada uno necesita su propio selector y el registro DNS correspondiente |
| Error de sintaxis en el registro TXT | Resultado de DKIM: `permerror` | Falta de puntos y comas, espacios de más dentro de los valores de las etiquetas o nombres de etiquetas incorrectos en el registro TXT del DNS | Compara tu registro con las especificaciones. Cada par de etiqueta-valor debe estar separado por un punto y coma. El valor `p=` debe contener únicamente caracteres Base64 válidos, sin espacios ni saltos de línea dentro de la cadena codificada. |
| Alineación incorrecta del dominio | DKIM se supera, pero DMARC falla | El dominio «d=» de la firma DKIM no coincide con el dominio «From:». El selector y la clave son correctos, pero el dominio de firma es incorrecto a efectos de DMARC. | |
| El CNAME no se resuelve | Resultado de DKIM: `temperror` o `none` | Algunos proveedores de servicios de correo electrónico (ESP) utilizan registros CNAME para dirigir la ruta de selección hacia su propia infraestructura de DNS. Si el registro CNAME no funciona correctamente o falta el registro de destino, la búsqueda falla. | Verify the CNAME resolves correctly: `dig CNAME {selector}._domainkey.{domain}`. Then verify the destination TXT record exists and contains the public key |
El problema del truncamiento de 2048 bits en detalle
Cuando las organizaciones actualizan sus claves DKIM de 1024 bits a 2048 bits (dado que el RSA de 1024 bits se considera poco seguro para fines de DKIM), la clave pública codificada en Base64 prácticamente duplica su longitud. La cadena resultante suele superar los 400 caracteres.
Los registros TXT del DNS tienen un límite de 255 caracteres por cadena dentro del registro. La solución, definida en el RFC 6376, consiste en dividir el valor en varias cadenas dentro de un mismo registro TXT. Los servidores de correo receptores concatenan estas cadenas automáticamente.
La mayoría de las interfaces de gestión de DNS más populares no gestionan esto de forma eficaz:
- Algunas interfaces recortan el valor a 255 caracteres sin previo aviso.
- Algunas interfaces rechazan la entrada por completo con un mensaje de error impreciso.
- Algunas interfaces requieren que el administrador divida manualmente la cadena y coloque cada segmento entre comillas.
Si publicas una clave de 2048 bits y DKIM empieza a fallar inmediatamente, comprueba la respuesta real del DNS con `dig` o `nslookup`. Compara el valor `p=` devuelto con la clave pública completa de tu par de claves. Si el valor devuelto es más corto, tu proveedor de DNS lo ha truncado.
Para evitarlo:
- Utiliza un proveedor de DNS que admita de forma nativa registros TXT largos (Cloudflare, AWS Route 53 y la mayoría de las plataformas de DNS empresariales lo gestionan correctamente).
- Utiliza DKIM basado en CNAME, en el que la ruta DNS del selector apunta a un CNAME alojado por el proveedor de servicios de correo electrónico (ESP). El ESP gestiona el registro TXT en su propia infraestructura, lo que evita por completo el problema.
- Si tienes que utilizar un proveedor que requiera la división manual, divide la clave en cadenas de 250 caracteres o menos, cada una entre comillas, dentro de un único registro TXT.
Selectores DKIM y alineación DMARC
DKIM y DMARC son protocolos independientes, pero interactúan de una forma que pilla desprevenidos a muchos administradores. Es posible que DKIM supere la comprobación mientras que DMARC siga fallando. Cuando esto ocurre, la causa suele ser casi siempre una discrepancia en la correspondencia de dominios, relacionada con la forma en que el dominio de firma del selector se relaciona con el dominio del encabezado «From:».
Cómo funciona la alineación de DMARC con DKIM
DMARC exige que al menos un mecanismo de autenticación (SPF o DKIM) supere la comprobación y coincida con el dominio indicado en el encabezado «From:».
Para la alineación DKIM en concreto, el dominio `d=` del encabezado DKIM-Signature debe coincidir con el dominio del encabezado `From:`. El selector en sí no se tiene en cuenta para la alineación. La alineación se basa únicamente en el dominio `d=`.
DMARC admite dos modos de alineación:
| Modo | Requisito | Ejemplo |
|---|---|---|
| Relajado (predeterminado) | El dominio «d=» debe ser el mismo que el dominio «From:» o un subdominio de este (o viceversa) | `d=mail.example.com` coincide con `From: [email protected]` |
| Estricto | El dominio «d=» debe coincidir exactamente con el dominio «From:». | | `d=mail.example.com` **no** coincide con `From: [email protected]` |
Los dos casos en los que DKIM se supera pero DMARC falla
Uno de los resultados más confusos en la autenticación del correo electrónico es que DKIM pase la comprobación mientras que DMARC siga fallando. Esto suele ocurrir cuando la firma en sí es válida, pero el dominio que la ha firmado no coincide correctamente con el dominio del campo «De:» que aparece en el mensaje.
Escenario 1: Un proveedor de servicios de correo electrónico externo utiliza su propio dominio
Algunos proveedores de servicios de correo electrónico (ESP), cuando DKIM no está configurado explícitamente para tu dominio, firman los mensajes salientes con el propio dominio del ESP en `d=`. Por ejemplo, un correo electrónico enviado en nombre de `[email protected]` podría incluir una firma DKIM con `d=esp-provider.com`.
La verificación DKIM se supera (la firma es válida), pero DMARC falla porque `esp-provider.com` no coincide con `example.com`.
Configura la firma DKIM en el proveedor de servicios de correo electrónico (ESP) para utilizar tu propio dominio en la etiqueta `d=`. Para ello, normalmente hay que añadir el selector DKIM del ESP como un registro DNS en tu dominio y habilitar la firma DKIM personalizada en la configuración del ESP.
Escenario 2: Firma de subdominios con alineación DMARC estricta
Si tu política DMARC utiliza la alineación estricta (`adkim=s`) y tu proveedor de servicios de correo electrónico (ESP) firma con `d=sub.example.com`, mientras que la dirección `From:` utiliza `example.com`, DMARC dará un resultado negativo aunque DKIM pase la comprobación.
Cambia a la alineación flexible (`adkim=r`, que es la predeterminada) o asegúrate de que el dominio `d=` de la firma DKIM coincida exactamente con el dominio `From:`.
Verificación de la coherencia entre varios proveedores de servicios de educación
En entornos con varios ESP, cada plataforma de envío puede firmar con diferentes dominios `d=`. Un ESP puede firmar con tu dominio raíz, otro con un subdominio y un tercero puede utilizar por defecto su propio dominio hasta que configures la firma personalizada.
Los informes agregados de DMARC muestran el dominio «d=» y el resultado de la alineación de cada mensaje firmado con DKIM. Revisa estos informes para identificar cualquier proveedor de servicios de correo electrónico (ESP) que esté firmando con un dominio desalineado. Los informes DMARC de PowerDMARC destacan los fallos de alineación por fuente de envío, lo que facilita identificar qué ESP necesita una reconfiguración.
Conclusión
Las organizaciones que consideran la gestión de selectores como una práctica operativa continua, en lugar de una tarea de configuración puntual, son las que mantienen una capacidad de entrega constante, superan las auditorías sin problemas y responden rápidamente a los incidentes.
Si gestionas más de unos pocos dominios o trabajas con varios proveedores de servicios de correo electrónico (ESP), merece la pena invertir en centralizar la visibilidad de tu selector DKIM.
PowerDMARC ofrece esa visión centralizada, combinando el análisis de informes agregados de DMARC, la supervisión del DNS y la gestión de DKIM alojada en una única interfaz diseñada precisamente para este tipo de complejidad operativa.
Gestiona fácilmente los selectores DKIM en varios proveedores de correo electrónico. Regístrate para obtener una prueba para supervisar los registros DKIM, mejorar la alineación con DMARC y proteger la entregabilidad del correo electrónico.
Preguntas frecuentes
¿Cómo puedo averiguar cuál es mi selector DKIM?
Puedes encontrar tu selector DKIM consultando los encabezados completos de un correo electrónico y localizando el campo DKIM-Signature . El valor que aparece después de s= es el selector. Por ejemplo, en s=google, el selector es google.
¿Cuántos selectores DKIM puede tener un dominio?
No existe ningún límite técnico en cuanto al número de selectores DKIM que puede tener un dominio. Las organizaciones suelen utilizar varios selectores a la vez para distintos proveedores de correo electrónico, departamentos o períodos de rotación de claves.
¿Pueden varios proveedores de servicios de correo electrónico (ESP) utilizar diferentes selectores DKIM en el mismo dominio?
Sí. Cada proveedor de servicios de correo electrónico suele utilizar su propio selector DKIM. Por ejemplo, Google Workspace, SendGrid y Mailchimp pueden tener selectores distintos bajo el mismo dominio sin que se produzca ningún conflicto.
¿Cuál es la diferencia entre un selector DKIM y una clave DKIM?
El selector es la etiqueta que se utiliza para localizar el registro DKIM en el DNS, mientras que la clave DKIM es el par de claves criptográficas pública y privada que se utiliza para firmar y verificar los correos electrónicos.
¿Por qué se supera la validación DKIM pero sigue fallando la de DMARC?
Esto suele ocurrir debido a un error de alineación de DMARC. Es posible que la firma DKIM se valide correctamente, pero el d= del dominio en la firma DKIM no coincide con el From: utilizado en el correo electrónico.
¿Con qué frecuencia se deben rotar los selectores y las claves DKIM?
Las mejores prácticas de seguridad recomiendan rotar las claves DKIM cada 6-12 meses. Durante la rotación, tanto los selectores antiguos como los nuevos deben permanecer activos temporalmente para evitar errores de validación mientras se propaga el DNS.
- ¿Qué es un selector DKIM y cómo gestionarlo en varios proveedores de servicios de correo electrónico? - 26 de mayo de 2026
- Comprobación de SPF en Exchange: cómo verificar, publicar y corregir registros SPF en Exchange - 20 de mayo de 2026
- Cómo configurar un registro SPF para Gmail - 17 de febrero de 2026


