Mantenga Account Engagement separado de otros productos de correo electrónico Salesforce
Salesforce Account Engagement tiene su propio flujo de trabajo de administración de dominios. Comience confirmando que el mensaje se envía a través de Account Engagement, anteriormente llamado Pardot, en lugar del correo electrónico principal Salesforce o Marketing Cloud Engagement. Una receta DNS para otro producto Salesforce puede utilizar controles diferentes y no debe importarse simplemente porque la organización utiliza el mismo proveedor. Esta guía cubre la verificación del dominio de envío de Account Engagement, DKIM y la ruta de retorno personalizada opcional asistida por soporte.
Enumere cada unidad de negocio, marca y dominio de origen utilizado por la cuenta. Incluya el remitente real seleccionado por la configuración de campaña y automatización. Un dominio que aparece en la dirección del buzón de un usuario no se configura automáticamente para cada ruta de Account Engagement. Asigne un propietario de marketing y un administrador DNS para que revisen el inventario juntos antes de cambiar los registros de un dominio compartido.
El objetivo de aceptación es un mensaje recibido controlado con un mecanismo de autenticación de paso alineado. La validación de la propiedad del dominio, la publicación DNS y el estado de gestión ecológica son pruebas intermedias útiles. Ninguno prueba por sí solo que una campaña específica utilizó la identidad deseada o que un servidor receptor aceptó su autenticación.
Comprenda la ruta SPF predeterminada antes de editar DNS raíz
Salesforce's Guía DNS para la participación de la cuenta indica que el correo de Account Engagement pasa SPF a través de su infraestructura de envío controlada y no requiere un cambio SPF del cliente para esa configuración predeterminada. No agregue una inclusión SPF genérica Salesforce al dominio raíz de la organización simplemente porque el nombre del producto aparece en un DMARC informe. Primero confirme la ruta real y la identidad evaluada.
SPF autentica el SMTP CORREO DE identidad, con manejo separado para HELO, bajo RFC 7208. Su resultado es distinto de alineación con el visible Desde. Una verificación SPF exitosa del dominio del proveedor puede coexistir con SPF no alineado. Cambiar la política de un dominio diferente no cambia el dominio de sobre que utiliza un mensaje.
Preservar la política SPF que necesitan los demás servicios de la organización. Si una configuración personalizada autorizada por separado requiere un cambio de política, revise una política completa de ese propietario, incluidos los términos de consulta de DNS anidados y el límite de búsqueda de protocolo. No crees un segundo Registro SPF o eliminar remitentes no relacionados para dejar espacio a un requisito no verificado.
Verificar la propiedad y DKIM como registros separados
Utilice la Administración de dominios para identificar el dominio de envío de correo electrónico deseado y sus entradas DNS esperadas. El Guía DNS distingue la clave de validación del dominio de su DomainKey. El valor de validación establece la propiedad del envío; el valor DKIM admite la firma de mensajes. Conserve ambos propósitos en la hoja de trabajo en lugar de tratar cualquier registro TXT que contiene un valor Salesforce como evidencia intercambiable.
Copie los valores de la cuenta real. Guarde el propietario del registro completo, el tipo, el valor y la fecha de instrucción antes de realizar el cambio DNS . Compruebe si otra cuenta de Account Engagement o un servicio diferente ya depende del mismo propietario. No sobrescriba un registro conflictivo, no reutilice el valor de otro cliente ni cambie un selector a un nombre inventado. Solicite soporte para una resolución compatible cuando los acuerdos de cuentas entren en conflicto.
Mantenga el dominio de envío de correo electrónico distinto del dominio de seguimiento. Salesforce advierte explícitamente contra el uso del dominio idéntico para esas dos funciones. Un nombre de host de seguimiento de marca no es lo mismo que el dominio De, incluso cuando ambos comparten un padre. El seguimiento del inventario depende por separado para que el trabajo de autenticación no cambie inadvertidamente las URL de los activos o los enlaces de las campañas.
Publicar la clave de dominio a través del flujo de trabajo documentado
Salesforce's Instrucciones de implementación DKIM requieren el rol de Administrador de Account Engagement. En la aplicación Lightning, abra Configuración de participación de cuenta y luego Administración de dominio. En la interfaz alternativa de Account Engagement, el punto de partida documentado es Administrador. En Dominios de envío de correo electrónico, abra Entradas DNS esperadas para el dominio elegido y copie el valor de DomainKey para publicarlo como TXT .
Utilice el propietario y el valor que se muestran para esa cuenta y dominio. El artículo actual dice que se deben permitir hasta 24 horas para que la firma entre en vigor después de agregar el registro. Trátelo como una guía de sincronización del proveedor, no como una garantía de que cada caché o receptor DNS se actualizará en el mismo instante. Registre el tiempo de publicación y espere el estado esperado antes de juzgar una nueva prueba.
Confirme la respuesta DNS público, incluido el propietario exacto y totalmente calificado. Los editores DNS a veces agregan el nombre de la zona al campo de host, creando un sufijo duplicado cuando se ingresa un nombre completo. Revise la respuesta resultante en lugar de confiar en el formulario de entrada. Guarde cualquier error de administración de dominio y sus detalles para que el soporte pueda investigar la falla real en lugar de un estado parafraseado.
Decidir si se requiere una ruta de retorno personalizada
Salesforce's Artículo de soporte DMARC describe DKIM alineado como la ruta DMARC normal y explica que la ruta predeterminada camino de retorno El dominio no se alinea con el Desde visible. También documenta una solicitud de ruta de retorno personalizada asistida por soporte. La limitación indicada es un dominio de ruta de retorno personalizado fijo por unidad de negocio, en lugar de un dominio variable seleccionado para cada mensaje.
Antes de solicitar esta opción, identifique el requisito comercial. Una organización que necesita SPF y DKIM alineados debe evaluar la disposición real del dominio y el modo de alineación con soporte. Una unidad de negocio que envía marcas no relacionadas no debe asumir que una ruta de retorno fija puede alinearse con cada dominio De. Mantenga abierta esa pregunta de diseño hasta que las identidades observadas y la configuración admitida la resuelvan.
Obtenga los registros DNS exactos del caso de soporte y haga que el propietario DNS revise los conflictos y dependencias. Este artículo no proporciona un destino de ruta de retorno personalizado universal ni un interruptor de activación. Publicar registros adivinados o copiar la configuración del dominio de rebote de otro producto puede interrumpir una ruta de trabajo sin satisfacer el requisito.
Pruebe el remitente seleccionado a través del flujo de mensajes real
Envíe mensajes controlados e inofensivos a través de cada dominio de envío y ruta de unidad de negocio sustancialmente diferentes. Utilice la misma selección de remitente que la campaña o automatización planificada. Registre la referencia de la campaña, el ID del mensaje, la hora UTC y el destinatario de la prueba externa. Si una función de vista previa o prueba utiliza una ruta diferente a la de producción, resuelva esa diferencia antes de tratarla como evidencia representativa.
En el sistema receptor confiable, capture From, Return-Path y todos los selectores y dominios de firma DKIM . RFC 6376 define los valores d= y s= utilizados para localizar la clave de verificación pública. Compare el dominio de firma observado con el dominio de envío configurado. Un registro DNS puede ser correcto mientras un mensaje todavía utiliza un remitente inesperado u otra ruta.
Aplicar RFC 9989 a los resultados reales. DMARC puede pasar a través de un paso alineado firma DKIM o pasar SPF alineado. Registre qué mecanismo proporcionó el resultado y qué modo de alineación se aplicó. Mantenga la autenticación SPF , la alineación SPF , la autenticación DKIM y la alineación DKIM en campos separados. Esto evita que un único estado verde oculte un requisito no probado.
Solucionar problemas del límite defectuoso en lugar de cambiar todos los controles
Si el dominio de envío no está verificado, compare su clave de validación y el propietario exacto DNS con las entradas DNS esperadas. Si falta DKIM después del período de activación esperado, confirme el dominio y la cuenta seleccionados y luego verifique los errores de administración del dominio. Si falla una firma, verifique el selector y el valor público e inspeccione cualquier sistema posterior que cambie el mensaje después de la firma.
Si DMARC falla mientras pasa SPF , investigue la alineación y si se configuró DKIM alineado para ese remitente. No trate el éxito predeterminado SPF como una promesa de éxito de DMARC . Si se trata de una ruta de devolución personalizada, compare la identidad del sobre observada con la configuración fija de la unidad de negocio y las instrucciones proporcionadas por el soporte. Conserve un mensaje fallido representativo para el diagnóstico.
Mantener la política DMARC de la organización y los destinos de informes bajo su propiedad actual. El artículo Salesforce describe la necesidad de un monitoreo DMARC externo en lugar de que Account Engagement recopile esos datos. informes de fallas. El trabajo de autenticación DNS no debe reemplazar silenciosamente los destinos de informes ni reducir la aplicación de la ley a remitentes no relacionados. Revise cualquier cambio de política propuesto por separado con los propietarios del correo y de la seguridad.
Hoja de trabajo del dominio de participación de la cuenta
- Cuenta, unidad de negocio, marca y flujo de trabajo de envío: ____.
- Dirección de remitente seleccionada y dominio de envío de correo electrónico configurado: ____.
- Dominio de seguimiento separado y sus dependencias existentes: ____.
- Clave de validación y referencias de registros DKIM de las entradas DNS esperadas: ____.
- Respuestas DNS público, hora de publicación y estado de gestión: ____.
- Diseño de ruta de retorno personalizado predeterminado o asistido por soporte: ____.
- Limitación de la ruta de retorno personalizada y confirmación de soporte cuando corresponda: ____.
- ID de mensaje de prueba, hora UTC, origen, Return-Path e identidades DKIM : ____.
- Resultados de autenticación confiables y mecanismo DMARC alineado: ____.
- Excepciones, seguimiento propietario y recuperación aprobada: ____.
Ejemplo ficticio de éxito SPF sin alineación
Solo caso escrito ficticio: AE-01 asume que la unidad de negocios Norte envía como news@example.org y la unidad de negocios Sur envía como news@example.net . Una ruta de retorno personalizada fija propuesta en bounce.example.org puede alinearse con la primera en una alineación SPF relajada, pero no se puede suponer que se alinee con la segunda no relacionada. Las firmas DKIM y los resultados SPF siguen siendo desconocidos, por lo que ninguna ruta tiene un veredicto DMARC afirmado. Los propietarios de marketing y correo deben separar la configuración de la unidad de negocios y validar DKIM alineado por dominio De origen seleccionado antes de solicitar cualquier edición SPF raíz. Todas las identidades y disposiciones están inventadas; no se ejecutó ningún caso de soporte, consulta DNS o mensaje.
Mantenga la finalización ligada a evidencia viva
El flujo de trabajo documentado no verifica los permisos de un inquilino real, los valores generados o la capacidad de ruta de retorno personalizada. Esas verificaciones de cuentas, DNS en vivo y verificación de encabezados, revisión visual y aprobación humana de las PYME siguen pendientes. Esta guía no está publicada y no debe presentarse como prueba de que las campañas de una organización están autenticadas en producción.
Separar un mensaje pasajero de la preparación para hacer cumplir la ley
RFC 9989 Sección 7.4 requiere DKIM válido para un dominio que publica 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.