Incompatibilidad de selector DKIM: la solución de 2 minutos

Qué es realmente una incompatibilidad de selector DKIM

DKIM utiliza criptografía de clave pública para permitir que un receptor verifique que un mensaje fue firmado por alguien que controla un dominio.
El receptor extrae una cabecera DKIM-Signature, encuentra un d= (dominio) y un s= (selector), y luego busca un registro TXT en DNS en:

<selector>._domainkey.<domain>

Cuando decimos “incompatibilidad de selector DKIM”, solemos referirnos a una de estas situaciones:

• El mensaje está firmado con el selector s=foo, pero DNS solo tiene bar._domainkey.
• El firmador está configurado para usar el selector foo, pero la clave publicada en foo._domainkey no coincide con la clave privada usada para firmar.
• El dominio en la firma d= no coincide con el dominio donde publicaste el registro (común con subdominios y dominios de “rebote”).
• DNS es correcto, el firmador es correcto, pero la visibilidad de DNS es errónea (DNS de horizonte dividido, resolutores obsoletos, caché o delegación rota).

Las incompatibilidades de DKIM no son problemas de “correo caído”. Son peores: el correo sigue fluyendo, solo con confianza reducida. Eso significa que tu incidente no aparece como una caída limpia. Aparece como “la tubería parece bien” mientras los emails de ingresos aterrizan en spam.
Problema clásico de fiabilidad: el fallo es silencioso hasta que resulta caro.

Un detalle operativo que importa: los receptores a menudo tratan DKIM como una señal entre muchas. Una incompatibilidad puede no rebotar el correo instantáneamente, pero puede inclinar el tráfico borderline sobre el borde—especialmente cuando la reputación de IP es mediocre o envías ráfagas.

Broma #1: los selectores DKIM son como etiquetas de equipaje—pierdes la etiqueta y tu correo todavía viaja, solo que no al destino que querías.

Guía rápida de diagnóstico (primera/segunda/tercera comprobación)

Cuando llega el aviso (“DKIM falla”), tu trabajo es encontrar el cuello de botella rápido: ¿es esto un problema de DNS, de firmado o de alineación de dominio?
No empieces rotando claves. No empieces editando DNS en pánico. Empieza leyendo lo que el correo realmente dice sobre sí mismo.

Primero: confirma qué selector y dominio se están usando ahora mismo

• Toma un mensaje reciente del flujo afectado (no la muestra de la semana pasada).
• Extrae d= y s= de DKIM-Signature.
• Mira Authentication-Results para ver cómo lo evaluó el receptor.

Si el selector en la cabecera no es el que piensas que configuraste, ya terminaste: estás depurando el remitente equivocado o la ruta de firmado equivocada.
En organizaciones grandes existen múltiples firmadores (pasarela en la nube, MTA, sistema de tickets, CRM). El correo que tienes en la mano te dice cuál está firmando realmente.

Segundo: consulta DNS para ese selector exacto

• Consulta TXT para <selector>._domainkey.<domain>.
• Consulta desde al menos dos resolutores diferentes (tu resolutor corporativo y uno público).
• Comprueba NXDOMAIN vs respuesta vacía vs registro truncado/roto.

Si DNS no devuelve una clave DKIM para el selector en la cabecera, arregla DNS o arregla el selector usado por el firmador. Por lo general, una línea.

Tercero: valida que la clave pública coincida con la clave privada del firmador

• En el host que firma, localiza el archivo de clave privada en tu configuración de OpenDKIM/OpenSMTPD/Haraka/lo-que-sea.
• Deriva la clave pública desde la privada y compárala con la que está en DNS (o repubblica la correcta).

Si DNS tiene una clave pero la verificación de la firma falla, probablemente tengas una incompatibilidad de claves (clave equivocada publicada, archivo incorrecto desplegado, selector apuntando a clave antigua, o múltiples firmadores fuera de sincronía).

Idea parafraseada (atribuida): “No puedes mejorar lo que no puedes medir”, a menudo asociada con Peter Drucker. En el terreno de la autenticación de correo, “medir” significa “leer la cabecera y consultar DNS”.

La solución de 2 minutos (la verdad aburrida)

