guía · configuración de dkim

¿Cómo debe implementar un equipo de producto la configuración de DKIM de forma segura?

Para configurar DKIM, elija un dominio de firma que pertenezca a la organización y un selector único para cada proveedor o sistema de firma, genere el par de claves en un servicio protegido, publique solo la clave pública en selector._domainkey.example.com y configure la ruta de salida real para que firme cada mensaje previsto. Verifique la firma con los bytes originales del mensaje recibido en un buzón externo, confirme que el dominio d= se alinea con el dominio From visible cuando DMARC dependa de él y luego despliegue de forma gradual. Documente la responsabilidad de cada selector, la rotación, la revocación y la reversión antes de mover el tráfico de producción.

Mapee cada ruta de salida real antes de generar una clave

Empiece por un inventario, no por un registro DNS. Enumere cada sistema que pueda emitir correo usando los dominios From visibles de la organización: workers de aplicaciones, proveedores transaccionales, plataformas de marketing, herramientas de soporte, sistemas de identidad, software de tickets, relays y rutas de emergencia. Para cada uno, registre su propietario, clases de mensajes, remitente del sobre, dominio From visible, dominio DKIM d= actual, selector, componente de firma y si otro relay modifica el mensaje posteriormente. Una clave DKIM publicada para un proveedor no hace nada para una ruta diferente que nunca usa su clave privada. De igual forma, un panel genérico de proveedor que muestra un dominio verificado no demuestra que cada tenant, región, flujo, plantilla o alternativa esté firmado. Use muestras controladas de cada ruta y conserve sus encabezados originales. Decida qué rutas están autorizadas antes de habilitar la firma; DKIM autentica la responsabilidad de un dominio por una firma, no el consentimiento del destinatario ni la veracidad del contenido del mensaje.

Elija un dominio de firma que admita la alineación DMARC

La etiqueta d= de DKIM identifica el dominio de firma. Elija un dominio que la organización controle y pueda gobernar durante toda la vida del flujo de correo. Cuando DMARC vaya a depender de DKIM, el dominio d= debe alinearse con el dominio del campo From visible del RFC 5322 según la regla de alineación relajada o estricta que corresponda. Un dominio de firma propiedad del proveedor puede producir un resultado DKIM válido y, aun así, no alinearse con el dominio From de la organización. Decida si cada flujo debe firmarlo el dominio raíz o un subdominio con un propósito específico, teniendo en cuenta la responsabilidad, la separación de reputación, el DNS delegado y el aislamiento de incidentes. No invente dominios adicionales solo para eludir un problema de reputación o de política. Documente la relación con el dominio organizativo y el modo DMARC previsto. Pruebe la alineación a partir de los encabezados finales recibidos; nunca la deduzca solo de la consulta de un selector, porque el mensaje podría usar otro valor d=.

Asigne los selectores como identidades operativas

Un selector permite a un dominio publicar varias claves y cambiarlas sin reemplazar un registro global. Cree una política de selectores determinista que identifique un proveedor o firmante y una generación de rotación sin revelar secretos. Por ejemplo, product-a-2026q3 puede ser más claro que default, pero mantenga los nombres dentro de las convenciones de DNS y los límites de sus herramientas. Nunca reutilice una clave privada entre proveedores, entornos o tenants no relacionados solo para reducir registros DNS. Mantenga un registro con el selector, dominio d=, propósito, servicio de firma, propietario, hora de creación, algoritmo, huella digital de la clave pública, estado de despliegue, plazo de rotación y evidencia de retirada. Compruebe el nombre exacto del selector antes de publicarlo: la consulta es `selector._domainkey.signing-domain`. Un registro accidental en el dominio From visible, el dominio return-path o la zona DNS incorrecta no verificará la firma prevista. Evite eliminar un selector antiguo hasta que el correo retrasado y los reintentos firmados con él hayan caducado.

Genere y proteja la clave privada

Genere el par de claves dentro de un servicio de claves administrado o de un sistema de firma estrictamente controlado, cuando el proveedor lo admita. La clave privada nunca debe llegar al DNS público, al control de versiones, al código del navegador, a la salida de CI, a la analítica, a los logs habituales, a tickets, documentos, prompts ni chats compartidos. Conceda acceso de firma solo al componente de correo que necesita la clave, separe producción de los entornos inferiores y registre el acceso administrativo. El RFC 8301 actualiza los requisitos criptográficos de DKIM e indica que los firmantes deben usar claves RSA de al menos 1024 bits y deberían usar al menos 2048 bits; también señala las restricciones operativas del DNS para las claves más grandes. Use las capacidades y recomendaciones actuales del firmante elegido y de la población de receptores, en lugar de copiar un ejemplo obsoleto. Si se considera Ed25519, el RFC 8463 define su uso en DKIM, pero hay que probar la interoperabilidad y mantener una estrategia de firma compatible donde sea necesario. Debe ser posible rotar sin exportar la clave privada.

Publique la clave pública con precisión

