El selector DKIM: qué es (y por qué hay varios)

selector1._domainkey.ejemplo.es

selector1._domainkey.ejemplo.es.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (clave pública)"

Por qué a menudo hay varios selectores

Este es el punto que sorprende. Un dominio casi nunca tiene un único selector, y es normal:

• Una plataforma = un selector (como mínimo). Un dominio que envía a través de Microsoft 365, un router de marketing y una herramienta de facturación tiene una clave DKIM por plataforma y, por tanto, un selector por plataforma. Se publica un registro TXT por selector.
• La rotación de claves crea selectores. Al renovar una clave DKIM, se publica una clave nueva bajo un nuevo selector, se cambia la firma a él y luego se retira el antiguo. Durante la transición, dos selectores coexisten (véase rotación de claves).
• Los subdominios pueden tener sus propios selectores.

Tener varios selectores no es, por tanto, un problema: es el funcionamiento esperado. Cada selector es independiente, y un destinatario solo usa el que indica la firma que está verificando.

Qué aspecto tiene un nombre de selector

El nombre del selector es libre, y cada plataforma tiene sus convenciones. Se encuentran, por ejemplo, selector1/selector2 (Microsoft 365), google (Google Workspace), nombres con fecha como s1024-2024, o cadenas generadas por un proveedor. El nombre no tiene ninguna importancia técnica: lo que cuenta es que el selector de la firma coincida con un registro DNS existente. Así que no hay que buscar un sentido oculto en el nombre de un selector: es solo una etiqueta.

Cómo activar un selector DKIM

En la práctica, un selector no se «crea» a mano: la plataforma de envío lo genera y facilita el registro DNS que hay que publicar (a menudo un CNAME que apunta a un registro gestionado por el proveedor, o un TXT con la clave pública). El trabajo se reduce a:

1. Activar DKIM en la consola de la plataforma (Microsoft 365, Google Workspace, el router de envío…).
2. Publicar el registro facilitado, en el selector indicado.
3. Comprobar que la firma pasa y se alinea (véase cómo verificar una firma de correo).

El CNAME suele ser preferible al TXT en bruto: deja que el proveedor rote la clave sin volver a tocar el DNS.

La alineación: el selector no lo hace todo

Un punto crucial para DMARC. Una firma DKIM válida demuestra que un dominio ha firmado el mensaje, pero para DMARC hace falta además que ese dominio (d=) se alinee con el del From:. El selector solo tiene que ver con la recuperación de la clave; es la etiqueta d= la que lleva la alineación. Una firma perfectamente válida puede, por tanto, no contar para DMARC, porque el d= es el del proveedor y no el del remitente. La solución es configurar una firma con marca propia (d=ejemplo.es) en cada plataforma. Este mecanismo se detalla en cómo funcionan juntos los tres protocolos.

Solucionar problemas de un selector

Cuando una firma DKIM falla, el selector suele ser el culpable. Las pistas clásicas:

• El registro DNS del selector no existe o está mal publicado (una errata en el nombre, un subdominio ._domainkey equivocado).
• La clave pública se ha truncado al copiar y pegar (las claves son largas; un carácter que falte rompe la verificación).
• El selector de la firma no coincide con ningún registro, algo típico tras una rotación mal terminada, en la que se retiró el selector antiguo antes de haber cambiado la firma.
• La propagación DNS no ha terminado: un selector recién publicado puede tardar un poco en ser visible en todas partes.

Para confirmarlo, basta consultar directamente el selector en el DNS (dig TXT selector1._domainkey.ejemplo.es) o mediante el analizador DKIM gratuito, y comprobar que la clave pública está ahí y completa.

Preguntas frecuentes

¿Cuántos selectores puede tener un dominio? Tantos como haga falta: no hay un límite que moleste. Una plataforma por selector, más los que crea temporalmente la rotación. Tener varios selectores es sano, no problemático.

