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

selector1._domainkey.ton-domaine.fr

selector1._domainkey.ton-domaine.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (clé publique)"

Por qué a menudo tienes 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). Si envías a través de Microsoft 365, un router de marketing y una herramienta de facturación, cada uno tiene su propia clave DKIM y, por tanto, su propio selector. Publicas un registro TXT por selector.
• La rotación de claves crea selectores. Cuando renuevas una clave DKIM, publicas una clave nueva bajo un nuevo selector, cambias la firma a él y luego retiras 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. Te cruzarás, por ejemplo, con 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, no «creas» un selector a mano: tu plataforma de envío lo genera por ti y te da 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). Tu trabajo se reduce a:

1. Activar DKIM en la consola de la plataforma (Microsoft 365, Google Workspace, tu router de envío…).
2. Publicar el registro que te faciliten, 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 que tengas que volver a tocar tu 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 de tu From:. El selector solo tiene que ver con la recuperación de la clave; es la etiqueta d= la que lleva la alineación. Puedes tener, por tanto, una firma perfectamente válida que no cuente para DMARC, porque el d= es el del proveedor y no el tuyo. La solución es configurar una firma con tu marca (d=ton-domaine.fr) 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, consulta directamente el selector en el DNS (dig TXT selector1._domainkey.ton-domaine.fr) y comprueba que la clave pública está ahí y completa.

Preguntas frecuentes

¿Cuántos selectores puedo tener? Tantos como necesites: 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.

¿Puedo 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 por ti sin que tengas que tocar tu DNS en cada rotación. Suele ser la opción correcta: publicas 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. Envías una factura desde entreprise.fr a través de tu plataforma, que firma con s=mail2025; d=entreprise.fr. Esto es lo que hace el servidor destinatario:

1. Lee la cabecera DKIM-Signature y encuentra s=mail2025 y d=entreprise.fr.
2. Construye la dirección DNS: mail2025._domainkey.entreprise.fr.
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=entreprise.fr 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 te permite diagnosticar cualquier fallo: sabes exactamente dónde mirar, y en qué orden.

Organizar tus 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. Da a tus selectores nombres claros y con fecha cuando los controles (mail-2025, routeur-marketing), en lugar de cadenas opacas: encontrarás más rápido cuál sirve para qué. Lleva un inventario sencillo —qué selector para qué plataforma, desde cuándo— igual que tu inventario de fuentes de envío. Y, sobre todo, retira los selectores muertos 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. Si envías desde news.entreprise.fr, ese subdominio necesita su propio registro DKIM —por ejemplo mail._domainkey.news.entreprise.fr— y la firma debe indicar d=news.entreprise.fr 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 preguntarte «¿es correcta mi clave?», comprueba primero «¿he publicado una clave para cada dominio y subdominio de envío?».

Deja que Thomas cartografíe tus selectores

Entre los selectores de cada plataforma y los que dejan las rotaciones antiguas, es fácil perderse. Thomas, tu 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 tu dominio, y te señala los selectores muertos que conviene limpiar.

Analiza tu dominio gratis → o crea una cuenta para ver claro en tus claves DKIM.