Publique un registro TXT en el nombre de propietario exacto `selector._domainkey.signing-domain`. El registro de clave DKIM contiene etiquetas como v=DKIM1, un tipo de clave cuando sea necesario y p= con el material de la clave pública sin envolturas de clave privada. Siga el formato exacto de registro del firmante y el comportamiento de comillas de su proveedor de DNS. Antes de guardar, compruebe si la interfaz de DNS agrega automáticamente la zona, divide cadenas largas o escapa caracteres. Consulte directamente los servidores de nombres autoritativos tras la publicación y luego consulte resolvedores recursivos independientes y reconstruya el valor TXT completo. Varias cadenas de caracteres en un registro TXT se concatenan mediante clientes DNS, mientras que varios registros de recursos en competencia pueden generar ambigüedad. Conserve la respuesta anterior y el TTL para una reversión. No reduzca la seguridad publicando una clave más amplia ni dejando una marca de prueba en producción solo para silenciar un verificador. Un registro visible demuestra la publicación en DNS, no que el remitente use la clave privada correspondiente.

Configure el firmante final y los campos firmados

Configure el componente que entrega el mensaje final al transporte de salida, o asegúrese de que ningún componente posterior cambie el contenido firmado. Una firma DKIM cubre un hash del cuerpo y los campos de encabezado nombrados en h=. El RFC 6376 exige que el campo de encabezado From esté firmado para que la firma sea válida. Incluya los encabezados críticos para la identidad que correspondan al producto, entienda cómo se seleccionan los encabezados repetidos y evite firmar campos que un sistema posterior necesario deba reescribir, salvo que esa transformación esté controlada. Elija la canonicalización de forma deliberada. La canonicalización relajada tolera ciertos cambios definidos de espacios en blanco y de formato de encabezados, pero no permite ediciones arbitrarias del cuerpo. La canonicalización simple es más frágil. Insertar pies de página, reescribir enlaces, cambiar los límites MIME, convertir la codificación de transferencia, agregar etiquetas al asunto o normalizar los finales de línea después de firmar puede romper la verificación. Firme el mensaje completamente renderizado después de las transformaciones aprobadas y evite que usuarios no confiables elijan d=, s=, las listas de encabezados o las claves.

Verifique de extremo a extremo los mensajes originales recibidos

Envíe mensajes controlados por cada ruta real con forma de producción a buzones de prueba externos que opere el equipo. Conserve el mensaje original sin procesar, no un cuerpo copiado ni un adjunto de ticket reserializado. Revise los valores d= y s= de DKIM-Signature, la lista de encabezados firmados, el hash del cuerpo, el algoritmo, la canonicalización, la marca de tiempo y cualquier vencimiento. Consulte la clave pública desde una red independiente y ejecute un verificador que respete los estándares sobre los bytes originales. Compare el encabezado Authentication-Results del receptor de confianza con su verificador, respetando los límites de confianza del RFC 8601. Pruebe texto sin formato, multipart alternative, los adjuntos previstos, asuntos Unicode, encabezados largos, plantillas, transformaciones de seguimiento, reintentos y rutas por relay. Las pruebas negativas deben incluir un encabezado firmado modificado a propósito en un fixture, un selector inexistente, un selector vencido o retirado y una ruta que omita la firma. Nunca altere correo real de clientes para crear una prueba.

Evalúe DKIM, DMARC y la entrega como resultados separados

Un resultado DKIM pass significa que el verificador encontró una firma válida para el dominio de firma identificado sobre los campos y el cuerpo firmados. No autentica cada encabezado sin firmar, confirma un autor humano, demuestra el consentimiento del destinatario, establece el cumplimiento legal ni garantiza la aceptación o la llegada a la bandeja de entrada. DMARC evalúa por separado si un dominio DKIM o SPF aprobado se alinea con el dominio From visible y aplica la política del propietario del dominio. Registre al menos el resultado y motivo de DKIM, el dominio d=, el selector, el dominio From visible, el resultado de alineación, el resultado de SPF, el resultado de DMARC, el receptor y la marca de tiempo de las pruebas controladas. Mantenga las direcciones completas de destinatarios y el contenido fuera de las métricas rutinarias. La aceptación por parte del proveedor SMTP, la aceptación por parte del servidor receptor, el rebote posterior, la ubicación en carpetas del buzón y la interacción son estados posteriores. Si DKIM pasa pero el correo se rechaza o se filtra, investigue la alineación DMARC, SPF, la reputación de IP y dominio, la tasa de quejas, la política de mensajes, la tasa y la guía del receptor en lugar de rotar claves repetidamente.

Rote sin crear una brecha de verificación

Use selectores superpuestos. Primero genere una nueva clave protegida y publique su registro público con un selector nuevo. Verifique el DNS autoritativo y recursivo, configure el firmante para usar el nuevo selector y envíe pruebas controladas por cada ruta. Supervise la proporción de firmas que usan el selector anterior y el nuevo, y sus resultados de verificación. Mantenga disponible la clave pública anterior durante la antigüedad máxima de los mensajes en cola, la ventana de reintentos y el periodo de caché del DNS, más un margen de seguridad explícito. Después, detenga toda firma con el selector anterior, confirme que ninguna configuración activa lo referencia y retire su registro según la política. Una revocación de emergencia tras la exposición de la clave privada puede exigir una eliminación más rápida, pausar el tráfico, rotar las credenciales del proveedor y comunicar el incidente; documente ese compromiso de antemano. No sobrescriba un selector en el mismo lugar durante una rotación rutinaria, porque las claves públicas antiguas en caché pueden hacer fallar la verificación de los mensajes firmados con la nueva clave privada.