¿Se puede borrar un selector antiguo? Sí, pero solo cuando ninguna firma lo use ya (típicamente tras una rotación terminada). Borrar un selector todavía referenciado por mensajes en tránsito rompe su verificación.

¿Es secreto el selector? No. El selector y la clave pública son públicos por naturaleza (están en el DNS y en cada correo firmado). Es la clave privada, del lado de la plataforma de envío, la que debe permanecer secreta.

¿Por qué mi proveedor me da un CNAME en lugar de un TXT? Para poder rotar la clave sin obligar a tocar el DNS en cada rotación. Suele ser la opción correcta: se publica una vez y el proveedor se encarga del resto.

¿Pueden dos plataformas compartir un selector? En teoría sí, pero está desaconsejado: cada plataforma tiene su propia clave y, por tanto, su propio selector. Mezclarlas complica la resolución de problemas y la rotación.

Seguir una verificación paso a paso

Para fijar el papel del selector, sigamos un mensaje real. Una factura sale de empresa.es a través de una plataforma que firma con s=mail2025; d=empresa.es. Esto es lo que hace el servidor destinatario:

1. Lee la cabecera DKIM-Signature y encuentra s=mail2025 y d=empresa.es.
2. Construye la dirección DNS: mail2025._domainkey.empresa.es.
3. Consulta esa dirección y recupera la clave pública publicada.
4. Recalcula el hash del mensaje y lo compara con la firma. Si todo concuerda: dkim=pass.
5. Por último, comprueba que d=empresa.es coincide con el dominio del From:: la alineación, imprescindible para DMARC.

Si uno de estos pasos falla —selector no encontrado, clave truncada, hash distinto—, la firma no pasa. Entender esta cadena es lo que permite diagnosticar cualquier fallo: se sabe exactamente dónde mirar, y en qué orden.

Organizar los selectores con orden

Con el tiempo, un dominio acumula selectores: uno por plataforma, más los que dejan las rotaciones antiguas. Unos pocos principios evitan el caos. Los selectores bajo control propio merecen nombres claros y con fecha (mail-2025, router-marketing), en lugar de cadenas opacas: identificar cuál sirve para qué es entonces inmediato. Un inventario sencillo —qué selector para qué plataforma, desde cuándo— completa el inventario de fuentes de envío. Y, sobre todo, los selectores muertos se retiran una vez terminadas sus rotaciones: un selector huérfano no es peligroso, pero estorba y enturbia el diagnóstico el día en que una firma falla. Un DNS bien cuidado es aquel en el que cada registro _domainkey tiene una razón de ser conocida: es lo que convierte una sesión de diagnóstico de una hora en un vistazo de dos minutos.

Selectores y subdominios: un caso que conviene conocer

Un punto que a menudo sorprende: los subdominios no «heredan» el selector del dominio raíz. Un envío desde news.empresa.es exige un registro DKIM propio para ese subdominio —por ejemplo mail._domainkey.news.empresa.es— y la firma debe indicar d=news.empresa.es para que la alineación DMARC sea correcta. Dominio raíz y subdominios son independientes, con sus propios selectores y sus propias claves. Esta realidad se pasa por alto a menudo cuando se configura DKIM solo para el dominio principal, y luego uno se pregunta por qué los envíos de marketing o las notificaciones automatizadas no aparecen alineados en los informes DMARC. Antes de la pregunta «¿es correcta la clave?» viene otra: «¿hay una clave publicada para cada dominio y subdominio de envío?».

Thomas cartografía los selectores

Entre los selectores de cada plataforma y los que dejan las rotaciones antiguas, es fácil perderse. Thomas, el CISO virtual, identifica cada fuente de envío, localiza el selector que utiliza, comprueba que la clave pública está bien publicada y que la firma se alinea con el dominio, y señala los selectores muertos que conviene limpiar.

Analizar un dominio gratis o crear una cuenta para ver claro en las claves DKIM.