A DKIM La configuración se completa cuando el servicio firma el correo deseado y un destinatario puede validarlo. Un estado DNS verde por sí solo no establece ninguno de los dos resultados. Elija TXT o CNAME del modelo de administración de claves admitido por el proveedor, en lugar de tratarlos como formas intercambiables de pegar una clave.
Identificar quién gestiona la llave
Un publicado directamente registro TXT lleva los datos de verificación DKIM . Con un acuerdo CNAME , el selector nombre alias otro nombre DNS donde se gestionan los datos de verificación. La clave de firma privada pertenece al sistema de firma, nunca a ningún registro público. RFC 6376 §3.6 y RFC 6376 §6.1.2 describir el descubrimiento y la recuperación de claves; El comportamiento del alias DNS se define en RFC 1034 §3.6.2.
Procedimiento de dominio personalizado de Microsoft 365 utiliza registros CNAME y destinos generados por inquilinos. Su documentación actual es un ejemplo de por qué no es seguro copiar un patrón de destino anterior. Obtenga los valores mostrados para el inquilino real y el dominio seleccionado. Este ejemplo no implica que un servicio no relacionado acepte los mismos registros.
Antes de editar DNS , registre la cuenta de envío, el dominio visible De, el dominio de firma previsto, los nombres del selector, el tipo de registro, los valores exactos generados y el propietario responsable. Pregunte qué sistema realiza la rotación y quién retira la delegación cuando finaliza el contrato. Si el proveedor no puede utilizar el dominio de firma requerido, cambiar el tipo de registro DNS no creará esa capacidad.
Publicar con el nombre del propietario correcto
Una firma ilustrativa con d=example.com y s=billing lleva a billing._domainkey.example.com. El ejemplo identifica un nombre de propietario DNS , no una clave pública que funcione ni un destino CNAME de producción.
Compruebe si la interfaz DNS espera ese nombre completo o sólo facturación. _domainkey. Algunas interfaces añaden el nombre de la zona. Vuelva a leer el nombre del propietario resultante en lugar de asumir que el cuadro de entrada lo conservó. Inspeccione los datos existentes antes de cambiar el nombre. Un CNAME convencional no puede coexistir allí con un registro de clave TXT independiente; conservar los selectores no relacionados y seguir el procedimiento de migración admitido por el proveedor.
Para TXT , publique el valor público exacto en la representación admitida. Para CNAME , utilice el destino generado, no una clave copiada descubierta en el destino hoy. Copiar la clave actual localmente puede romper el modelo de rotación posterior del proveedor. Mantenga capturas de pantalla o registros exportados en el registro de cambios, excluyendo credenciales y claves privadas.
Verificar la resolución y el envío real por separado
Consulte el nombre exacto del propietario con DNS autorizado y luego verifique la resolución recursiva a través de la ruta que utilizarán los destinatarios. Para CNAME , siga el alias hasta el resultado final TXT y registre cualquier tiempo de espera o objetivo faltante. Permita el almacenamiento en caché de datos antiguos, incluidas las respuestas negativas, al interpretar el desacuerdo. La publicación y la convergencia de caché global son observaciones diferentes.
Luego envíe un mensaje controlado a través de la aplicación real. Conserve sus encabezados sin formato y el resultado de autenticación del sistema receptor confiable. Registro d=, s= y verificación DKIM . Controlar alineación con el dominio De visible por separado. Una firma válida de un dominio propiedad del proveedor puede no estar relacionada con la identidad del cliente que pretendía autenticar.
Si DNS se resuelve pero el correo no está firmado, investigue la activación y el enrutamiento del servicio. Si la firma nombra un selector diferente, inspeccione ese selector en lugar de editar repetidamente el registro no utilizado. Si la verificación falla después de la modificación del contenido, cambiar TXT a CNAME no es la solución.
Hacer responsable a la dependencia
Cierre el cambio sólo cuando el registro, el firmante y la evidencia recibida estén de acuerdo. Almacene la configuración anterior y un plan de recuperación autorizado antes de la transición. Al realizar la salida, detenga la integración de envío y retire deliberadamente su dependencia de verificación, teniendo en cuenta el correo legítimo que aún está en tránsito. No deje un alias de proveedor inexplicable indefinidamente ni elimine un selector activo simplemente porque una hoja de cálculo del contrato indique que el servicio finalizó.
Lectura relacionada
Delegación DNS DKIM : evaluar el alcance del control otorgado a un proveedor · Sintaxis de clave pública DKIM : identificar valores DNS truncados o con formato incorrecto.
Aplicar la distinción
Utilice un registro de aceptación de tres partes: propietario/tipo/valor publicado y tiempo de observación; d/s recibidos reales y verificación confiable; alineación con el dominio de autor previsto. Si DNS es correcto pero el correo no está firmado, investigue la activación o la selección de ruta en lugar de cambiar el tipo de registro. Si se emite un selector diferente, siga esa evidencia. La lista de verificación es un trabajo de revisión propuesto, no una prueba de correo o DNS realizada.