DKIM Record Checker es para un problema que se esconde a simple vista. Ingresa un nombre de dominio y un selector DKIM, y el verificador busca el registro DNS en selector._domainkey.domain . Desde allí lee el registro DKIM TXT, muestra la clave pública, examina las etiquetas del registro, verifica el tipo de clave y señala fallas comunes como datos faltantes, claves revocadas, longitudes RSA débiles, registros con formato incorrecto y selectores que existen más en el folclore corporativo que en la realidad del DNS. En lenguaje corriente, responde a una pregunta contundente: si su dominio afirma firmar el correo electrónico, ¿hay realmente una clave pública válida esperando en el DNS, o toda la configuración es una mentira ceremonial más contada por los paneles de control?

Para alguien que no vive dentro de los sistemas de correo, la versión simple es simple. Un dominio es el nombre legible, como ejemplo.com . DNS, el Sistema de nombres de dominio , es el sistema de búsqueda distribuida que almacena registros técnicos con ese nombre. DKIM es Correo identificado con claves de dominio . Las cartas no son místicas. Son una etiqueta para un sistema de firma de correo que utiliza un nombre de dominio, un par de claves criptográficas y claves públicas publicadas en DNS para permitir que un sistema de correo receptor verifique que un mensaje fue firmado por alguien que posee la clave privada correspondiente. Eso no significa que el mensaje sea moralmente puro, sabio o agradable. Significa que un firmante asociado al dominio asumió la responsabilidad de él de una manera que se puede verificar.

El nombre es inusualmente revelador si te molestas en leerlo en lugar de hojearlo con los ojos vidriosos de una persona ya traumatizada por el DNS. Dominio significa que el sistema está anclado a un nombre de dominio en lugar de a un certificado personal para cada ser humano en la tierra. Claves significa que está involucrada la criptografía de clave pública. Se utiliza una clave privada para firmar y una clave pública publicada para que otros puedan verificar. Identificado significa que el objetivo no es simplemente ocultar contenido en humo cifrado; el punto es vincular una identidad de firma responsable al mensaje. Mail significa exactamente eso: correo electrónico, el viejo medio global que pasó décadas siendo absurdamente confiable y luego tuvo que inventar capa tras capa de sospecha técnica una vez que el mundo descubrió el spam, la suplantación de identidad, el phishing y la escala.

El camino histórico importa porque DKIM no apareció de la nada. Antes de que DKIM se convirtiera en el estándar, existían DomainKeys , descritas en RFC 4870 como "Autenticación de correo electrónico basada en dominio utilizando claves públicas anunciadas en el DNS". Incluso el título suena a un ingeniero carraspeando antes de introducir un mecanismo con toda la calidez de una herramienta de precisión. DomainKeys fue uno de los primeros marcos de autenticación de correo electrónico a nivel de dominio que utilizaba claves públicas en DNS. DKIM, estandarizado en RFC 4871 y posteriormente revisado en RFC 6376, llevaba esa ascendencia directamente en su propio nombre. Fue creado para permitir que una persona, función u organización propietaria del dominio de firma reclame la responsabilidad de un mensaje y verifique ese reclamo a través de una firma criptográfica y una búsqueda de DNS para la clave pública.

Esa palabra responsabilidad es importante. DKIM no es un halo. No es un certificado moral. No es Internet declarando, con lágrimas en los ojos, que el mensaje vino de santos. La descripción general del servicio DKIM es muy clara: DKIM tiene un trabajo restringido. Proporciona a los sistemas de correo un identificador verificable asociado con el mensaje para que puedan tomar decisiones posteriores. Por sí solo, DKIM no le dice al receptor exactamente qué acción tomar, no prueba por sí solo que cada encabezado visible significa lo que una persona normal supone que significa y no detiene mágicamente la reproducción después de una verificación exitosa. En otras palabras, DKIM es útil porque es específico. La gente se mete en problemas cuando piden que sea toda una filosofía de confianza.

La razón por la que DKIM utiliza DNS para la distribución de claves es muy práctica. La descripción general del servicio explica que el uso de DNS evitó la necesidad de inventar una infraestructura de consulta global completamente nueva. Esa fue una decisión muy propia de Internet: ya existe un gran sistema de nombres distribuido y operado globalmente, así que utilícelo en lugar de crear una gran catedral más de ambición técnica. DNS ya sabía cómo distribuir registros a escala. DKIM simplemente almacenó allí el material de verificación pública. Sensible, eficiente y naturalmente destinado a ser incomprendido por generaciones de administradores que luego copiarían fragmentos de DNS de artículos de ayuda sin leer lo que estaban pegando.

