# Qué es DKIM: el estándar de autenticación de email explicado URL: https://notificationharbor.com/es/journal/que-es-dkim Type: blog Locale: es Published: 2026-09-08 Updated: 2026-09-09 --- > DKIM adjunta una firma RSA a cada email saliente. El MTA receptor verifica la firma contra tu clave pública publicada en el DNS antes de decidir dónde aterriza el mensaje. DKIM (DomainKeys Identified Mail) es un protocolo criptográfico de autenticación de email. Qué es DKIM en términos prácticos: adjunta una firma RSA a cada mensaje saliente que envía tu servidor de correo. El MTA receptor recupera tu clave pública del DNS, verifica esa firma y reporta el resultado como `dkim=pass` o `dkim=fail`. Ese resultado alimenta el modelo de reputación de tu dominio y determina si se mantiene la alineación DMARC. Sin una firma válida, el MTA receptor no tiene confirmación criptográfica de que el mensaje provino de tu infraestructura. ## DKIM es un protocolo de firma, no un filtro El nombre invita a un error frecuente. DKIM no bloquea el email. No pone en cuarentena los mensajes ni aplica ninguna política por sí solo. Lo que hace es estampar cada mensaje saliente con una afirmación verificable: este mensaje fue firmado por el dominio en el campo `d=`, usando la clave privada correspondiente al selector `s=`. El MTA receptor toma esa afirmación, construye una consulta DNS a `._domainkey.`, recupera el registro TXT que contiene la clave pública y ejecuta la verificación criptográfica. Si la verificación pasa, el encabezado de resultados de autenticación muestra `dkim=pass`. Si falla, ves `dkim=fail` o `dkim=temperror`. Ninguno de estos resultados causa un rechazo por sí solo. La señal alimenta el modelo de reputación del servidor receptor y, fundamentalmente, la evaluación DMARC. El trabajo de DKIM es producir un resultado verificable, no actuar sobre él. ## Qué firma DKIM y qué cubre la firma DKIM firma dos cosas: encabezados de mensaje seleccionados y el cuerpo del mensaje. El algoritmo de firma hashea ambos y almacena el resultado en el campo de encabezado `DKIM-Signature`. La lista de encabezados está controlada por el tag `h=` en la firma. Una configuración de producción típica incluye `from:subject:date:message-id:content-type`. El encabezado `from` es el campo que importa para la alineación DMARC. El hash del cuerpo cubre el cuerpo completo del mensaje, canonicalizado mediante canonicalización `simple` o `relaxed`. La canonicalización `relaxed` es la que usa la mayoría de las stacks de producción. Normaliza los espacios en blanco antes del hashing, lo que permite que la firma sobreviva a un reformateo menor por parte de los MTA de relay. La canonicalización `simple` es más estricta: un único cambio de espacio en blanco al final rompe la firma. Verás `c=relaxed/relaxed` en el encabezado `DKIM-Signature` de prácticamente cualquier ESP bien configurado. Lo que DKIM no firma: el remitente del sobre SMTP, los encabezados de enrutamiento como `Received`, y cualquier encabezado fuera de la lista `h=`. Esto es intencional. Firmar el sobre rompería los escenarios de reenvío, que es donde proviene la ventaja de DKIM sobre SPF. ![Dos sobres digitales asegurados con candado que representan un email firmado con DKIM en tránsito](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/95ba5d-img-2.webp) ## El selector: un handle de control de acceso que la mayoría de los equipos trata como una etiqueta El selector es la parte de DKIM que la mayoría de los equipos subestima hasta que necesitan rotar claves bajo presión. El campo `s=` en tu DKIM-Signature apunta a una clave pública específica en tu DNS. El formato de lookup es `._domainkey.`. Si tu selector es `mail2026` y tu dominio es `example.com`, el resolver busca un registro TXT en `mail2026._domainkey.example.com`. Un dominio puede tener múltiples selectores activos simultáneamente. Cada servicio de envío, cada ESP, cada MTA interno debería usar su propio selector. Esto te da tres capacidades operacionales concretas: - Rotación de clave independiente por servicio sin tocar otros remitentes. - Atribución trazable en los logs de autenticación: el selector te dice qué clave de firma se usó en cada mensaje. - Offboarding limpio: elimina el registro DNS del selector y ese ESP ya no puede firmar como tu dominio independientemente de lo que haga en su extremo. A l'usage, voilà ce qu'on observe dans les traces: los equipos que configuran un selector compartido en todos sus servicios de envío no pueden revocar el acceso a un remitente sin interrumpir todos los demás. El selector no es cosmético. Es un handle de control de acceso. ![Terminal mostrando registros DNS TXT para la configuración de un selector DKIM](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/02b314-img-3.webp) ## DKIM y alineación DMARC: cómo funciona realmente la capa de aplicación Que DKIM pase es un requisito previo para un tipo específico de éxito DMARC denominado alineación DKIM. DMARC requiere al menos una de dos condiciones de alineación: alineación SPF o alineación DKIM. La alineación DKIM significa que el dominio en el encabezado `From:` coincide con el valor `d=` en la firma DKIM, y la firma se verifica. Cuando ambas condiciones se cumplen, DMARC considera el mensaje autenticado. Por eso DKIM es la señal de autenticación más duradera. La alineación SPF se rompe con el reenvío: cuando se reenvía un mensaje, el remitente del sobre SMTP cambia, y la evaluación SPF falla contra la nueva IP de envío. La alineación DKIM sobrevive al reenvío porque la firma y el encabezado `From:` viajan con el cuerpo del mensaje y no son reescritos por los MTA de relay, asumiendo que el cuerpo no se modifica en tránsito. Para dominios con una política DMARC `p=reject`, un mensaje que falla tanto la alineación SPF como la DKIM es rechazado por el MTA receptor. Ese es el mecanismo que impide que los emails falsificados de tu dominio lleguen a las bandejas de entrada a escala. DKIM no es la última línea de defensa aquí. Pero es la línea que se mantiene cuando el reenvío está en el camino. Desde 2024, Google, Yahoo y Microsoft [exigen DKIM para remitentes masivos](https://support.google.com/mail/answer/81126) que envíen 5.000 o más mensajes por día a sus MX. Los mensajes de dominios no firmados se enrutan al spam o se rechazan por defecto. Ce n'est pas une feature marketing. C'est une contrainte d'infrastructure. ## Longitud de clave y rotación: decisiones prácticas para 2026 La mayoría de las implementaciones DKIM usan RSA-SHA256. La pregunta clave es la longitud de la clave. Las claves RSA de 1024 bits todavía aparecen en configuraciones heredadas. El [NIST deprecó RSA de 1024 bits para la mayoría de los casos de uso en 2015](https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final). Una clave de 2048 bits proporciona un margen significativamente mayor y está soportada por todos los principales MTA y proveedores de recepción. Si estás generando una nueva clave hoy, usa 2048 bits. Algunos equipos han migrado su clave de firma activa a 2048 bits pero dejaron selectores antiguos de 1024 bits publicados en DNS porque nadie auditó el inventario. Trois signaux qui changent le comportement du moteur: si ves `k=rsa` con una clave de 1024 bits en un selector antiguo, ese selector es una vulnerabilidad incluso si tu infraestructura de firma actual ya ha avanzado. Un selector válido pero deprecado es explotable. Calendario de rotación de claves: la mayoría de los equipos de infraestructura rotan anualmente, algunos trimestralmente para dominios de mayor sensibilidad. La secuencia importa: - Generar un nuevo par de claves. - Publicar la nueva clave pública bajo un nuevo nombre de selector en DNS. - Esperar la propagación TTL, típicamente 24 a 48 horas para registros con un TTL bajo. - Cambiar la clave de firma en la configuración de tu MTA al nuevo selector. - Verificar `dkim=pass` en mensajes salientes mediante una herramienta de prueba de email o inspeccionando los encabezados de resultados de autenticación en un mensaje de prueba. - Después de confirmar que la nueva clave está activa y firmando correctamente, eliminar el registro DNS antiguo. La rotación no es disruptiva si sigues el orden: DNS primero, cambio de clave segundo, eliminación del registro antiguo al final. Invertir los pasos 4 y 6 provoca una ventana de `dkim=fail`. ## Señales operacionales a monitorear después de configurar DKIM DKIM no es una tarea de configuración única. Las siguientes señales indican que algo ha derivado o se ha roto. **`dkim=temperror` en encabezados recibidos.** Los fallos temporales generalmente indican problemas de búsqueda DNS en el lado receptor, o un desfase TTL durante la rotación de claves. Si ves esto en mensajes salientes poco después de una rotación de clave, espera la propagación completa antes de concluir que la clave en sí está mal configurada. **`dkim=fail` en mensajes que enviaste.** La modificación del cuerpo por un relay intermedio es la causa más común. Comprueba si hay un salto de reenvío, un procesador de listas de correo, o un relay que inyecta pie de página en la ruta de entrega. Si el fallo es constante en un único flujo, mapea la cadena de relay salto por salto. **Encabezado `DKIM-Signature` completamente ausente.** El daemon de firma en tu MTA no está en ejecución, la ruta de la clave de firma es incorrecta, o el mapeo dominio-selector está mal configurado en la configuración de tu MTA. Esto es una interrupción completa de DKIM para los flujos de mensajes afectados. **Registro TXT del selector ausente del DNS.** La zona DNS fue editada o migrada sin preservar el registro del selector DKIM. Verifica con `dig TXT ._domainkey.` desde un resolver externo. En una configuración de envío multi-región, los resultados DKIM inconsistentes entre nodos son frecuentemente causados por nodos que usan diferentes configuraciones de selector. Confirma que la configuración de la clave de firma está sincronizada en todos los nodos de envío antes de implementar una rotación. ## Lo que DKIM no protege DKIM no es un filtro anti-spam. Un remitente puede registrar un nuevo dominio, configurar DKIM válido y enviar spam completamente autenticado. La firma se verifica correctamente. La autenticación confirma el origen, no la intención o la calidad del contenido. DKIM tampoco aborda la suplantación de nombre de visualización, donde el encabezado `From:` muestra un nombre de confianza como "Equipo de Nómina" emparejado con un dominio controlado por un atacante. La verificación criptográfica opera sobre el dominio, no sobre la presentación visual en el MUA. La mayoría del phishing a nivel MUA depende del engaño por nombre de visualización en lugar de la suplantación del dominio exacto. Lo que DKIM sí protege: la suplantación de dominio exacto, donde un atacante intenta enviar desde tu dominio sin poseer tu clave privada. Combinado con una política DMARC `p=reject` que aplica la alineación DKIM, esto evita que esa clase de mensaje falsificado llegue a las bandejas de entrada en los proveedores receptores que aplican DMARC. En términos prácticos: DKIM solo no es suficiente. El modelo de protección requiere la aplicación de la política DMARC por parte del MTA receptor. DKIM es la capa de autenticación que hace significativo a DMARC. SPF es la otra capa de autenticación, y maneja la verificación del remitente del sobre. Los tres funcionan juntos. La ausencia de cualquiera de ellos deja una brecha en la cadena de aplicación. Si ya has configurado DKIM y SPF pero aún no has publicado un registro DMARC, las firmas existen pero no hay ninguna política de aplicación activa. El modo de monitoreo (`p=none` con informes `rua`) es un primer paso razonable: obtienes informes agregados que muestran las tasas de éxito de autenticación en tu dominio de envío antes de comprometerte con `p=quarantine` o `p=reject`. ## FAQ ### ¿Qué es DKIM y cómo funciona? DKIM (DomainKeys Identified Mail) es un protocolo criptográfico de autenticación de email. Tu servidor de envío firma cada mensaje saliente con una clave RSA privada y adjunta la firma en un encabezado DKIM-Signature. El MTA receptor consulta tu DNS para obtener la clave pública correspondiente bajo el subdominio del selector, verifica la firma y reporta dkim=pass o dkim=fail. Ese resultado alimenta el scoring de reputación y la evaluación DMARC. ### ¿Contra qué protege DKIM? DKIM protege contra la suplantación de dominio exacto: un atacante que intenta enviar desde tu dominio sin poseer tu clave de firma privada. Combinado con una política DMARC p=reject y alineación DKIM, evita que esa clase de mensaje falsificado alcance las bandejas de entrada. No protege contra la suplantación de nombre de visualización, el spam de dominios legítimamente autenticados, ni el phishing basado en contenido desde un dominio válido controlado por el atacante. ### ¿Qué es un selector DKIM y por qué importa? Un selector DKIM es una etiqueta en el encabezado DKIM-Signature (el campo s=) que indica al MTA receptor qué clave pública buscar en el DNS. El formato de consulta DNS es selector._domainkey.tudominio.com. Múltiples selectores pueden coexistir en un único dominio, cada uno apuntando a una clave pública diferente. Esto permite rotación de clave independiente por servicio de envío y revocación limpia: elimina el registro DNS del selector y ese remitente ya no puede firmar como tu dominio. ### ¿Con qué frecuencia se deben rotar las claves DKIM? La mayoría de los equipos de producción rotan las claves DKIM anualmente. La secuencia segura es: publicar la nueva clave pública bajo un nuevo selector en DNS, esperar la propagación TTL (24 a 48 horas), cambiar la clave de firma en tu MTA al nuevo selector, verificar dkim=pass en mensajes salientes de prueba, y luego eliminar el registro DNS antiguo. Eliminar el registro antiguo antes de confirmar que la nueva clave está activa crea una ventana de dkim=fail. ### ¿DKIM sobrevive al reenvío de email? Sí, a diferencia de SPF. Cuando se reenvía un mensaje, el remitente del sobre SMTP cambia y la alineación SPF falla contra la nueva IP de envío. La alineación DKIM sobrevive al reenvío porque la firma viaja con los encabezados y el cuerpo del mensaje y no es reescrita por los MTA de relay, siempre que el cuerpo del mensaje no se modifique en tránsito. Esto hace de DKIM la señal de autenticación más fiable para la aplicación de la política DMARC en emails reenviados. ### ¿Qué longitud de clave DKIM usar en 2026? Usa claves RSA de 2048 bits. El NIST deprecó RSA de 1024 bits para la mayoría de los casos de uso en 2015, y las claves de 1024 bits presentan un riesgo calculable a los costos de cómputo actuales. Todos los principales MTA y proveedores de recepción soportan claves de 2048 bits. Si tienes selectores de 1024 bits publicados en DNS, audítalos: un selector válido pero deprecado es una exposición de seguridad aunque tu infraestructura de firma actual ya use claves más largas. ### ¿Cuál es la diferencia entre DKIM, SPF y DMARC? SPF autentica el dominio del remitente del sobre SMTP verificando si la IP de envío está listada en el DNS de ese dominio como autorizada. DKIM autentica el mensaje en sí mediante una firma criptográfica sobre encabezados y cuerpo. DMARC usa los resultados de alineación SPF y DKIM para aplicar una política definida por el propietario del dominio: none, quarantine o reject. SPF falla en el reenvío; DKIM generalmente sobrevive. DMARC requiere que al menos una alineación pase antes de aplicar su política.