El correo electrónico de marketing HubSpot y el buzón conectado de un vendedor son formas de envío diferentes. Comience por identificar el flujo de trabajo que está configurando. La autenticación de un dominio de envío de marketing no establece el estado de cada mensaje asociado con el CRM.
Esta guía trata sobre el dominio de envío de correo electrónico utilizado para el correo electrónico de marketing HubSpot . Registre la cuenta relevante, el dominio De y su propietario comercial antes de realizar cambios.
Elija un dominio que se ajuste al flujo de trabajo
Lea la guía de elegibilidad de dominio actual antes de seleccionar el nombre. Las instrucciones actuales de HubSpot dicen que un dominio de envío de correo electrónico no debe estar en uso para otro propósito, como alojar contenido. Un subdominio adecuado puede mantener esta ruta distinta, pero aún necesita un propietario explícito y una configuración probada.
Verifique el dominio exacto utilizado en la dirección De marketing con la conexión de dominio de envío propuesta. Un nombre nuevo que se parezca a la marca aún puede ser el nombre incorrecto para la campaña real.
Mapea los otros usos del dominio o subdominio: contenido alojado, recepción de correo, redireccionamientos, otra cuenta HubSpot y servicios externos. Resuelva los conflictos antes de aceptar un cambio DNS generado.
Revisar la solicitud DNS generada como un conjunto de cambios
Utilice el flujo de trabajo de conexión de envío de correo electrónico actual y los valores generados para la cuenta. La guía de HubSpot cubre MX , DKIM, SPF y DMARC, con detalles que deben verificarse en los nombres de sus propietarios especificados.
No mover el buzón normal de la organización Registros MX simplemente porque un flujo de trabajo del remitente muestra un requisito MX . Establezca el nombre exacto y el propósito en la solicitud generada. Un cambio específico de un subdominio y un cambio de dominio raíz tienen consecuencias diferentes.
Para SPF , inspeccione la política existente en el nombre exacto que se está cambiando. Si ya existe una, concilie la autorización necesaria en esa política en lugar de crear una segunda política SPF allí. Coloque el mecanismo de autorización antes del mecanismo de terminación de todos y asegúrese de que la evaluación resultante siga siendo válida y dentro del límite de búsqueda dependiente del DNS.
Trate DMARC como una decisión política del propietario del dominio. Preservar una política adecuada existente y una configuración de informes. Una configuración de marketing no debe restablecer los controles del correo no relacionado.
Compruebe cómo DNS publica los valores
Identifique el host autorizado activo en lugar de depender del nombre de un registrador. Compare los nombres y valores completos de los propietarios resultantes después de la publicación.
HubSpot menciona específicamente el proxy Cloudflare y la configuración de aplanamiento de CNAME en todo el dominio. Siga los requisitos admitidos actualmente para los registros de autenticación y evalúe cualquier cambio DNS más amplio por separado. No cambie el comportamiento del sitio web no relacionado simplemente para borrar una advertencia de configuración de correo electrónico.
Para una conexión automática, revise los cambios y registre lo que realmente se escribió. Para una conexión manual, verifique el manejo de sufijos y los conflictos de tipos de registros. Ambos caminos necesitan respuestas públicas observables.
Verificar el mensaje de marketing real
Complete las comprobaciones de autenticación de HubSpot y luego envíe una prueba de campaña controlada adecuada a través de la ruta prevista. Mantenga el mensaje recibido original, el contexto de la cuenta y la hora de envío.
Inspeccione los resultados visibles del remitente, la identidad del sobre, el dominio de firma DKIM y el receptor confiable. Registre el alineación ruta que soporta DMARC . Una firma aprobada para un dominio de servicio no relacionado no es suficiente por sí sola.
En un caso sintético, el equipo DNS conecta con éxito un subdominio de marketing, pero la campaña aún utiliza la antigua dirección De origen del dominio raíz. La configuración y el mensaje describen identidades diferentes. Corrija la configuración del remitente previsto y luego repita la prueba de ruta de campaña en lugar de agregar registros a cada nombre plausible.
No generalice una prueba a cada buzón conectado, ruta transaccional o servicio integrado. Pruebe los flujos de trabajo que sean importantes para el alcance de este cambio.
Preservar un registro de finalización útil
La entrega debe identificar la cuenta, el dominio de envío seleccionado, los registros generados, el cambio de propietario DNS y el mensaje verificado. Incluya el motivo de la elección del dominio y cualquier otra cuenta que lo utilice.
Revise la configuración cuando cambie la propiedad de la campaña o se introduzca un nuevo subdominio. Mantenga las dependencias antiguas hasta que se haya verificado el retiro en lugar de eliminarlas tan pronto como se realice una nueva campaña.
Utilice el inventario de remitentes para conectar la propiedad del marketing con el programa de correo más amplio. La autenticación establece una ruta de identidad; el permiso para contactar a los destinatarios, la calidad de la lista y la ubicación de la bandeja de entrada siguen siendo asuntos separados.
Separe la corrección del remitente de un cambio de política
El caso escrito HS-01 supone que la cuenta de marketing tiene news.example.com conectada, mientras que la campaña planificada De es updates@example.com . Un resultado hipotético de mensaje confiable es el pase DKIM con d=news.example.com, s=demo1. Esa firma puede alinearse bajo una alineación relajada ordinaria del dominio organizacional, pero no se alinea exactamente con la raíz bajo adkim=s. SPF y todas las demás firmas siguen siendo desconocidas, por lo que no informe una falla general DMARC en modo estricto. El propietario del marketing debe confirmar el origen previsto y la conexión del producto coincidente, y luego obtener una muestra de campaña autorizada; cambiar la política de todo el dominio no es la reparación propuesta aquí. El buzón de correo MX normal del personal en example.com permanece fuera de este cambio. No se probó ninguna cuenta, buzón o DNS HubSpot .
Utilice los valores y propietarios de registros generados, en lugar de convertir ejemplos de solución de problemas en selectores universales. Actualmente, HubSpot documenta CNAME DKIM emparejados y una combinación de SPF cuando existe una política. Sus etiquetas de estado describen comprobaciones de configuración; Incluso una etiqueta completamente autenticada no prueba que esta campaña planificada haya seleccionado la identidad De correcta.
Preservar el límite de aplicación
RFC 9989 La sección 7.4 requiere DKIM válido, no solo SPF , para la publicación de dominios p=rejecty 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.