La mayoría de los incidentes de incompatibilidad de selector terminan igual: alguien cambió un selector en un lugar y olvidó que el otro lugar existe.
Lo arreglas haciendo que el selector sea consistente entre:

1. Lo que emite el firmador (el s= en DKIM-Signature)
2. Lo que publica DNS (el registro TXT para ese selector)
3. Qué archivo de clave usa el firmador (clave privada mapeada a ese selector)

La “solución de 2 minutos” más rápida depende de qué lado esté mal:

• DNS sin el selector que está en el correo en producción: publica el registro TXT para ese selector (copia de la clave pública que espera el firmador).
• Firmador usando el selector equivocado: actualiza la configuración del firmador para usar el selector que ya está en DNS, recarga el servicio.
• Incompatibilidad de clave: publica la clave pública correcta para el selector usado, o despliega la clave privada correcta para el selector ya publicado.

El consejo que doy a los equipos: prefiere cambiar el firmador para que coincida con DNS solamente si estás absolutamente seguro de que DNS es correcto y actual.
De lo contrario, adapta DNS a lo que el firmador ya está usando, porque eso es lo que tus receptores están evaluando actualmente. Cambiar el firmador puede tardar en propagarse por pasarelas, contenedores o sistemas de proveedores.

No olvides la caché. Si publicas un nuevo registro TXT, los receptores no necesariamente lo verán de inmediato. Tu TTL autoritativo importa, al igual que el comportamiento de caché del receptor.
Pero: si tu registro no existía (NXDOMAIN) y lo añades, muchos sistemas lo recogerán rápido; el caché negativo aún puede morderte por unos minutos.

Hechos y contexto histórico (por qué sigue ocurriendo)

1. DKIM estandarizado en 2007: Surgió de la fusión de DomainKeys (Yahoo) e Identified Internet Mail (Cisco) en un estándar. Esa fusión explica por qué ves tanto la denominación “domainkey” como la terminología DKIM.
2. Los selectores se diseñaron para la rotación de claves: El selector permite publicar múltiples claves a la vez y cambiar firmadores sin eliminar inmediatamente las claves antiguas.
3. Los límites de longitud de TXT en DNS influyeron en DKIM: Las cadenas TXT tienen limitaciones prácticas de tamaño, y las claves largas a menudo se dividen en múltiples cadenas entrecomilladas. Algunas herramientas manejan esto mal y crean roturas “invisibles”.
4. Los receptores suelen usar canonicalización relajada por defecto: DKIM admite canonicalización “simple” y “relaxed” para tolerar cambios de espacios en tránsito. Por eso muchos correos aún validan incluso después de algunos cambios en el formateo de cabeceras.
5. DMARC (2012) hizo visibles los fallos de DKIM ante los ejecutivos: DKIM existía antes de DMARC, pero los informes y la aplicación de DMARC convirtieron la “autenticación” en un tema de junta directiva.
6. Las claves de 2048 bits se volvieron la base esperada: Las claves de 1024 bits se tratan cada vez más como débiles; algunos receptores las penalizan. Las rotaciones a menudo coinciden con cambiar el tamaño de la clave, lo que aumenta la posibilidad de errores de selector.
7. Algunos proveedores rotan selectores automáticamente: Las plataformas de correo en la nube pueden generar selectores como selector1/selector2 o cadenas propias del proveedor. Los humanos luego las “estandarizan” y rompen cosas.
8. DNS de horizonte dividido es un villano recurrente: Los resolutores internos que devuelven respuestas distintas a los externos pueden hacer que DKIM parezca correcto dentro de la empresa mientras falla en internet público.

Tres mini-historias corporativas (cómo rompen el correo los adultos)

Mini-historia #1: El incidente causado por una suposición incorrecta

Una empresa SaaS mediana migró de una pila on-prem Postfix + OpenDKIM a un relé de correo en la nube para notificaciones salientes.
El plan de migración tenía una hoja de cálculo ordenada: “Actualizar SPF, configurar DKIM, verificar DMARC.” Todos asintieron. El evento del calendario decía “30 minutos.”

El ingeniero que hizo el trabajo de DNS asumió que el nombre del selector era arbitrario, así que eligió algo memorable: prod2025.
Publicó prod2025._domainkey.example.com con la clave que mostraba la interfaz del relé. Limpio.

