Dominios de inventario por servidor y aplicación
La autenticación de SocketLabs debe revisarse para el servidor o subcuenta que realmente envía el mensaje. Comience con una lista de aplicaciones, visibles desde los dominios y la configuración de SocketLabs que utiliza cada aplicación. Incluya distintos subdominios, marcas de clientes y rutas alternativas. Una marca que funcione no es prueba suficiente para un servidor que envía en nombre de varias organizaciones.
El proveedor requiere dominios de envío verificados y documenta un error cuando una dirección no está permitida. Admite la verificación de propiedad a través de un proceso de confirmación de dirección o funciones de autenticación DNS elegibles, al tiempo que señala que la configuración y el plan de la cuenta afectan la aplicación de los controles del dominio de envío. SocketLabs Envío de dominios, adición y verificación de un dominio de envío.
Permiso separado para enviar de la autenticación en el receptor. Se puede permitir que un dominio envíe sin el dominio de cliente deseado DKIM o identidad del sobre que se utiliza. Regístrelos como comprobaciones independientes y obtenga el permiso del propietario del dominio antes de autorizar la identidad de un cliente o socio.
Elija el método DKIM con el propietario de la clave
SocketLabs documenta tres métodos: una clave TXT proporcionada por el cliente, una clave TXT generada por el proveedor y una clave TXT administrada por el proveedor. CNAME. La elección cambia quién administra las claves y cómo se mantienen en los servidores. Su descripción general actual dice que la firma requiere una coincidencia con la identidad De. Descripción general de SocketLabs DKIM , los tres métodos de firma.
Registre la decisión antes de que comience el trabajo DNS . Para un método administrado por el proveedor, identifique quién puede cambiar la configuración de firma. Para un método controlado por el cliente, identifique el custodio de la clave privada y el proceso de rotación aprobado. Una hoja de cálculo llena de claves no es un registro de propiedad aceptable. La hoja de trabajo debe contener una referencia de evidencia y una persona responsable, no material secreto.
No elija automáticamente el método más complejo porque expone más controles. Prefiera el enfoque respaldado que cumpla con los requisitos de la organización y pueda ser mantenido por sus operadores reales. Si la política requiere un acuerdo particular de administración de claves o una identidad de firma inusual, obtenga la confirmación del proveedor antes de presentar la configuración como compatible.
Configurar el método de firma seleccionado
Para la firma CNAME , la guía oficial describe un registro DNS delegado y una verificación del lado de la cuenta antes de habilitar la función. La guía CNAME enumera dkim. _domainkey bajo el dominio de envío que apunta a dkim._domainkey.email-od.com . Compare ese par documentado públicamente con las instrucciones de la cuenta corriente; no sobrescribas un ocupado selector simplemente porque el ejemplo coincide con su nombre. Si el host DNS no puede admitir el guión bajo requerido en el propietario CNAME , la guía dirige a los usuarios hacia el enfoque TXT en lugar de una ortografía inventada. Guía de firma CNAME de SocketLabs.
Compruebe si otro servicio ya utiliza el propietario del selector previsto. Un CNAME no se puede pegar de forma segura sobre un selector no relacionado. Solicite una alternativa admitida o una migración aprobada en su lugar. Preservar el registro existente, sus servicios dependientes y la decisión de cambio en el ticket de implementación.
La guía TXT distingue generar claves en la plataforma de traer un par de claves. Requiere la clave pública en DNS y verifica esa clave antes de guardar la configuración relevante. El flujo de claves generadas mantiene su componente privado en la cuenta. Guía de firma TXT de SocketLabs.
Utilice un flujo de trabajo de manejo de secretos aprobado si el método seleccionado implica la importación de material privado. Publique solo la clave pública. Registre el dominio y el selector exactos e inspeccione el valor TXT lógico resultante después de dividir cualquier cadena del editor DNS. La guía de clave generada dice que la clave pública ya no está disponible en el portal después de publicar y guardar correctamente DNS . Conserve el registro público y su procedencia antes de cerrar el ticket de configuración, sin conservar la clave privada en el paquete de revisión.
Configure el dominio de rebote como una asignación separada
SocketLabs implementa el dominio del cliente SPF a través de su modelo de dominio de rebote personalizado sin requerir una adición al visible-From existente Registro SPF. Su guía especifica un CNAME del subdominio de rebote seleccionado a tracking.socketlabs.com . Se pueden configurar múltiples entradas de rebote; El correo no coincidente utiliza el valor predeterminado seleccionado o el respaldo del proveedor. Guía de rebote personalizado de SocketLabs, configuración y múltiples dominios de rebote personalizados.
Elija un nombre no utilizado con el administrador DNS y confirme la asignación admitida en el servidor real. Mantenga intacta la configuración de correo entrante normal del dominio. Un nombre de host de rebote es una identidad de entrega de la aplicación y no debe confundirse con el buzón de respuesta de un usuario o el punto final de seguimiento del sitio web.
Registre la coincidencia deseada para cada dominio De y luego registre el comportamiento predeterminado. Los valores predeterminados merecen una revisión comercial explícita en un servidor multimarca: la entrega exitosa aún puede exponer una identidad de marca o proveedor inesperada. No infiera la asignación activa únicamente a partir de los nombres en la configuración. el emitido Return-Path es la evidencia para comparar más adelante.
Publicar y comparar los registros públicos.
Exporte los registros DNS relevantes antes de realizar el cambio aprobado. Confirme el servicio autorizado y el manejo de nombres relativos por parte del editor DNS . Inspeccione cada propietario publicado de forma independiente, incluida su cadena CNAME o respuesta TXT . Un registro DKIM correcto no prueba que el nombre del rebote esté configurado y un registro de rebote correcto no prueba que la firma DKIM esté activa.
SPF se evalúa utilizando la identidad del sobre SMTP , no simplemente el De visible. Si otro servicio aún necesita la política SPF del dominio raíz, consérvela. En cualquier propietario donde se requiera una política SPF , mantenga una política y verifique el límite de plazo de consulta de DNS del protocolo. RFC 7208 , secciones 2.4, 4.5 y 4.6.4.
Espere respuestas consistentes, autorizadas y recursivas cuando estén involucrados cachés. Si el proveedor no puede verificar un récord, guarde el valor emitido y las observaciones DNS cronometradas para obtener soporte en lugar de cambiar el nombre repetidamente. Una limitación del host DNS debe manejarse mediante un método compatible y documentado.
Pruebe cada coincidencia de dominio y rebote exacta
Envíe contenido inofensivo a través de cada aplicación material y servidor a destinatarios externos controlados. Conservar la hora, el ID del mensaje y la referencia del evento del proveedor o de la aplicación. Pruebe los subdominios por separado en lugar de asumir que una entrada para el dominio principal los cubre.
La página CNAME anterior menciona PRA y Remitente en su descripción de aplicabilidad, mientras que la descripción general actual y la página TXT describen una coincidencia De origen exacta. Si la aplicación utiliza un encabezado de Remitente separado u otra identidad inusual, obtenga una aclaración y pruebe ese formulario exacto. No traduzcas silenciosamente esas diferentes declaraciones en una regla universal.
En el destinatario, registre el origen visible, Return-Path , la identidad y el resultado SPF confiable, cada d y s DKIM , y el DMARC resultado. La verificación DKIM utiliza el dominio y el selector en la firma real para localizar la clave pública. RFC 6376 , secciones 3.5 y 6.1.
Compare cada identidad pasajera con la visible De debajo de la aplicable alineación modo. Un subdominio de rebote personalizado puede cumplir con una alineación relajada SPF sin cumplir con una igualdad estricta. Un pase alineado firma DKIM puede satisfacer DMARC de forma independiente. Ni la verificación exitosa del dominio ni un pase de autenticación del dominio del proveedor son suficientes para inferir el resultado completo. RFC 9989 , explicación de la alineación del identificador y evaluación DMARC.
Diagnosticar la capa defectuosa
Para un error de remitente no permitido, inspeccione la verificación y los controles de dominio del servidor correcto antes de cambiar las claves DNS . Para un dominio de firma inesperado, compare el Desde exacto con la entrada DKIM configurada. Para un Return-Path inesperado, inspeccione la coincidencia de rebote y el valor predeterminado. Mantenga estas comprobaciones separadas para que la reparación de una no oculte un problema en otra.
Si la verificación criptográfica falla a pesar de que DNS sea correcto, investigue los cambios en el contenido firmado o en los encabezados a lo largo de la ruta. Si la autenticación y la alineación pasan pero la ubicación de la bandeja de entrada es deficiente, investigue el filtrado del destinatario, la reputación y el propósito del mensaje. La autenticación no promete la entrega ni hace legítimo todo uso de una cuenta autorizada.
Recuperación de registros antes del lanzamiento
Complete la hoja de trabajo del servidor y el dominio de SocketLabs (cree un registro de revisión separado con los campos que se describen aquí). Conserve una matriz de permisos ruta por ruta, método de firma, mapeo de rebotes y evidencia recibida. Identifique quién puede pausar la aplicación o restaurar una configuración de servidor previamente aprobada si la prueba falla.
No elimine claves públicas antiguas ni registros de rebote mientras los mensajes en cola u otros servidores dependan de ellos. Planifique el retiro con el propietario de la aplicación y vuelva a realizar la prueba después de los cambios en el dominio De, el servidor, el método de clave, el valor predeterminado de rebote o el proveedor DNS .
Caso de diagnóstico ficticio que involucra una entrada de rebote predeterminada
Solo caso escrito ficticio: SOCK-01 supone que un servidor envía Desde news@alpha.example con sobre bounces.alpha.example y un resultado SPF pasajero. Una segunda ruta utiliza From news@beta.example pero recurre a bounces.alpha.example , también con pase SPF . Bajo alineación relajada se alinea el primer sobre estipulado; el segundo no. Se desconocen ambos resultados DKIM , por lo que no se afirma ni una falla completa del segundo mensaje ni una reparación exitosa. El propietario del servidor debe aprobar y verificar el mapeo de la versión beta, luego inspeccionar su Return-Path y DKIM emitidos. No se realizó ninguna prueba de servidor, DNS o mensajes.
La aceptación sigue pendiente
Acepte la ruta cuando el servidor previsto permita el dominio, el método de firma seleccionado verifique, cada mapeo de rebote se comporte como aprobado y la evidencia del receptor establezca el paso alineado requerido. La aceptación del alcance original, las verificaciones DNS y de inquilinos en vivo, la revisión técnica independiente, la revisión visual y la aprobación humana de las PYME siguen pendientes para este borrador no publicado.
Separar un mensaje pasajero de la preparación para hacer cumplir la ley
RFC 9989 La sección 7.4 requiere DKIM válido para la publicación de un dominio p=reject y advierte sobre la interoperabilidad del correo indirecto. Un único resultado alineado SPF no justifica por sí solo la implementación de una política de rechazo. Revise todas las rutas legítimas y la propiedad de la política por separado de la configuración de este proveedor.