A DKIM El diagnóstico sin clave generalmente significa que el verificador no pudo encontrar la clave de verificación requerida para una firma. El punto de partida útil es la realidad del mensaje. selector y firma de dominio. Adivinar un selector común o consultar el dominio De visible puede conducir a una respuesta perfectamente precisa a la pregunta DNS incorrecta.
Conserve el mensaje recibido original y su resultado de autenticación confiable. Registre el tiempo de observación, porque la clave puede haber cambiado desde la entrega. Luego investigue la firma exacta nombrada en el resultado; Los mensajes pueden llevar varias firmas con diferentes nombres de búsqueda y resultados.
Derivar la pregunta DNS exacta
Lea s y d de DKIM-Signature. Con s=campaign7 y d=mailer.example, la búsqueda es campaign7._domainkey.mailer.example . El selector no es un nombre de proveedor universal y el dominio de firma no tiene por qué ser el mismo que el dominio De origen visible. RFC 6376 §3.1, RFC 6376 §3.5 y RFC 6376 §3.6.2.1 definir estos elementos.
Consulta el nombre y el tipo de registro esperado por la configuración admitida. Bajo RFC 1034 §3.6.2, si el servicio utiliza un CNAME, sígalo hasta los datos de verificación y capture el objetivo intermedio. Compruebe si hay errores en el editor de DNS, como un sufijo añadido dos veces, un récord publicado en la zona incorrecta o un selector copiado de un inquilino diferente.
Distinguir ausencia de indisponibilidad
Una respuesta negativa que no establece una clave correspondiente es diferente de una consulta que caduca. RFC 6376 §6.1.2 requiere PERMFAIL para una clave ausente y permite TEMPFAIL cuando la consulta de clave no responde. Estos son los resultados del procesamiento del verificador; la etiqueta exacta que se muestra en un producto de diagnóstico puede diferir.
Capture el código de respuesta DNS y responda, no solo un indicador rojo. Compare las respuestas autorizadas con la vista recursiva relevante para el receptor fallido cuando haya evidencia disponible. Una búsqueda exitosa desde su computadora portátil posteriormente no prueba que se pudiera acceder a la clave en el momento de la evaluación original.
Utilice un árbol de diagnóstico de tres ramas
Primero, si el mensaje no contiene ninguna DKIM-Signature , investigue la configuración de firma en lugar de una búsqueda de selector. No hay ningún par s y d específico del mensaje para recuperar. En segundo lugar, si existe una firma y su clave no está, inspeccionar el historial de publicación, migración y retiro. En tercer lugar, si la clave está disponible pero el hash corporal o la firma falla, pase a verificaciones de contenido, coincidencia de claves o criptográficas.
Caso ilustrativo: un selector de nombres de mensajes antiguo7, mientras que DNS contiene solo nuevo8. La publicación correcta de new8 no puede verificar la firma old7. Si old7 se eliminó intencionalmente, es posible que el error se deba a correo retrasado o archivado. Si old7 se eliminó accidentalmente y su clave aún es confiable, la restauración de los datos de verificación correctos puede ser una reparación aprobada adecuada. Estos son escenarios de diagnóstico, no pruebas de inquilinos ejecutadas.
Verificar la validez de la clave después de la recuperación
Encontrar una respuesta TXT no finaliza la verificación; RFC 6376 §3.6.1 y RFC 6376 §6.1.2 definir la sintaxis clave y la validación. Una clave con formato incorrecto, un valor p vacío que indica revocación o un material de clave incompatible no son una clave de verificación utilizable. Bajo RFC 4592 §3.3.3, un comodín registro TXT También puede producir una respuesta que sea irrelevante para DKIM . No vuelva a etiquetar cada respuesta inutilizable como un selector faltante.
Utilice el valor de registro actual exacto del proveedor o una copia de seguridad de configuración conocida y autorizada. Nunca genere una clave pública aleatoria para satisfacer la búsqueda: no coincidirá con la clave privada que creó la firma. Evite reemplazar registros en una búsqueda compartida sin revisar otros remitentes y mensajes retrasados.
Verifique la solución con evidencia nueva
Después de una reparación autorizada, inspeccione DNS y envíe nuevo correo controlado a través de la ruta afectada. Preservar el resultado recibido, la identidad de la firma y alineación evaluación. Si la muestra original ahora se verifica, regístrelo como una nueva verificación posterior en lugar de reescribir el resultado histórico del receptor.
Cerrar el incidente con el nombre faltante, causa, dependencia restaurada y medida de prevención. Un inventario de selección y una lista de verificación de retiro reducen la recurrencia de manera más efectiva que agregar registros repetidamente cada vez que un verificador indica rojo.
Preservar una conclusión acotada
Para old7 versus new8, conserve la búsqueda de la firma anterior en lugar de copiar el selector actual en el registro del incidente. Una clave old7 ausente, un tiempo de espera y una revocación p vacía son observaciones diferentes. Una nueva verificación exitosa posterior debe mantener su tiempo posterior. No se realizó ninguna reparación o verificación de firma para el escenario de enseñanza.