Seleccione primero el producto y el servicio de entrega.
"Enviado por Sitecore" no es una descripción de ruta suficiente. La misma organización puede utilizar Email Experience Manager con EXM Delivery Cloud, EXM con SMTP personalizado o el producto Sitecore Send independiente. Este borrador cubre esas ramas documentadas, utilizando la documentación EXM 10.4 para los ejemplos versionados. Confirme el producto y la versión reales antes de adoptar cualquier procedimiento. El amplio alcance del catálogo permanece en suspenso hasta que se acepte esa selección.
Registre el propietario de la campaña, el dominio de envío, el producto, la cuenta o entorno y la ruta de entrega. Si hay una migración en curso, registre las rutas antiguas y nuevas por separado. No se debe suponer que un dominio validado en un producto esté configurado en otro. La implementación debe indicar exactamente qué flujos de trabajo cubrirá su evidencia.
Siga la sucursal EXM Delivery Cloud cuando corresponda
El Guía de dominio EXM 10.4 describe cómo agregar un dominio de remitente controlado en Administrador, Servicio de entrega de correo electrónico, Dominios. Mostrar detalles expone lo requerido DKIM información. Dice que Delivery Cloud utiliza un dominio de sobre común con administración del proveedor. SPF, por lo que no requiere una configuración SPF separada para cada dominio de envío visible.
Utilice únicamente un dominio que la organización posea y esté autorizada a utilizar. Obtenga el registro público emitido exacto y compárelo con la zona autorizada. No sustituyas un selector desde una instancia de Sitecore diferente. Si la verificación muestra una advertencia, conserve ese estado e investigue el propietario, el tipo y el valor publicados antes de continuar.
La guía EXM también recomienda un crecimiento gradual de la audiencia con listas mantenidas y habilitadas. Reputación del plan calentamiento por separado de la aceptación DNS ; Esta guía no establece ningún cronograma de volumen universal.
Planifique el cambio con el propietario de la campaña. Un dominio que se muestra configurado en la aplicación es una observación intermedia; la campaña final aún debe llevar la identidad deseada y producir un resultado alineado. No interprete SPF administrado por el proveedor como prueba de que el dominio From visible se alinea con SPF . El sobre y la firma reales determinan esa respuesta.
Asignar propiedad posterior para SMTP personalizado
El Comparación de entrega EXM Asigna la gestión de autenticación para SMTP personalizado al sistema de envío seleccionado por el cliente. El flujo de trabajo del dominio de Delivery Cloud no configura las claves, DNS o controles de reputación de ese relé. Este es un límite de responsabilidad, no una afirmación de que los servicios SMTP no puedan admitir DKIM .
Identifique el operador del relé y sus instrucciones de primera mano actuales. Registre qué sistema aplica la firma final, qué dominio de sobre utiliza y si otra puerta de enlace puede modificar el mensaje posteriormente. Si la organización opera el relé, asigne un administrador que pueda verificar esos controles. Si lo opera otro proveedor, obtenga allí los registros específicos de la cuenta correctos.
Mantenga la autenticación de retransmisión, el cifrado de transporte y DMARC separado. Una conexión segura a un relé no establece una firma de dominio del cliente en el receptor final. Del mismo modo, un envío SMTP exitoso solo muestra aceptación en ese salto. Vuelva a probar la ruta completa cada vez que cambie una retransmisión, una puerta de enlace o una modificación de contenido descendente.
Utilice el flujo de trabajo del remitente de envío de Sitecore por separado
Guía DNS de Sitecore Send dirige a los usuarios a Más, Configuración, Remitentes, con información de registro en las pestañas SPF y DKIM y una acción Verificar registros DNS . Describe la verificación combinada de SPF , DKIM y DMARC , incluidas verificaciones de dominio principal y un estado verificado de 48 horas. Estos son comportamientos de verificación de aplicaciones.
Copie los valores para el remitente y el dominio reales, no los valores de la pantalla del dominio EXM. Revise la política DMARC existente antes de cambiarla para satisfacer un mensaje de la aplicación. Es posible que un dominio ya tenga un destino de informes aprobado, una configuración de cumplimiento y alineación modo. Preservar esas decisiones a menos que una revisión autorizada por separado las cambie.
Trate cuidadosamente la regla de verificación del dominio principal del proveedor. No significa que SMTP SPF herede automáticamente un registro principal arbitrario. Un estado verificado en caché tampoco prueba que un mensaje recién recibido se autentique después de una edición DNS externa. Registre tanto el tiempo de verificación de la aplicación como la observación posterior del mensaje.
Revise los cambios DNS como un conjunto controlado
Prepare una hoja de cambios que contenga el dominio, propietario, tipo de registro, valor público, cuenta de origen y operador responsable. Exporte los registros existentes y resuelva los conflictos del selector antes de su publicación. Si una interfaz DNS agrega el dominio automáticamente, confirme el propietario totalmente calificado resultante. Mantenga las claves privadas y las credenciales de retransmisión fuera de la hoja.
Para cualquier cambio SPF administrado por el cliente, RFC 7208 proporciona las reglas de evaluación y el límite de búsqueda. Conserve otros remitentes autorizados y revise la política completa. No agregue una segunda política ni incluya un proveedor no relacionado solo porque una lista de verificación anterior espera un paso SPF de Sitecore.
Para DKIM , conserve todos los dominios de firma y selectores observados. RFC 6376 explica esos campos. DNS público debe corresponder a la firma realmente utilizada, no simplemente al selector que esperaba un administrador. Las firmas múltiples requieren resultados separados en lugar de una entrada indiferenciada "habilitada DKIM ".
Pruebe una ruta de campaña real con contenido inofensivo
Utilice una campaña controlada o un flujo de trabajo de prueba compatible que practique la ruta de entrega real. Registre si coincide con el envío de producción, porque una vista previa o una notificación de aplicación pueden usar otra ruta. Evite envíos de producción amplios mientras la identidad no esté verificada. Mantenga el identificador del mensaje y la hora de envío para que se puedan correlacionar los eventos del proveedor y la evidencia del receptor.
Capture visibles De, Responder a, dominio de sobre, todas las identidades DKIM y resultados de receptores confiables. RFC 9989 define el requisito de alineación. Identifique qué mecanismo de paso se alinea y por qué. Un sobre de proveedor no relacionado puede pasar SPF mientras que la identidad del cliente depende de DKIM alineado.
Verifique una falla en el contexto de su rama. En Delivery Cloud, compare el dominio configurado y los detalles de firma emitidos. Con SMTP personalizado, involucre al propietario del relé descendente. En Sitecore Send, compare los valores del remitente y el estado de verificación con DNS actual. No se mueva entre estos procedimientos hasta que se haya establecido la ruta misma.
Utilice la hoja de trabajo de decisión de producto y ruta.
La hoja de trabajo de entrega y producto de Sitecore (cree un registro de revisión separado con los campos descritos aquí) comienza con una selección de sucursal obligatoria. Luego registra la fuente del dominio, el estado de verificación, la propiedad posterior y las identidades finales de la campaña. Marque las ramas no utilizadas fuera del alcance en lugar de tratar todas las funciones posibles de Sitecore como parte de una sola implementación.
El registro de aceptación debe conectar cuatro observaciones: el producto seleccionado, su ruta de entrega activa, el DNS de soporte y el resultado final del receptor. Si falta alguno, indique las pruebas faltantes y el propietario responsable de ellas. Una insignia de producto no puede llenar el campo de mensaje recibido.
Caso de diagnóstico ficticio que involucra una migración de relevo.
Solo caso escrito ficticio: SC-02 asume la campaña prevista. De es news@museum.example . Después de un cambio de EXM Delivery Cloud a SMTP personalizado, el mensaje final pasa d=relay.example, un dominio no relacionado; se desconoce el resultado del sobre/ SPF y cualquier otra firma. Esa firma no está alineada, pero los hechos proporcionados no establecen un veredicto DMARC completo. El propietario del relé debe documentar la configuración de firma de dominio del cliente admitida y recopilar pruebas de la campaña real. La verificación anterior de Delivery Cloud no puede cerrar la nueva ruta. No se probó ningún inquilino, retransmisión, DNS o mensaje.
Recuperar solo la ruta cambiada
Mantenga disponible la antigua ruta aprobada durante una migración planificada cuando sea posible, con controles explícitos contra envíos duplicados. Coordine la reversión con la programación de campañas y los mensajes en cola. No elimine las claves públicas antiguas hasta que el propietario confirme que el correo restante ya no depende de ellas. Preserve los requisitos de supresión y manejo de rebotes al evaluar una ruta de entrega de reemplazo.
Vuelva a realizar la prueba después de la migración del producto, cambios de retransmisión, adiciones de dominio del remitente y ediciones DNS externas. Este sigue siendo un borrador documental inédito. El alcance exacto del producto original, los registros emitidos por la cuenta, DNS en vivo y la evidencia de los mensajes recibidos, la revisión visual y la aprobación humana de las PYME siguen pendientes.
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.