Pero el relé ya estaba firmando mensajes con s=selector1. La página de “configuración DKIM” del UI mostraba dos selectores y un interruptor para rotación.
El ingeniero vio “prod2025” en la documentación y pensó que debía nombrarlo él mismo, así que lo hizo. Nunca cambió el selector real del relé.

Resultado: la autenticación falló para todo el correo saliente, la política DMARC fue “quarantine” y los correos de restablecimiento de contraseña más importantes empezaron a llegar a spam. Los tickets de soporte se dispararon. Nadie pudo reproducirlo internamente porque su buzón de prueba tenía reglas de lista blanca.

La solución fue casi insultante: publicar el registro TXT para selector1 y dejar de inventar nombres de selectores a menos que también vayas a cambiar el firmador.
El postmortem tuvo un buen aprendizaje: cuando falla la autenticación de correo, lee la cabecera primero. No confíes en lo que pretendías configurar.

Mini-historia #2: La “optimización” que salió mal

Una compañía global tenía una flota ordenada de pasarelas de correo en dos regiones. Alguien decidió “optimizar” las actualizaciones de DNS bajando el TTL de todos los registros DKIM a 60 segundos.
La idea: rotación de claves más rápida, rollback más rápido, menos riesgo. Suena razonable en una reunión.

Lo que realmente pasó: su proveedor DNS autoritativo empezó a limitar la tasa de tráfico de algunos resolutores y ocasionalmente devolvía SERVFAIL durante horas pico.
No fue una caída total; fue intermitente y dependiente de carga. Las pasarelas de correo seguían firmando con el mismo selector, pero los receptores a veces no podían recuperar la clave debido a fallos DNS transitorios.

DKIM empezó a fallar esporádicamente en proveedores de correo masivos. Los equipos de entregabilidad vieron “algunas campañas bien, otras no”, que es el tipo de incertidumbre que hace pelear a todos.
El SRE de guardia no vio errores en las pasarelas. El servicio de firmado DKIM estaba sano. El problema estaba aguas abajo: la recuperación de claves.

Revirtieron el TTL a un valor sensato (horas, no segundos), ajustaron la configuración del proveedor DNS y dejaron de tratar DKIM como un sistema de feature flags.
La “optimización” aumentó el volumen de consultas, amplificó un eslabón débil y les dio un modo de fallo difícil de detectar desde dentro de su red.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día

Una organización de servicios financieros tenía una práctica aburrida: cada sistema de correo saliente enviaba semanalmente un correo canario a un buzón externo dedicado en dos proveedores.
El buzón era vigilado por un script que analizaba cabeceras, registraba resultados DKIM/SPF/DMARC y alertaba sobre cambios.

Un proveedor rotó un selector DKIM un viernes por la noche como parte del “mantenimiento rutinario de seguridad.”
Para la mañana del sábado, la alarma del canario saltó: DKIM falló (selector no encontrado). Nadie estaba en una gran bridge de incidentes porque los sistemas de producción estaban bien—solo se había roto la confianza del correo.

El de guardia siguió el playbook: leyó la cabecera, vio s=vendor2026, consultó DNS, NXDOMAIN.
Su equipo de DNS publicó el nuevo registro en minutos, porque ya tenían un procedimiento de cambio y una lista preaprobada de subdominios DKIM.

Sin impacto notable para clientes. Que es exactamente el punto.
No “fueron rápidos”. Actuaron de forma predecible.

Tareas prácticas: comandos, salida esperada y decisiones

A continuación hay tareas reales que puedes ejecutar durante un incidente. Cada una incluye: el comando, qué significa una salida típica y qué decisión tomar a continuación.
Ajusta nombres de host, dominios y rutas a tu entorno, pero mantén la lógica.

Task 1: Extract selector and domain from a DKIM-Signature header

cr0x@server:~$ grep -i '^DKIM-Signature:' -m1 -n /tmp/message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Qué significa: El correo en vivo declara d=example.com y s=selector1.

Decisión: Deja de debatir. Tu búsqueda DNS debe dirigirse a selector1._domainkey.example.com.

Task 2: Check receiver-side evaluation in Authentication-Results