Diagnostique los fallos desde la firma hacia afuera

Si falta la firma, identifique si el mensaje usó un flujo sin firmar, un dominio From no autorizado, un relay alternativo o una ruta de plantilla. Si no se encuentra la clave, compruebe la consulta exacta de s= y d=, la delegación de la zona, la respuesta autoritativa, los errores de DNSSEC o del resolvedor y la propagación. Si hay una discrepancia en el hash del cuerpo, compare el MIME sin procesar previo a la firma con el recibido para encontrar las transformaciones posteriores a la firma. Si la firma no coincide, verifique que la clave pública publicada corresponde a la clave privada activa y revise la canonicalización y los encabezados firmados. Si DKIM pasa y DMARC falla, evalúe la alineación con el dominio From visible. Clasifique los errores temporales de consulta DNS por separado de los fallos de configuración persistentes, y use reintentos de transporte acotados solo cuando la respuesta SMTP sea transitoria. Pause el flujo afectado si detecta firmas entre dominios, claves desconocidas, fallos de verificación generalizados o una posible exposición de la clave. Conserve evidencia con la mínima información personal y cambie una sola variable en cada nueva prueba controlada.

Use la documentación DKIM de su sistema de envío

Configure DKIM en los sistemas de envío y la autoridad DNS reales, valide los mensajes recibidos originales y confíe en los estándares actuales de IETF y la documentación específica de cada proveedor.

Preguntas frecuentes

¿Dónde se publica una clave pública DKIM?

Publíquela como un registro TXT en selector._domainkey.dominio-de-firma, con el selector y el dominio d= exactos que contendrá la firma de salida.

¿Hay que poner la clave privada DKIM en el DNS?

No. El DNS contiene solo material de clave pública. Mantenga la clave privada dentro de un firmante administrado o de un límite de secretos, con acceso de alcance limitado y controles de rotación.

¿Se puede reutilizar un selector DKIM para todos los proveedores de correo?

Evite ese diseño. Separe selectores y claves privadas por proveedor, firmante, entorno o límite de riesgo, para que una rotación o un compromiso no afecten a rutas no relacionadas.

¿Si DKIM pasa, DMARC también pasa?

No necesariamente. DMARC exige que el dominio d= de DKIM que pasa se alinee con el dominio From visible, salvo que un pass de SPF alineado satisfaga DMARC en su lugar.

¿Por qué falla DKIM después de agregar un pie de página o reescribir el seguimiento?

DKIM cubre los encabezados seleccionados y un hash del cuerpo. Una modificación posterior que quede fuera de las reglas de canonicalización seleccionadas puede invalidar la firma después de crearla.

¿Cómo deben rotarse las claves DKIM?

Primero publique y verifique un selector nuevo, cambie la firma controlada a ese selector, supervise los resultados, conserve la clave pública anterior durante las ventanas de reintento y de caché, y luego retírela.

¿DKIM determina la llegada a la bandeja de entrada?

No. DKIM aporta evidencia acotada de la firma de un dominio. Los receptores siguen evaluando de forma independiente DMARC, SPF, la reputación, las quejas, el contenido, la frecuencia de envío y la política del buzón antes de decidir el resultado de la entrega.

¿Un registro DNS público demuestra que la firma DKIM está activa?

No. Valide los mensajes recibidos originales con la clave publicada y confirme los valores d= y s= en el encabezado DKIM-Signature.

Fuentes

Siga aprendiendo

Cómo comprobar DKIM en el correo de su aplicaciónCompruebe DKIM inspeccionando una firma real, consultando su selector y dominio, verificando el mensaje, leyendo los resultados del receptor y probando la alineación.Cómo hacer una comprobación DMARC del correo de su aplicaciónCompruebe la detección del registro DMARC, la sintaxis, la alineación SPF y DKIM, la política, los informes y los mensajes reales de la aplicación sin confundir una consulta DNS con la entrega.Cómo comprobar un registro SPF para el correo de su aplicaciónCompruebe el dominio SPF correcto, la sintaxis, los mecanismos, el presupuesto de consultas DNS anidadas, la autorización de la IP de origen, el resultado y la alineación DMARC del correo de su aplicación.Cómo evaluar un servicio de entregabilidad de correo electrónicoEvalúe los servicios de entregabilidad de correo según su alcance, evidencia, autenticación, bucles de retroalimentación, supresiones, privacidad, portabilidad y adecuación operativa.Protocolo SMTP: cómo circula el correo de una aplicaciónDescubra cómo el envío SMTP, el relay, los sobres, los códigos de respuesta, TLS, los reintentos y el contenido del mensaje determinan el flujo de correo de una aplicación.