HubSpot: autenticar el correo (DKIM, SPF y DMARC)

hs1._domainkey.ejemplo.es.  CNAME  ejemplo.es.hs1._domainkey.hubspotemail.net.
hs2._domainkey.ejemplo.es.  CNAME  ejemplo.es.hs2._domainkey.hubspotemail.net.

DMARC pasa solo con DKIM

Aquí es donde la mecánica de DMARC juega a favor de la configuración. DMARC solo valida un mensaje si SPF o DKIM pasa y se alinea — una de las dos condiciones basta. En HubSpot, DKIM se alinea; SPF no. El mensaje pasa por tanto DMARC sobre la base del solo DKIM, lo que es perfectamente conforme y suficiente.

Esta asimetría tiene un límite que conviene conocer: la redundancia es menor. Donde una disposición de doble alineación (SPF y DKIM) sobrevive a la pérdida de uno de los dos, un envío de HubSpot se sostiene solo por DKIM. Si una pasarela intermedia reescribe el cuerpo del mensaje e invalida la firma, nada rescata el mensaje — SPF, no alineado, no puede tomar el relevo. En la práctica, en tráfico de marketing directo (sin redirección ni lista de difusión en cascada), este caso sigue siendo raro, y DKIM aguanta. Los ejemplos de registros DMARC comentados muestran cómo fijar la consigna _dmarc una vez DKIM en su sitio. Bajo DMARCbis, el dominio organizativo que sirve de referencia se determina mediante el DNS Tree Walk, sin cambio para este razonamiento.

El único caso en que la asimetría de DKIM-solo muerde de verdad es el de los mensajes retransmitidos: una redirección automática, una lista de difusión que reescribe el asunto o añade un pie. Allí, la firma DKIM puede caer, y sin SPF alineado de reserva, el mensaje falla DMARC. El protocolo ARC se diseñó para este caso preciso — permite a un intermediario de confianza atestiguar la autenticación de origen —, pero no todos los destinatarios lo evalúan aún. En correo de marketing enviado directamente a los suscriptores, el asunto sigue siendo teórico; se vuelve real en cuanto se intercalan retransmisiones.

No «arreglar» SPF por error

El error más frecuente en torno a HubSpot consiste en añadir include:_spf.hubspot.com (o equivalente) al registro SPF raíz del dominio, creyendo así alinear SPF. Es inútil y contraproducente. Inútil, porque la alineación SPF depende del dominio de sobre, no de los include del SPF raíz: mientras el sobre permanezca en hubspotemail.net, ningún include alineará nada. Contraproducente, porque cada include consume una de las diez consultas DNS que SPF autoriza — y un registro que apila servicios por reflejo acaba disparando un permerror que invalida SPF para todo el dominio, incluido el correo que sí se alineaba.

La regla es, pues, clara: en HubSpot, no se toca el SPF raíz para las campañas. Uno se apoya en DKIM, vigila el límite de diez consultas DNS de SPF para los demás servicios, y deja al sobre de HubSpot vivir su vida sin tratar de alinearlo.

Los errores de configuración habituales

Varias trampas reaparecen en el corpus de informes que el analizador DMARC gratuito procesa a diario.

Esperar que SPF se alinee. El más común: un informe muestra SPF «fail» (en el sentido de alineación) sobre el tráfico de HubSpot, y uno trata de corregir un defecto que no lo es. En cuanto DKIM se alinea, DMARC pasa.

Añadir HubSpot al SPF raíz. Descrito más arriba: sin efecto sobre la alineación, con el riesgo del permerror.

Publicar los CNAME sin conectar el dominio en HubSpot. Como en otras plataformas, esta debe constatar la propagación y marcar el dominio de envío como autenticado antes de que las firmas se apliquen realmente.

Endurecer la política sin verificar DKIM. Pasar a p=reject imaginándose cubierto cuando los CNAME no se han propagado equivale a rechazar las propias campañas.

Confundir el dominio conectado con el dominio del From. El dominio autenticado en HubSpot debe corresponder al que se muestra en la dirección de remitente de las campañas; enviar bajo un From @ejemplo.es mientras solo otro dominio está conectado deja ese tráfico sin DKIM alineado, y DMARC falla para esos envíos.

IP compartida, IP dedicada y reputación de marketing

HubSpot envía por defecto desde un pool de IP compartido, mancomunado entre clientes. Para volúmenes altos, se ofrece una IP dedicada como opción: la reputación pertenece entonces solo a la cuenta, pero se construye — una IP nueva debe calentarse, subirse en volumen de forma progresiva a lo largo de varios días, so pena de ser tratada como sospechosa por los proveedores destinatarios. Esta elección no tiene efecto sobre la alineación DMARC — DKIM se alinea de la misma forma sea cual sea la IP emisora — pero pesa en la entregabilidad, y por tanto en lo que muestran las tasas de entrega de los informes.

El tráfico de marketing tiene además un perfil de envío particular: volúmenes en picos, tasas de baja y de queja más altas que el correo transaccional. Por eso a menudo es sensato enviar las campañas desde un subdominio dedicado en lugar del dominio raíz, para aislar la reputación de marketing de la del correo humano. Esta separación no cambia nada de la mecánica DKIM descrita más arriba: el selector firma a nombre del subdominio conectado, que se alinea en modo relajado con el dominio organizativo — y el dominio raíz, el de las personas, conserva una reputación aparte.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la consola de HubSpot, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua=, los informes agregados llegan en unos días y detallan, fuente por fuente, qué se alinea y qué falla. La lectura de los informes DMARC agregados confirma el caso esperado para HubSpot: en la fuente de HubSpot, DKIM alineado, SPF no alineado — y es un resultado correcto, no un defecto, mientras la columna DKIM esté verde.

Basta una cadencia sencilla: una primera lectura unos días después de publicar el registro _dmarc, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. El tráfico de HubSpot se reconoce pronto por sus rangos de direcciones estables; no se trata de perseguir un SPF no alineado, esperado aquí, sino de verificar que DKIM aguanta sobre el conjunto de las campañas antes de endurecer. Una vez confirmado eso durante varios días, el paso a p=reject se hace sin riesgo para el tráfico de HubSpot. El analizador en línea recompone este estado a partir de los registros publicados y de los informes recibidos, y sitúa el dominio en el camino que lleva a p=reject.