Confirmar el acuerdo de envío predictivo
Esta guía cubre el flujo de trabajo del servidor de campañas de Predictive Response descrito en su centro de ayuda pública. No se supone que todos los productos predictivos, acuerdos SMTP empresariales o rutas de correo electrónico Salesforce se comporten de la misma manera. Registre la cuenta, el tipo de campaña, el dominio visible desde y el sistema que realmente envía el mensaje. No sustituya la configuración de autenticación propia de Salesforce por una ruta de campaña de terceros sin evidencia de que es la ruta en uso.
La página de capacidad de entrega del proveedor distingue el envío predeterminado del dominio del proveedor del uso del propio dominio del cliente. Indica a los clientes que se pongan en contacto con el soporte después de la publicación. SPF para que los servidores de envío puedan alinearse. Por lo tanto, la publicación DNS es sólo una parte del cambio documentado; sigue siendo necesario un paso del lado del servidor confirmado por soporte. Configuración de capacidad de entrega de respuesta predictiva
Antes de planificar ediciones, capture una prueba de campaña inofensiva y las respuestas DNS autorizadas existentes. Identifique a las personas que controlan DNS , el dominio de envío empresarial, el dirección de rebotey la cuenta predictiva. Solicite las instrucciones específicas de la cuenta corriente donde el material público deja una pregunta abierta. Este manuscrito no representa una respuesta de soporte ni prueba de que una cuenta en particular haya sido actualizada.
Integre SPF sin reemplazar remitentes no relacionados
La ayuda SPF del proveedor identifica include:spf.predictiveresponse.net como su mecanismo de autorización. Sus instrucciones distinguen agregar autorización a una política existente de crear una política donde no existe ninguna e incluyen un paso de verificación de soporte. Úselo como punto de partida para la cuenta y el dominio exactos, no como evidencia de que el sobre actual ya usa la identidad deseada. Configuración SPF de respuesta predictiva
Conserve una póliza SPF con el nombre del propietario correspondiente. No crees un segundo Registro SPF o pegue un segundo mecanismo de terminal en una política existente. Coloque las autorizaciones requeridas en el orden de evaluación previsto y retenga a otros remitentes legítimos. La elección de falla o softfail de la política existente es una decisión de seguridad separada; un ejemplo de proveedor no es la aprobación para debilitarlo. Revise los límites de búsqueda después de los cambios. SPF RFC 7208 secciones 3.2 y 4.6.4
Un validador que muestra SPF sintácticamente válido no prueba que una campaña evalúe ese dominio, que el paso de soporte esté completo o que DMARC se alinea. Registre el propietario consultado, la política devuelta, el tiempo de recolección y el resultado de la prueba. Luego compárelos con el dominio del sobre real de un mensaje recibido. La cadena de evidencia completa debe conectar la autorización, la ruta de envío y la identidad visible.
Preservar la dependencia del procesamiento de rebotes
Predictivos camino de retorno Las instrucciones utilizan una prueba de campaña para identificar el destino de rebote del proveedor específico de la cuenta. Luego, el cliente prepara una dirección de retorno en su propio sistema de correo, le asigna un alias a ese destino identificado y solicita soporte para actualizar la aplicación de envío. La página conecta este acuerdo con el procesamiento de rebotes en Salesforce . Nunca adivine el nombre corto específico de la cuenta ni utilice el destino de otro cliente. Configuración predictiva de la ruta de retorno
Trate esto como un cambio de ruta operativa, no solo como una edición cosmética del remitente. Documente quién es el propietario del alias, qué destino confirmó el soporte y qué sucede si el alias no puede realizar la entrega. Coordine con el propietario de la campaña para comprender los reintentos y el manejo de la supresión. Mantenga la configuración de trabajo anterior disponible para una reversión aprobada hasta que se hayan demostrado tanto la autenticación como el procesamiento de rebote.
Utilice únicamente una prueba de rebote controlada y autorizada o un diagnóstico respaldado por el proveedor para evaluar ese flujo de trabajo. No envíe campañas reales a destinatarios inventados ni altere los datos de supresión simplemente para obtener pruebas. El registro de aceptación debe mostrar la actualización de estado esperada o el resultado del diagnóstico sin exponer públicamente las direcciones de los destinatarios. Una entrega exitosa al destinatario y una ruta de retroalimentación de rebote que funcione son pruebas separadas.
No equiparar DKIM del proveedor con DKIM del cliente alineado
La página de capacidad de entrega revisada dice DKIM se maneja en los servidores del proveedor. No establece un procedimiento actual de generación de selectores de dominios de clientes ni demuestra qué d= dominio utiliza una campaña específica. Por lo tanto, esta guía no inventa DKIM CNAME objetivos, un cambio de dominio personalizado de autoservicio o una afirmación no respaldada de que DKIM del dominio del cliente no está disponible. Esas preguntas quedan para la evidencia específica de la cuenta. Declaración DKIM predictiva
Un mensaje recibido puede llevar una firma de dominio de proveedor válida sin que esa firma se alinee con el dominio visible del cliente. Verificación DKIM y DMARC alineación responder diferentes preguntas. Registre el dominio de cada firma y selector, los resultados del receptor y si alguna firma aprobada se alinea. Una ruta SPF de paso alineada también puede satisfacer DMARC , pero solo si el dominio del sobre evaluado y la relación From cumplen con el modo aplicable. DKIM RFC 6376 DMARC RFC 9989
No cambie la política DMARC de todo el dominio simplemente porque un proveedor dice que maneja DKIM . Pregunte qué identidad exacta está autenticada y pruébela. Si no se establece una ruta alineada compatible, mantenga pendiente la implementación del dominio personalizado y decida con el propietario de la empresa si es apropiada una ruta autorizada del dominio del proveedor u otra configuración compatible.
Hoja de trabajo de aceptación de campaña predictiva
Complete un registro para cada cuenta distinta y ruta de envío.
- Contexto de la campaña: cuenta, tipo de campaña, propietario de la empresa, servicio del remitente real y dominio de origen previsto.
- Cambio SPF : política actual, autorización propuesta, dominio del sobre que lo requiere, respuestas DNS autorizadas, revisión de búsqueda y cambio de propietario.
- Punto de control de soporte: referencia del ticket, cambio exacto solicitado en el lado del servidor, cuenta y dominio confirmados por soporte, tiempo de finalización y preguntas sin resolver.
- Ruta de rebote: dirección de ruta de retorno del cliente, destino específico de la cuenta, propietario del alias, diagnóstico controlado y evidencia de procesamiento esperada Salesforce .
- Identidad recibida: marca de tiempo de prueba, receptor confiable, visible desde, Return-Path , todos los dominios y selectores DKIM , resultado SPF , resultados DKIM y ruta de paso alineada.
- Decisión de lanzamiento: funciones restantes no compatibles, plan de reversión, aprobación comercial, revisión humana de las PYME y revisión de la presentación editorial. Estos son campos de aceptación en blanco, no resultados activos.
Diagnóstico ficticio de un cambio DNS completo pero configuración inacabada
Este escenario es ficticio. Un administrador de marketing publica la autorización SPF documentada y un validador DNS informa una política válida. La siguiente campaña todavía muestra un dominio de sobre de proveedor y falla DMARC para el dominio De del cliente. Un proveedor válido firma DKIM aparece, pero su dominio de firma tampoco se alinea.
El equipo verifica el registro de cambios y descubre que nadie completó el punto de control de soporte. El siguiente paso propuesto es confirmar la disposición del sobre del cliente admitida, validar el alias de rebote para esa cuenta y hacer que el soporte complete la configuración autorizada. Sólo una nueva campaña recibida y un diagnóstico de rebote controlado pueden establecer el resultado. La verificación de sintaxis original no demostró la alineación ni el manejo de rebotes Salesforce .
Puertas de evidencia y publicación.
Se recuperó y revisó la documentación pública de configuración propia. No se inspeccionó ni modificó ninguna cuenta predictiva, ticket de soporte, DNS del cliente, buzón de correo de rebote, registro Salesforce o mensaje recibido del cliente. La aplicabilidad de la cuenta actual, la activación del lado del servidor, los resultados alineados y el procesamiento de rebotes siguen siendo puertas activas. La aprobación de Human SME y la revisión de la presentación realizada están pendientes. El título más amplio de configuración completa se mantiene hasta que se resuelvan las preguntas DKIM y la ruta exacta; el borrador es inédito.
Distinguir un alias de una receta de ruta de retorno DNS
La configuración de rebote documentada utiliza una dirección de correo del cliente que se reenvía a la dirección de procesamiento específica de la cuenta. No proporciona una receta universal DNS CNAME . Mantenga el propietario del alias y el cambio de la aplicación confirmada por soporte en el mismo ticket y deje la capacidad DKIM de dominio personalizado sin resolver hasta que el proveedor proporcione la evidencia aplicable.
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.