Utilice la configuración de la cuenta como punto de partida
Sendloop proporciona un flujo de trabajo de cuenta para la autenticación del dominio del remitente, mientras que su asistente de autenticación pública también menciona dedicado DKIM y alineación ajustes. Esas páginas establecen que la autenticación está disponible, pero no establecen el conjunto de registros exacto, la identidad de firma o los controles de sobre para una cuenta en particular. Esta guía lo guía a través del flujo de trabajo documentado de la cuenta y un plan de verificación controlado. Un acuerdo DKIM exclusivo o un requisito de sobre personalizado sigue siendo un elemento de confirmación del proveedor. Asistente de autenticación de Sendloop, DKIM y configuración de alineación de dominio.
Primero identifica la cuenta, los dominios aprobados y las campañas o automatizaciones que utiliza cada uno. Registre si la cuenta tiene un acuerdo de entrega exclusivo y quién puede confirmarlo. No infiera la infraestructura dedicada a partir de una etiqueta de precios, un correo electrónico de incorporación antiguo o una lista de IP de envío de terceros. Asigne un administrador de Sendloop, un propietario DNS y un revisor para la organización. DMARC política.
Antes de realizar cambios, exporte las entradas DNS actuales para los propietarios relevantes. Mantenga un mensaje recibido por un representante de la ruta aprobada existente, si está disponible. Un inventario de lo que ya funciona evita que un nuevo proyecto de autenticación deshabilite accidentalmente a otro remitente. El objetivo es una ruta Sendloop autenticada y alineada, no un reemplazo total de la configuración de correo electrónico del dominio.
Abra el panel de control del dominio del remitente
La guía del proveedor lo dirige a Configuración > Autenticación del dominio del remitente > Autenticar dominio del remitente y luego Agregar dominio. El Panel de control de dominio resultante proporciona valores relevantes para la cuenta y una acción Verificar registros DNS . Capture esa salida antes de editar DNS . Si la interfaz actual es diferente, utilice las instrucciones o el soporte del proveedor actual en lugar de adivinar botones equivalentes. Guía de Sendloop, uso del asistente de autorización de correo electrónico y verificación de la configuración de autenticación.
Registre cada propietario completo, tipo DNS , valor y TTL con su propósito. Mantenga el conjunto de registros mostrado adjunto al ticket de cambio. Si el panel muestra un registro faltante, determine si está ausente, publicado con el propietario equivocado o presente con un valor diferente. Un dominio ya configurado para otra cuenta de Sendloop puede necesitar la coordinación del proveedor en lugar de un reemplazo.
La guía pública tiene un SPF ejemplo y una enmienda de registro existente que no enumera inclusiones idénticas. También describe la preparación de archivos de texto. No convierta ninguno de los detalles en una receta de producción automática. DNS debe contener la política vigente y aplicable; un archivo de texto guardado en una estación de trabajo no lo publica. Resolver cualquier discrepancia entre el panel de cuenta y la página pública antes de la implementación. Guía de Sendloop, Configurar el registro SPF.
Revisar SPF sin ampliar permisos no relacionados
Determine qué dominio de sobre utiliza el mensaje real de Sendloop. Esa es la identidad que se debe investigar para SPF , en lugar de asumir que el dominio De visible debe ser el propietario de la evaluación. Si existe un arreglo de sobre personalizado autorizado, capture su configuración emitida y su alcance. Si no es así, registre la identidad del sobre del proveedor observada y evalúe la alineación DKIM por separado.
En cualquier cambio de propietario, conserve una única política SPF y conserve las autorizaciones requeridas por otros remitentes activos. Revise las búsquedas DNS anidadas antes de agregar nuevos términos. El límite de diez términos de SPF se aplica a los mecanismos y modificadores que provocan búsquedas DNS durante la evaluación, no a la cantidad de palabras visibles en el registro. También vale la pena revisar los mecanismos permisivos existentes, pero eliminarlos es una decisión de dependencia separada. RFC 7208 , secciones 4.5 y 4.6.4.
No copie una política de muestra amplia como reemplazo del registro existente. Hacerlo podría autorizar hosts no deseados, cambiar el calificador de falla o eliminar otro proveedor. Cuando la autorización requerida no pueda caber de manera segura, deténgase y solicite al propietario del correo que elija un diseño compatible. No resuelva el problema publicando otra política SPF o eliminando servicios con los que no esté familiarizado.
Publicar únicamente el material DKIM público emitido
Utilice el valor público y de propietario proporcionado para esta cuenta. La guía pública muestra una configuración DKIM TXT , pero su clave de demostración no es la clave del cliente. Si el panel o el soporte proporciona un formulario de registro respaldado diferente, conserve esa instrucción en lugar de convertirla sin evidencia. Guía de Sendloop, Configurar el registro DKIM.
Sólo la clave de verificación pública pertenece al DNS . DKIM crea una firma criptográfica con una clave privada; no incorpora la clave privada en el mensaje saliente. La explicación informal de la guía pública no debe leerse como una solicitud para compartir secretos de firma. El mensaje lleva una firma y el verificador utiliza la clave pública identificada por su dominio de firma y selector. RFC 6376 , secciones 3.5 y 6.1.
Verifique que el propietario propuesto tenga una clave activa que pertenezca a otra ruta. Una colisión requiere coordinación; No es seguro sobrescribir un selector en funcionamiento solo para borrar un estado rojo. Verifique el nombre completo después de la publicación, incluido el sufijo de dominio agregado por el editor DNS . Mantenga marcas de tiempo y resultados de consultas para que los informes posteriores puedan distinguir una caché obsoleta de un propietario o clave incorrectos.
Mantenga la marca del enlace fuera de la conclusión de alineación
La guía del proveedor describe un opcional CNAME para enlaces de mensajes con alias. Su propósito es vincular la marca, no evidencia de que SPF o DKIM estén alineados. Impleméntelo solo si se aprueba el cambio de seguimiento relevante y la cuenta proporciona el objetivo exacto. Guía de Sendloop, OPCIONAL: Configurar el registro CNAME.
Verifique el sitio web existente o el uso de seguimiento antes de reclamar al propietario propuesto. No apunte el sitio web raíz o el nombre de host de una aplicación activa a un objetivo de seguimiento. Mantenga un enlace de prueba inofensivo en la campaña controlada para que el revisor pueda verificar tanto su destino como el nombre de host mostrado. La autenticación y la función de enlace son comprobaciones de aceptación independientes; un enlace de marca que funciona no establece una firma válida.
Regrese a la verificación DNS de la cuenta después de la publicación. Compare cada resultado mostrado con una búsqueda pública independiente. Registre los estados pendientes con honestidad. Si una cuenta se muestra verificada mientras la prueba externa aún falla, deje el cambio abierto y use la evidencia del mensaje para ubicar el límite restante.
Recopilar un registro de identidad de mensaje recibido
Envíe a través del flujo de trabajo de la campaña real a buzones de correo externos controlados sin utilizar datos del cliente. Repita este procedimiento para dominios De o configuraciones de entrega materialmente diferentes. Conserve el mensaje original y los resultados del receptor confiable, junto con un ID de mensaje y una marca de tiempo UTC. Registre todas las firmas DKIM en lugar de detenerse en la primera firma que pase.
El registro de evidencia debe contener el dominio visible De, la identidad del sobre autenticado, Return-Path, valores DKIM d= y s=, resultados SPF y DKIM y el resultado DMARC del receptor. Establezca qué mecanismo de paso se alinea con el dominio De. La alineación relajada y estricta impone diferentes comparaciones de dominios; registrar el modo en uso. RFC 9989 , explicación de la alineación del identificador.
Si la única firma que pasa utiliza un dominio de proveedor no relacionado, solicite la opción de firma de dominio de cliente admitida y sus condiciones de activación. La nota de contacto DKIM dedicada del asistente público no prueba que la opción esté habilitada, sea gratuita, esté disponible en todos los planes o esté configurada automáticamente. Obtenga esas respuestas para la cuenta exacta. No represente un alias de seguimiento como dominio de sobre alternativo.
Utilice el error para seleccionar la siguiente verificación
por un desaparecido firma DKIM, confirme la cuenta, seleccione Desde identidad y activación de proveedor. En caso de un error de firma, compare el selector observado y la clave pública antes de investigar los cambios posteriores en el contenido firmado. Una prueba con una dirección de remitente diferente puede tener éxito mientras la campaña afectada aún falla, así que mantenga el flujo de trabajo constante durante el diagnóstico.
En caso de falla SPF , identifique el dominio evaluado y la fuente de envío final. Para aprobación SPF con falla DMARC , inspeccione la alineación en lugar de agregar más inclusiones SPF . Si el proveedor no puede documentar la opción de identidad requerida, mantenga ese requisito bloqueado y evalúe otra ruta admitida con el propietario de la empresa. No reduzca la política de un dominio completo simplemente para que la prueba de un proveedor deje de fallar.
Prepare un paquete de soporte que contenga la identificación de la cuenta, el dominio afectado, los registros públicos emitidos, las respuestas DNS observadas, el ID del mensaje, la hora y los resultados relevantes del receptor. Excluya contraseñas, claves API, listas de destinatarios y contenido de mensajes no relacionados. Una falla reproducible concisa es más útil que múltiples capturas de pantalla no correlacionadas de ediciones DNS .
Recuperación y aceptación de hojas de trabajo.
Utilice la hoja de trabajo de autenticación de Sendloop (cree un registro de revisión separado con los campos descritos aquí) para realizar un seguimiento de la revisión de discrepancia de registros, la confirmación de funciones dedicadas y la comparación final de identidad. Una respuesta de capacidad de sobre faltante puede permanecer explícitamente sin resolver incluso cuando funciona DKIM alineado normal. Defina la aceptación frente al requisito empresarial en lugar de llenar cada espacio en blanco con una suposición.
Si el cambio falla, suspenda los envíos afectados y restaure la configuración previamente aprobada a través del plan de cambios registrado. Coordinar los cambios DKIM con la activación del proveedor; Eliminar una clave pública mientras el servicio aún firma con ella crea una nueva falla. Al retirar Sendloop, confirme que todas las campañas y automatizaciones se hayan detenido y revise las dependencias SPF compartidas antes de eliminar los registros de confianza o de seguimiento.
Ejemplo ficticio trabajado de una discrepancia SPF
Solo caso escrito ficticio: SLP-01 asume la intención De offers@workshop.example . El ejemplo público contiene dos inclusiones de proveedores, mientras que su instrucción de política existente nombra una; Se desconocen la autorización de la cuenta actual, la identidad del sobre y los resultados de DKIM / SPF . El propietario DNS retiene el cambio y solicita al propietario de la cuenta que obtenga una confirmación específica de la ruta. Un archivo de texto y un enlace de marca no establecen autenticación. Después de la aclaración, el equipo revisaría una política y recopilaría un mensaje de campaña controlado. No se ejecutó ninguna cuenta, DNS o prueba de envío.
Cobertura documental y puertas restantes.
Este borrador cubre el flujo de trabajo de la cuenta pública y la verificación segura. No establece un DKIM dedicado universal ni una configuración Return-Path personalizada, y no afirma que se haya inspeccionado un mensaje Sendloop alineado en vivo. Esos detalles dependientes de la cuenta, DNS en vivo y evidencia de encabezado, revisión independiente, revisión visual y aprobación humana de las PYME siguen pendientes. Mantenga en suspenso el alcance completo de la implementación original hasta que la evidencia de cuenta requerida cierre las brechas.
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.