cr0x@server:~$ grep -i '^Authentication-Results:' -n /tmp/message.eml | head
12:Authentication-Results: mx.google.com;
13:       dkim=fail header.i=@example.com header.s=selector1 header.b=AbCdEf;
14:       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
15:       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Qué significa: DKIM falló para selector1; SPF pasó pero DMARC falló (probablemente problema de alineación o DKIM requerido por la política).

Decisión: Centra el esfuerzo en la disponibilidad y corrección del registro DKIM primero; luego comprueba la alineación DMARC cuando DKIM pase.

Task 3: Query the DKIM TXT record with your default resolver

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com

Qué significa: No salida típicamente indica NXDOMAIN o que no se devolvió registro TXT (dependiendo de las opciones de dig).

Decisión: Vuelve a ejecutar con más detalle para distinguir “sin registro” de “fallo DNS”.

Task 4: Distinguish NXDOMAIN vs SERVFAIL vs empty answer

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51234
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Qué significa: NXDOMAIN: el nombre no existe públicamente (o no desde este resolutor).

Decisión: Publica el registro que falta, o arregla el selector usado por el firmador si DNS ya tiene uno diferente.

Task 5: Query authoritative DNS directly (remove “my resolver lies”)

cr0x@server:~$ dig +short NS example.com
ns1.dns-provider.net.
ns2.dns-provider.net.

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @ns1.dns-provider.net
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa: El servidor autoritativo tiene el registro.

Decisión: Si los receptores aún fallan, sospecha de caché de resolutor, demoras de propagación, o que el receptor está viendo una vista DNS diferente (horizonte dividido, problemas de delegación).

Task 6: Compare answers from a public resolver (external reality check)

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @8.8.8.8
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa: El resolutor público ve la clave. Bien.

Decisión: Si DKIM aún falla, pasa a incompatibilidad de clave / ruta de firmado / canonicalización y cambios en las cabeceras.

Task 7: Check if the record is broken by quoting, whitespace, or missing tags

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." "morekeymaterial..."

Qué significa: Las cadenas TXT partidas son normales. Los receptores las concatenan. La ausencia de k=rsa suele estar bien (existen valores por defecto), pero las etiquetas malformadas o las comillas inteligentes no.

Decisión: Si el registro contiene comillas no ASCII, puntos y comas fuera de lugar o saltos de línea insertados por la UI de DNS, corrige el formato del registro.

Task 8: Verify OpenDKIM is actually signing and which selector it uses

cr0x@server:~$ sudo opendkim-testkey -d example.com -s selector1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'selector1._domainkey.example.com'
opendkim-testkey: key OK

Qué significa: Desde este host, OpenDKIM puede recuperar la clave pública y la analiza correctamente.

Decisión: Si los receptores remotos aún fallan, o no pueden obtener DNS o el firmador no está usando realmente esta clave/selector para el flujo de correo afectado.

Task 9: Identify which KeyTable/SigningTable rule applies (common mismatch source)

