Campaign Monitor autentica un dominio de envío mediante la configuración de la cuenta, DNS público y una verificación de verificación. Utilice el dominio exacto que aparecerá en la dirección De, incluido su subdominio. Esta es una configuración específica del remitente: la autenticación de Campaign Monitor no autentica otro servicio que utilice el mismo dominio de marca.
Establecer la identidad y cambiar de propietario
Confirme que la organización controla el dominio previsto y que el operador DNS puede cambiar su zona autorizada. Guardar existente selector, SPF y Registros DMARC. Identifique otros remitentes legítimos antes de aceptar cualquier reemplazo de política sugerido. Mantenga a la persona que configura las campañas y a la persona que publica DNS alineadas en todo el dominio, no solo en una etiqueta corta como correo.
El guía de dominio de envío dice que autenticar un dominio de segundo nivel no autentica sus subdominios en la plataforma. Si las campañas utilizan news.example.com , agregue ese dominio exacto en lugar de asumir que example.com cubre la configuración de la cuenta.
Configurar el dominio y la clave generada
Abra el menú de perfil, Configuración de la cuenta y luego Envío de dominios. Elija Configurar un dominio de envío o Agregar dominio, ingrese el dominio completo y continúe. Publique el nombre y el valor TXT generado en DNS autorizado, utilizando la convención de nombre completo o nombre relativo correcta del editor. Regrese a Campaign Monitor y seleccione He agregado los registros o Vuelva a verificar el registro si regresa más tarde.
Utilice una clave recién generada para esta configuración en lugar de importar una clave privada existente por conveniencia. Mantenga el material de firma privado fuera de DNS , tickets y hojas de trabajo compartidas. Si un selector generado choca con otro registro activo, resuelva el conflicto antes de reemplazarlo. Los ejemplos públicos no son la clave de su cuenta.
Preservar DMARC y conciliar SPF cuidadosamente
El flujo de trabajo documentado acepta un documento válido existente. DMARC configuración. Mantenga su política de aplicación y destinos de informes a menos que el propietario del dominio apruebe un cambio por separado. Cuando no se aplique ninguna política, establezca una con el propietario correcto. A p=none Un ejemplo es una solicitud de supervisión, no una aplicación de la ley ni una razón para debilitar una política heredada de uno de los padres.
Campaign Monitor recomienda la autorización SPF opcional mediante include:_spf.createsend.com. Si esa autorización es apropiada para su configuración, combínela en la única política SPF existente en lugar de agregar una segunda. Conserve otros remitentes legítimos y verifique la ruta de dependencia evaluada con el límite de búsqueda de SPF . el proveedor descripción general de la autenticación de correo electrónico proporciona contexto, pero el sobre recibido determina qué dominio verifica realmente el receptor.
Un pase SPF para un sobre propiedad del servicio no necesariamente está alineado con su nombre visible. Un paso alineado firma DKIM puede satisfacer DMARC incluso cuando esa ruta SPF no está alineada. No prometas SPF estricto alineación simplemente porque se agregó una inclusión al dominio De registro TXT.
Verificar registros antes de la prueba de campaña
Consulte el selector generado en cada servidor autorizado y luego inspeccione las respuestas DMARC y SPF aplicables. Registre el propietario completo, tipo, valor y marca de tiempo. Un editor DNS puede dividir un valor TXT largo en cadenas de caracteres dentro de un registro; que difiere de publicar múltiples DKIM archivos. Siga el manejo del proveedor de DNS y compare el valor reconstruido.
Si Campaign Monitor no puede realizar la verificación, verifique si hay un sufijo de dominio duplicado, un tipo de registro incorrecto, caracteres clave omitidos y desacuerdos con el servidor autorizado. El TTL es un control de almacenamiento en caché, no un momento garantizado en el que se actualiza cada validador. Una respuesta negativa almacenada en caché puede durar más que el momento en que se crea un nuevo registro.
Confirme que la campaña real utiliza el dominio previsto
Envíe una campaña de prueba controlada con la dirección De recién autenticada. Preservar la confianza Authentication-Results, De, Return-Path y todos los pares DKIM d=/s= . Confirme que una firma aprobada se alinee con el dominio De en el modo configurado. Si la prueba pasa pero una campaña posterior falla, compare las direcciones y rutas del remitente antes de modificar DNS .
Caso ilustrativo: example.com está configurado, pero una campaña usa news.example.com , que nunca se agregó a la cuenta. Corrija la configuración del dominio para la identidad real de la campaña; no reemplace una clave de dominio principal válida para resolver una configuración de identidad diferente.
Conserve el remitente que trabajaba anteriormente hasta su aceptación, cuando sea posible. Vuelva a verificar después de cambios de cuenta, nuevos subdominios de envío, migraciones DNS o rotación de claves. Antes de retirarlas, detenga las campañas programadas y confirme que ya no se utilizan las dependencias. Este artículo es una guía documental y un plan de verificación propuesto, no evidencia de una prueba de Campaign Monitor en vivo o entrega garantizada.
No confunda una brecha en el alcance del producto con una alineación estricta
El caso escrito CM-01 supone que el producto tiene configurado example.com pero la campaña De es news@news.example.com . Estipule por separado una firma DKIM de aprobación confiable d=example.com, s=demo1. Con una alineación normal y relajada del dominio organizacional, esa firma puede alinearse con news.example.com ; con adkim=s no coincide exactamente. Se desconocen SPF y otras firmas, por lo que el veredicto general del modo estricto no está resuelto, no es una falla DMARC establecida. Ninguna premisa prueba que Campaign Monitor tenga configurado el subdominio deseado. El propietario de la campaña debe completar la configuración del dominio exacto e inspeccionar la campaña controlada resultante antes del lanzamiento. Estos son aportes ficticios, no una entrega capturada o una razón para flexibilizar la política.
Preservar el límite de aplicación
RFC 9989 La sección 7.4 requiere DKIM válido, no solo SPF , para los dominios que publican p=reject, y advierte sobre la interoperabilidad del correo indirecto y de las listas de correo. Una sola prueba exitosa de mensajes directos no es prueba de que todas las rutas legítimas estén listas para una política más fuerte. Mantener la protección aprobada existente mientras se diagnostica la brecha real; cualquier cambio de política necesita su propia decisión.