Confirme la implementación del CMS antes de elegir las instrucciones
Optimizely CMS crea mensajes de aplicación, pero el transporte configurado los envía. Comience registrando la versión del CMS, el modelo de alojamiento, el entorno y la integración de correo que maneja el flujo de trabajo afectado. No se puede suponer que un CMS que se ejecuta en DXP, una instalación autohospedada y una aplicación con su propia retransmisión de terceros compartan uno. SPF o DKIM configuración. Optimizely Campaign es un producto independiente y sus registros de dominio de correo de marketing no deben tomarse prestados para notificaciones de CMS.
La página del servidor de correo electrónico DXP propia recuperada para esta guía tiene la etiqueta DXP para CMS 12 y Commerce 14. Documenta una nube correo electrónico transaccional servicio, una configuración SMTP respaldada por SendGrid y un proceso de autenticación de dominio asistido por soporte. Este artículo utiliza esa ruta como su rama de implementación concreta. La aplicabilidad a otra versión de CMS, nivel de hosting o integración personalizada requiere la documentación actual correspondiente y evidencia de implementación. La etiqueta del catálogo general Optimizely CMS es más amplia que el alcance de configuración aquí establecido. Configuración del servidor de correo electrónico DXP
Antes de editar la configuración, nombre el propietario de la aplicación, el operador de implementación, el administrador de correo y el propietario DNS . Acuerde qué flujo de trabajo demostrará el éxito: una notificación de proyecto, un mensaje de aprobación de contenido u otro correo electrónico de aplicación configurado explícitamente. Utilice contenido sintético y un destinatario controlado. Un boletín de marketing no es un sustituto adecuado de una prueba de notificación de CMS simplemente porque ambos productos llevan el mismo nombre de proveedor.
Rastree el mensaje desde el evento de la aplicación hasta la retransmisión
Divida la ruta en creación de eventos, envío de aplicaciones, envío SMTP , entrega del proveedor y autenticación del receptor. Registre qué evidencia está disponible en cada etapa. Si la aplicación nunca produce ni envía una notificación, la edición SPF no puede crearla. Si SMTP rechaza las credenciales, el mensaje aún no ha llegado a la etapa en la que el destinatario evalúa DMARC.
La documentación de Proyectos CMS 13 de Optimizely describe por separado el envío de notificaciones y dice que se deben configurar las configuraciones SMTP para las notificaciones por correo electrónico. Esto admite la verificación de la etapa de activación y envío cuando la instalación real es CMS 13; no establece que una implementación de CMS 12 tenga valores predeterminados de trabajo idénticos o que el ejemplo de DXP SMTP se aplique sin cambios. Haga coincidir las instrucciones de configuración con la versión instalada en lugar de mezclar fragmentos versionados. Notificaciones de proyectos CMS 13
Para cada entorno, distinga la configuración de tiempo de ejecución efectiva de un archivo fuente que puede anularse durante la implementación. Un éxito de puesta en escena puede coexistir con un error de producción causado por una configuración faltante o una dirección De remitente diferente. Recopile configuraciones desinfectadas y registros de aplicaciones a través del proceso de ingeniería normal. No exponga credenciales SMTP , claves API ni secretos de producción no relacionados en el paquete de pruebas.
Configurar el transporte DXP documentado mediante un despliegue controlado
La guía DXP dice que la configuración de correo electrónico no se aplica automáticamente mediante transformaciones de configuración estándar. Describe la obtención de la credencial del servicio de correo electrónico a través del portal de administración de DXP y el suministro de configuraciones SMTP a la aplicación. Su ejemplo incluye configuraciones de identidad de notificación de aplicaciones, así como configuraciones de transporte. Utilice el mecanismo de configuración admitido para la versión y el entorno implementados y revise los valores efectivos resultantes. Configuración del servidor de correo electrónico DXP
Trate la creación, el almacenamiento y la rotación de credenciales como una operación de seguridad controlada independiente. Esta guía no requiere una nueva credencial si ya existe una credencial de trabajo aprobada. Nunca pegue un secreto en un artículo público, ejemplo de repositorio, registro DNS o captura de pantalla de soporte. En su lugar, haga referencia al almacén secreto aprobado y al operador responsable. Confirme que los registros de implementación y los informes de errores no impriman la credencial durante la prueba.
El servicio DXP documentado es para la comunicación automatizada de sitios web transaccionales. La guía dirige a los clientes que necesitan otras capacidades SendGrid , como el uso de su propia plantilla HTML personalizada, hacia una cuenta suscrita por separado u otro proveedor SMTP . Confirme el uso previsto en lugar de asumir que el acceso a DXP SMTP es un acceso sin restricciones a una cuenta SendGrid administrada por el cliente. Una cuenta separada tiene su propia propiedad y procedimiento de autenticación de dominio.
Solicitar autenticación para cada dominio de envío
Para la ruta DXP documentada, comuníquese con Optimizely con el dominio de envío para obtener ayuda para activar la autenticación del remitente. La misma guía dice que se debe solicitar DKIM para cada dominio de envío de correo y requiere registros DNS adicionales. Obtenga el conjunto de registros exacto y el plan de activación para el entorno antes de publicar cualquier cosa. No universal selector, CNAME La clave privada o de destino se puede derivar del nombre del producto. Dominio DXP y configuración DKIM
Enumere todos los dominios De visibles utilizados por las notificaciones relevantes. Si las aplicaciones multisitio o los flujos de trabajo configurados por separado utilizan dominios diferentes, pregunte al soporte técnico qué configuración de autenticación cubre cada uno. No asuma que la verificación del dominio corporativo principal activa automáticamente todos los subdominios o marcas alternativas. Registre quién debe confirmar la activación del remitente después de la publicación DNS .
La página DXP incluye ejemplos de políticas SPF . Trátelos como ejemplos de documentación, no como recetas completas para un dominio de producción. Determine el propietario real del sobre, conserve otros remitentes autorizados y mantenga allí una política SPF válida. Evalúe los límites de búsqueda recursiva antes de fusionar la autorización. Si el transporte configurado difiere del servicio DXP documentado, obtenga las instrucciones actuales de ese transporte. SPF RFC 7208
Publique cada registro DKIM proporcionado con el propietario exacto con el tipo proporcionado. Conserve los selectores activos durante una transición planificada, resuelva los conflictos CNAME antes de guardarlos y mantenga las claves privadas fuera DNS . Consulte los servidores autorizados para verificar el nombre y el valor resultantes; una vista previa del editor DNS no es suficiente. Un registro público admite la validación solo cuando el mensaje saliente real utiliza su identidad de firma correspondiente. DKIM RFC 6376
Mantenga coordinadas la identidad del remitente y la política DMARC
Acuerde la dirección de origen visible prevista antes de la prueba. Un nombre de host SMTP correcto y una credencial de trabajo no prueban que la aplicación utilice el dominio De remitente aprobado. Registre la identidad de notificación efectiva y cualquier anulación a nivel de aplicación por separado de la configuración de transporte. Revise el manejo de respuestas para que los destinatarios no sean dirigidos a un buzón desatendido sin una decisión comercial.
Inspeccionar la política DMARC actual para el dominio visible y mantener su aplicación aprobada. alineación y configuración de informes. DMARC tiene éxito cuando al menos una identidad SPF o DKIM que pasa se alinea en el modo aplicable. Un dominio de firma propiedad del proveedor puede pasar la validación criptográfica sin alinearse con el dominio visible De de la organización. No responda debilitando la política de todo el dominio antes de examinar la ruta de autenticación de remitente admitida. DMARC RFC 9989
La conectividad de aplicaciones, la autenticación del proveedor y la ubicación de la bandeja de entrada son resultados de aceptación separados. Un registro de CMS que indica que se envió un mensaje no es un recibo del buzón final. Un mensaje recibido que pasa DMARC aún puede filtrarse por otros motivos. Conserve estas distinciones en el informe de cambios para que una capa exitosa no oculte un problema no resuelto en otra parte.
Hoja de trabajo de rutas CMS y DXP reutilizables
Complete una copia separada para cada entorno de implementación e identidad de envío sustancialmente diferente.
- Versión de CMS, modelo de hosting, proyecto y entorno: ______.
- Flujo de trabajo exacto, desencadenante sintético y destinatario esperado: ______.
- Fuente de configuración, revisión de implementación y configuración de tiempo de ejecución efectiva: ______.
- Proveedor de transporte, titular de la cuenta y referencia secreta aprobada únicamente: ______.
- Visible desde, nombre para mostrar, destino de respuesta y expectativa de sobre: ______.
- Caso de soporte que confirma la aplicabilidad de DXP y cada dominio de envío: ______.
- Propietarios, tipos, valores y requisitos de activación DNS emitidos: ______.
- Políticas SPF y DMARC existentes y conjunto de cambios aprobados: ______.
- Respuestas autorizadas, tiempos de consulta y estado de verificación del proveedor: ______.
- Envío, envío SMTP y evidencia de entrega del proveedor: ______.
- Mensaje recibido de, sobre, todos los pares DKIM d=/s= y resultados confiables: ______.
- Implementación de reversión, plan de restauración DNS y aceptación humana: pendiente.
Diagnóstico ficticio de un fallo de notificación de producción.
Este ejemplo es ficticio. Un equipo prueba con éxito una notificación de aprobación en la etapa de preparación e implementa la aplicación. Los mensajes de producción utilizan un dominio De visible diferente. El envío SMTP se realiza correctamente, pero un receptor independiente informa una firma de proveedor válida que no se alinea con ese dominio de producción. El equipo propone copiar un objetivo DKIM de campaña en DNS porque también pertenece a Optimizely.
El diagnóstico propuesto compara la identidad de producción efectiva con los dominios cubiertos por la solicitud de soporte DXP. En este escenario, solo se incluyó la identidad provisional. El plan correctivo consiste en solicitar la configuración de autenticación admitida para el dominio de envío de producción, publicar los registros emitidos y volver a probar el flujo de trabajo de aprobación real. Tomar prestado un registro de campaña no establecería que el firmante de DXP lo utilice. Este es un ejemplo práctico, no una prueba en vivo ni una afirmación sobre la implementación de ningún cliente.
Recuperar en la capa que cambió
Si la aplicación deja de enviar mensajes, compare la configuración de implementación y transporte antes de revertir DNS . Si la verificación del dominio falla, compare los propietarios proporcionados por el soporte con respuestas autorizadas. Si la autenticación se realiza pero la entrega falla, inspeccione las respuestas del proveedor y del destinatario sin ampliar innecesariamente los permisos del remitente. Conserve la evidencia antes de volver a intentarlo para poder identificar notificaciones duplicadas.
La reversión debería restaurar la implementación o el cambio DNS estrechamente afectado, no rotar todas las credenciales ni restablecer toda la zona. Retire los selectores reemplazados solo después de que el propietario del correo confirme que ninguna ruta activa o en cola los necesita. La rama DXP documentada está establecida, pero la aplicabilidad más amplia de la versión CMS, la configuración específica del inquilino, los valores emitidos por el soporte, DNS en vivo, los mensajes recibidos, la revisión visual y la aprobación humana de las PYME siguen pendientes. No se cambió ninguna configuración de aplicación, credencial, registro DNS o flujo de trabajo en vivo para esta guía.
Mantenga la seguridad del transporte alejada de los ejemplos copiados
La página pública combina ejemplos de archivos de configuración e incluye una configuración de código SSL deshabilitado. Este artículo no aprueba esa configuración ni un fragmento de versión que no coincide. Haga que el propietario de la implementación confirme el transporte admitido y el comportamiento TLS para el tiempo de ejecución real sin exponer las credenciales. En el caso ficticio, la firma del proveedor por sí sola no determina el resultado SPF no especificado.
Separe la aceptación de mensajes de la implementación de políticas
Un resultado SPF alineado aprobado puede satisfacer la evaluación de un mensaje, pero no justifica por sí solo mover un dominio completo para rechazarlo. RFC 9989 La sección 7.4 requiere DKIM válido para la publicación de dominios p=reject y advierte sobre la interoperabilidad del correo indirecto. Haga un inventario de todos los remitentes legítimos y rutas indirectas antes de que el propietario de la política apruebe su aplicación. No se ejecutó ningún cambio DNS , operación de inquilino o prueba de mensaje recibido para este artículo.