Eso nos lleva a una de las ideas más útiles en DKIM: el selector . Un selector no está ahí para hacer la vida interesante. Existe porque un dominio puede tener múltiples claves de firma y múltiples acuerdos de firma. El selector permite que el sistema de firma apunte a la clave pública correcta sin tener que juntar todas las claves en una triste pila. RFC 5585 explica que el selector se combina con el identificador del dominio de firma para que el verificador sepa qué clave recuperar. RFC 6376 va más allá y señala que los selectores ayudan con la rotación de claves, la delegación e incluso la denominación jerárquica, porque los puntos dentro de los selectores definen los límites de las etiquetas DNS. En lenguaje sencillo, el selector es la subetiqueta que dice: "Utilice esta clave, no aquella". Es la versión de etiquetado de cajones de la infraestructura de correo, lo que suena humilde hasta que se ve lo que sucede cuando nadie etiqueta los cajones.

La parte fija ._domainkey también tiene una razón. RFC 6376 dice que todas las claves DKIM se almacenan en un subdominio llamado _domainkey . Entonces, si el dominio de firma es ejemplo.com y el selector es newsletter , la consulta DNS va a newsletter._domainkey.example.com . Esa regla de nomenclatura crea orden. El selector elige la clave. El subdominio _domainkey dice qué tipo de datos se encuentran allí. El dominio base vincula todo al espacio de nombres del firmante. Sin esa estructura, el DNS se convertiría en una búsqueda del tesoro aún mayor de lo que ya es.

Dentro del propio registro DKIM, las etiquetas no son decoración aleatoria. v=DKIM1 declara la versión del registro. p= lleva los datos de clave pública. k= identifica el tipo de clave, históricamente con mayor frecuencia RSA. Algunas otras etiquetas restringen el uso del servicio, anuncian indicadores o describen un comportamiento hash aceptable. Un valor p= vacío tiene un significado particularmente seco e importante en RFC 6376: significa que la clave ha sido revocada. Ése es uno de esos detalles que el mundo de las normas maneja con absoluta eficiencia. Sin fuegos artificiales. Ninguna despedida dramática. Simplemente vacíe los datos clave y se espera que el verificador los trate como un error.

Un buen verificador DKIM también debe preocuparse por la criptografía, porque la clave pública no es un papel tapiz decorativo. DKIM comenzó en un mundo donde RSA era el método de firma estándar y RFC 6376 todavía refleja esa época. Posteriormente, RFC 8301 actualizó la guía criptográfica DKIM, declarando obsoleto a rsa-sha1 y exigiendo a los firmantes que utilicen claves RSA de al menos 1024 bits, aunque señaló que las claves de menos de 2048 bits pueden ser vulnerables a ataques fuera de línea. Ése es el lenguaje estándar para decir “la vieja manta reconfortante se está adelgazando”. Luego, RFC 8463 agregó la firma DKIM basada en Ed25519, que trajo claves más cortas para niveles de seguridad similares. Entonces, cuando un inspector mira una clave DKIM hoy en día, no debería simplemente anunciar "registro encontrado" como un golden retriever que porta con orgullo un palo. Debería preguntarse qué tipo de clave es, si la clave se puede analizar y si el tamaño pertenece a la realidad actual y no a un museo de optimismo criptográfico.

Hay un contraste casi cómico en el centro de DKIM. El concepto es claro: firmar los encabezados seleccionados y el contenido del cuerpo, publicar la clave pública en DNS y dejar que los receptores verifiquen. La realidad operativa es menos poética. Se olvida la rotación de claves. Se acumulan viejos selectores. Los proveedores piden a los administradores que publiquen un selector más, un remitente subcontratado más, un registro DNS supuestamente inofensivo más. Años más tarde, la organización tiene un pequeño cementerio de selectores obsoletos bajo _domainkey , algunos activos, otros abandonados, algunos medio documentados y uno que todos temen eliminar porque aún podría alimentar un sistema de facturación que nadie ha tocado desde una reorganización administrativa hace tres logotipos. Por eso comprobar los registros DKIM no es higiene académica. Es arqueología de infraestructuras con consecuencias.

Vale la pena decir claramente la lección más importante. Los sistemas de autenticación de correo electrónico existen porque Internet se volvió demasiado grande y demasiado hostil para confiar únicamente en la postura. DKIM es una respuesta a esa realidad. Permite que un firmante asociado a un dominio adjunte una firma criptográfica al correo y permite a los receptores validar la clave pública asociada a través de DNS. No resuelve todos los problemas de confianza. No reemplaza el juicio. No rescata de sus propios hábitos una operación de correo mal administrada. Pero sí proporciona una declaración técnica verificable que se puede verificar en lugar de simplemente creer. En la Internet moderna, eso cuenta como progreso.

Entonces, ¿qué debería decirle realmente un verificador de registros DKIM serio? Si el host selector existe. Si existe un registro v=DKIM1 adecuado. Si la clave pública está presente, es decodificable y plausible. Si la clave aparece revocada. Si el registro anuncia banderas o restricciones de servicio que importan. Si la criptografía parece lo suficientemente actual como para ser respetable. Y, quizás lo más importante, si la historia de firma de correo de su dominio se basa en una clave publicada real o en el tipo de ilusión administrativa que tiende a colapsar en el momento en que un servidor receptor solicita pruebas.