cr0x@server:~$ sudo grep -R --line-number -E 'SigningTable|KeyTable|Selector|Domain' /etc/opendkim.conf /etc/opendkim/*
/etc/opendkim.conf:12:KeyTable           /etc/opendkim/KeyTable
/etc/opendkim.conf:13:SigningTable       refile:/etc/opendkim/SigningTable
/etc/opendkim/KeyTable:5:selector1._domainkey.example.com example.com:selector1:/etc/opendkim/keys/example.com/selector1.private
/etc/opendkim/SigningTable:3:*@example.com selector1._domainkey.example.com

Qué significa: Para correo desde @example.com, pretendes firmar con selector1 usando un archivo de clave privada específico.

Decisión: Si la cabecera muestra un selector diferente, tu ruta real de correo está evitando este firmador o un firmador distinto está añadiendo DKIM después.

Task 10: Confirm the private key file exists and permissions are sane

cr0x@server:~$ sudo ls -l /etc/opendkim/keys/example.com/selector1.private
-r-------- 1 opendkim opendkim 1704 Jan  4 10:12 /etc/opendkim/keys/example.com/selector1.private

Qué significa: El archivo existe, legible solo por el usuario/grupo opendkim. Bien.

Decisión: Si los permisos son incorrectos (legible por todos o no legible por opendkim), arréglalos y reinicia; las claves ilegibles pueden llevar a correos sin firmar o errores en tiempo de ejecución.

Task 11: Derive public key from the private key (prove whether DNS matches)

cr0x@server:~$ sudo openssl rsa -in /etc/opendkim/keys/example.com/selector1.private -pubout -outform PEM | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

Qué significa: Ahora tienes una huella estable de la clave pública derivada de la clave de firmado.

Decisión: Compárala con la material de clave que crees que está en DNS (tarea siguiente). Si difiere, tienes una incompatibilidad de clave, no un problema de “nombre de selector”.

Task 12: Extract the DNS public key and fingerprint it the same way

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com | tr -d '"' | sed 's/.*p=//' | tr -d ' ' | base64 -d 2>/dev/null | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

Qué significa: Si la suma coincide con la de la Tarea 11, DNS y clave privada coinciden. Si no, estás publicando la clave equivocada para ese selector.

Decisión: Publica la clave correcta o despliega la clave privada correcta. No “intentes reinicios al azar” hasta que las sumas coincidan.

Task 13: Check Postfix is actually sending through the DKIM milter

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
milter_protocol = 6
milter_default_action = accept

Qué significa: Postfix está configurado para usar un milter DKIM en localhost puerto 8891.

Decisión: Si estos están vacíos, o solo smtpd_milters está establecido, algunos caminos de correo (como envíos o reinyecciones) pueden evitar el firmado. Arregla la configuración para cubrir todos los flujos.

Task 14: Confirm the milter service is actually listening

cr0x@server:~$ sudo ss -ltnp | grep 8891
LISTEN 0      128        127.0.0.1:8891      0.0.0.0:*    users:(("opendkim",pid=2145,fd=6))

Qué significa: OpenDKIM está en ejecución y escuchando.

Decisión: Si no hay nada escuchando, reinicia OpenDKIM y revisa logs. Si OpenDKIM está caído, puede que veas correo sin firmar en vez de incompatibilidad de selector—síntoma distinto, solución distinta.

Task 15: Validate a selector exists when you’re rotating keys (list what’s published)

cr0x@server:~$ for s in selector1 selector2 prod2026; do echo "== $s =="; dig +noall +answer TXT ${s}._domainkey.example.com; done
== selector1 ==
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
== selector2 ==
== prod2026 ==

Qué significa: Solo selector1 existe en DNS; selector2/prod2026 no existen.

Decisión: No cambies el firmador a selector2/prod2026 hasta que DNS esté listo, a menos que disfrutes ver caer las gráficas de entregabilidad.

Broma #2: La propagación de DNS es la única parte de internet que todavía funciona con “¿probaste esperar?” como paso oficial de resolución.

Listas de comprobación / plan paso a paso

Lista de incidentes (15 minutos hasta estable)

1. Obtén un mensaje fallido reciente. No reenviado, no reenviado manualmente, no una captura de pantalla.
2. Extrae d= y s=. Esa es tu verdad de referencia.
3. Consulta DNS para ese selector y dominio. Usa tu resolutor y un resolutor público.
4. Si NXDOMAIN: publica el registro TXT que falta o revierte el firmador a un selector existente.
5. Si el registro existe: ejecuta opendkim-testkey (o el equivalente de tu firmador) desde el host que firma.
6. Si “key OK” localmente pero los receptores fallan: sospecha de visibilidad DNS, delegación o SERVFAIL intermitente a escala.
7. Comprueba la ruta de firmado: confirma que el correo pasa por la pasarela/milter esperada.
8. Confirma la alineación DMARC: una vez que DKIM pase, verifica que d= se alinee con el dominio From: para tu política.
9. Envía un canario. Verifica las cabeceras en el lado receptor y captura evidencia para el postmortem.

Lista de cambios (rotación segura de selector/clave sin drama)

1. Genera un nuevo par de claves. Usa un nombre de selector nuevo que no colisione (p. ej., s2026a).
2. Publica el nuevo selector en DNS primero. Espera a que sea visible externamente.
3. Despliega la clave privada a todos los firmadores. Confirma permisos y mapeo de configuración (SigningTable/KeyTable).
4. Cambia el firmado al nuevo selector. Recarga servicios, verifica con un correo canario.
5. Mantén publicado el selector antiguo. Al menos varios días; más tiempo si tienes flujos de correo retrasados o sistemas de archivado.
6. Elimina el selector antiguo solo tras la verificación. No limpies el mismo día. Así es como creas heisenbugs en el registro de cumplimiento.

Lista de diseño (hacer menos probable la incompatibilidad de selector)

• Un propietario para el firmado saliente. Si cinco equipos pueden cambiar DKIM, nadie se hace cargo de la entregabilidad.
• Centraliza los cambios de DNS con revisión de código. Los registros DKIM son configuración de producción, no un ticket de mesa de ayuda.
• Monitoreo canary desde fuera de tu red. Las comprobaciones internas pierden DNS de horizonte dividido y el comportamiento de resolutores externos.
• Registra el selector en tu runbook. No “DKIM está configurado”, sino “el selector es X; el procedimiento de rotación es Y.”

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “dkim=fail (no key for signature)”

Causa raíz: DNS no tiene el registro TXT para el selector en la cabecera del mensaje, o el receptor no puede resolverlo.

Solución: Publica el registro TXT <selector>._domainkey.<domain>. Verifica vía servidores autoritativos y resolutores públicos. Revisa TTLs de caché negativa si “aún falla” por unos minutos.

2) Síntoma: “dkim=fail (bad signature)” while DNS record exists

Causa raíz: La clave pública en DNS no coincide con la clave privada usada para firmar. A menudo causado por despliegue parcial, ruta de archivo errónea o rotar claves en un solo nodo.

Solución: Compara la huella de la clave pública derivada (Tareas 11–12). Re-despliega la clave correcta en todos lados o actualiza DNS para que coincida con la clave desplegada. Luego vuelve a probar con un mensaje nuevo.

3) Síntoma: DKIM pasa a veces, falla a veces

Causa raíz: Múltiples rutas salientes o múltiples firmadores con configuraciones inconsistentes; o fallos intermitentes de resolución DNS a escala de receptor (SERVFAIL, límites de tasa).

Solución: Correlaciona mensajes fallidos con IPs/hosts emisores; comprueba qué firmador añadió DKIM. Asegura que todos los nodos tengan configuración de selector/clave idéntica. Si es DNS, estabiliza TTLs y la fiabilidad del proveedor.

4) Síntoma: SPF pasa, DKIM pasa, pero DMARC falla

Causa raíz: Fallo de alineación: el dominio d= de DKIM no se alinea con el dominio visible From:, o el dominio mailfrom de SPF no se alinea.

Solución: Asegura que DKIM firme con d= que coincida (o sea un subdominio permitido por el modo de alineación DMARC) con el dominio From. No “arregles DMARC” debilitando la política salvo que realmente lo necesites.

5) Síntoma: Todo parece correcto internamente, los receptores externos todavía muestran selector ausente

Causa raíz: DNS de horizonte dividido, delegación rota, o cambios DNS aplicados solo a vistas internas.

Solución: Consulta servidores autoritativos y un resolutor público desde fuera de la red corporativa. Arregla registros de zona públicos y delegación. La autenticación de correo se juzga en internet público, no en tu VPN.

6) Síntoma: DKIM falla tras un cambio “menor” en infraestructura de correo

Causa raíz: El correo ahora está evitando el salto que firma (nueva ruta de relé, puerto de envío cambiado, nueva pasarela, ajustes de milter).

Solución: Traza la ruta del mensaje. Confirma que los milters se apliquen a todos los puntos de inyección (smtp y no-smtp). Valida que la cabecera DKIM-Signature esté presente y sea producida por el sistema esperado.

7) Síntoma: DKIM falla solo para un subdominio o una unidad de negocio

Causa raíz: Coincidencia de SigningTable: reglas firman @example.com pero no @alerts.example.com, o el firmador usa d=example.com mientras From es subdominio y la política exige alineación estricta.

Solución: Actualiza reglas de SigningTable; publica claves para el dominio correcto; confirma alineación con el modo DMARC (relaxed vs strict).

8) Síntoma: El receptor dice “key too short” o trata DKIM como débil

Causa raíz: Aún se usa clave de 1024 bits o configuración legacy.

Solución: Rota a claves de 2048 bits. Publica nuevo selector, despliega nueva clave, cambia el firmado y luego retira el selector antiguo. No intentes “editar” la clave antigua en sitio.

Preguntas frecuentes

1) ¿Qué es un selector DKIM, en términos sencillos?

Es el nombre de la clave. El selector indica a los receptores qué registro DNS recuperar para la clave pública usada para verificar la firma.
Un dominio puede tener múltiples selectores para poder rotar claves o permitir que diferentes sistemas firmen con claves distintas.

2) ¿Cómo encuentro el selector que usa mi sistema?

No adivines. Mira un mensaje real y lee la cabecera DKIM-Signature: s=....
Si el mensaje no tiene DKIM-Signature, tienes otro problema: el firmado no está ocurriendo.

3) ¿Por qué una incompatibilidad de selector suele aparecer como fallo DMARC?

DMARC requiere que SPF o DKIM pasen y se alineen con el dominio From.
Si DKIM falla por selector faltante o incompatibilidad de clave, y SPF no está alineado (común con remitentes terceros), DMARC falla.

4) ¿Puedo “simplemente cambiar el selector” en el firmador?

Sí, pero solo si DNS ya publica la clave de ese selector y el firmador tiene la clave privada correspondiente.
Cambiar primero el firmador es la forma más rápida de crear un incidente global de entregabilidad.

5) ¿Por qué veo dos selectores como selector1 y selector2 en algunas plataformas?

Muchos proveedores soportan rotación sin interrupciones manteniendo dos claves publicadas y alternando entre ellas.
La plataforma puede firmar con una mientras la otra está en preparación. Los humanos a menudo borran “la que no se usa” y causan fallos intermitentes.

6) ¿Cuánto tiempo debo mantener publicado un selector antiguo tras la rotación?

Más tiempo del que piensas. Al menos varios días es habitual; más si tienes colas retrasadas, reintentos, sistemas de reenvío o archivado por cumplimiento.
La verificación DKIM ocurre en el momento de la recepción, así que una entrega retrasada aún puede necesitar la clave pública antigua.

7) ¿Y si DNS se ve correcto desde mi portátil pero los receptores aún fallan?

Comprueba desde fuera de tu red y consulta servidores autoritativos directamente.
DNS de horizonte dividido, delegación rota y problemas del proveedor DNS se manifiestan como “aquí funciona” hasta que no.

8) ¿DKIM depende de la IP de envío como lo hace SPF?

No directamente. La verificación DKIM depende de la firma y la búsqueda DNS de la clave, no de la IP de envío.
Pero los receptores combinan señales: si la reputación de tu IP es mala, un fallo DKIM duele más.

9) ¿Una incompatibilidad de selector es lo mismo que “firma inválida”?

No. La incompatibilidad de selector suele significar “no se encontró clave para ese selector” (registro faltante o nombre equivocado).
“Firma inválida” normalmente significa que el registro existe pero la clave pública no verifica la firma (incompatibilidad de claves o mensaje modificado).

10) ¿Deberíamos automatizar la validación DKIM?

Sí. Un canario externo simple que capture cabeceras y alerte sobre cambios en DKIM/SPF/DMARC detectará problemas de selector antes que los clientes.
Este es uno de esos lugares donde el monitoreo aburrido vence a las heroicas acciones manuales.

Próximos pasos para evitar repetir el incidente

La incompatibilidad de selector DKIM es el tipo de fallo que hace quedar mal a equipos inteligentes, porque raramente es “difícil.”
Normalmente es solo configuración inconsistente entre DNS y firmadores, con suficientes partes móviles para ocultar el error.
La solución es rápida cuando tratas la cabecera del correo como la única fuente de verdad.

Haz esto ahora, mientras el dolor todavía está reciente:

1. Anota tus selectores en vivo por dominio y por sistema de envío.
2. Añade un canario externo que alerte sobre cambios en DKIM/SPF/DMARC.
3. Estandariza la rotación: publica el nuevo selector primero, luego despliega claves, luego cambia el firmado y finalmente retira claves antiguas más tarde.
4. Deja de improvisar nombres de selectores a menos que controles también la configuración del firmador de extremo a extremo.

La autenticación de correo no es glamurosa. Por eso se rompe.
Trata DKIM como infraestructura de producción, no como una casilla en un portal de proveedor, y la incompatibilidad de selector se convierte en una solución de dos minutos—una sola vez, no cada trimestre.