Aller au contenu
DMARC
← Blog

HubSpot : authentifier l'e-mail (DKIM, SPF et DMARC)

Par Thomas · RSSI virtuel · 09 septembre 2026

HubSpot est d'abord une plateforme marketing : envois de campagnes, e-mails automatisés, séquences de nurturing, le tout adossé à un CRM. Cette nature marketing a une conséquence sur l'authentification que beaucoup découvrent en lisant leurs premiers rapports DMARC : chez HubSpot, l'alignement repose entièrement sur DKIM, car SPF, lui, ne s'aligne pas. Comprendre pourquoi évite une erreur de configuration très répandue — celle qui consiste à « réparer » un SPF qui n'a jamais eu vocation à s'aligner.

Par défaut, un domaine connecté à HubSpot émet sous l'identité de la plateforme. La signature ne porte pas le domaine affiché, l'enveloppe est au domaine technique de HubSpot, et une politique p=reject rejette ce trafic pourtant légitime. La configuration de l'authentification — la « connexion du domaine d'envoi » dans les réglages HubSpot — pose deux enregistrements DKIM qui suffisent à faire passer DMARC. Le reste tient à bien comprendre ce que SPF fait, et surtout ce qu'il ne fait pas, dans ce montage.

Ce guide détaille les deux CNAME DKIM, la raison pour laquelle SPF ne s'aligne pas, la façon dont DMARC valide malgré tout sur DKIM seul, l'erreur d'ajouter HubSpot au SPF racine, puis les pièges de configuration courants et la contre-épreuve par les rapports RUA.

Les deux CNAME DKIM

L'authentification DKIM de HubSpot repose sur deux enregistrements CNAME posés dans la zone du domaine d'envoi. Depuis les réglages, à la connexion d'un domaine, HubSpot génère et affiche les valeurs exactes à publier — de la forme :

hs1._domainkey.exemple.fr.  CNAME  exemple.fr.hs1._domainkey.hubspotemail.net.
hs2._domainkey.exemple.fr.  CNAME  exemple.fr.hs2._domainkey.hubspotemail.net.

Deux sélecteurs, hs1 et hs2, sont provisionnés d'emblée : la logique est celle d'une délégation par CNAME, identique dans son principe à d'autres grandes plateformes. La clé publique n'est pas copiée dans la zone du domaine, elle vit chez HubSpot, et le CNAME fait le pont. Deux sélecteurs permettent la rotation des clés sans intervention manuelle sur la zone — HubSpot peut générer une nouvelle paire et basculer d'un sélecteur à l'autre côté plateforme.

L'essentiel pour DMARC : la signature apposée porte d=exemple.fr, le domaine organisationnel lui-même. L'alignement DKIM est donc acquis dès la propagation des deux CNAME et la validation dans la console. C'est ce mécanisme, et lui seul, qui fera passer DMARC.

Pourquoi SPF ne s'aligne pas

Voici le point qui déroute. L'adresse d'enveloppe des campagnes HubSpot — le Return-Path, ce que SPF vérifie réellement — reste au domaine technique de HubSpot (hubspotemail.net). SPF authentifie bien ce domaine : HubSpot y publie l'autorisation de ses serveurs. Mais il s'aligne avec hubspotemail.net, pas avec exemple.fr. Du point de vue de DMARC, SPF passe sans s'aligner — et un mécanisme qui passe sans s'aligner ne compte pas.

Contrairement à des plateformes qui proposent un Return-Path personnalisé (un CNAME de rebond au domaine du client), HubSpot ne déplace pas l'enveloppe vers le domaine de l'expéditeur pour ses envois marketing. Il n'y a donc pas de levier pour aligner SPF : c'est un choix d'architecture de la plateforme, pas une case à cocher oubliée. Chercher à forcer l'alignement SPF chez HubSpot revient à courir après quelque chose qui n'existe pas dans ce montage.

DMARC passe sur DKIM seul

C'est ici que la mécanique de DMARC joue en faveur de la configuration. DMARC ne valide un message que si SPF ou DKIM passe et s'aligne — une seule des deux conditions suffit. Chez HubSpot, DKIM s'aligne ; SPF non. Le message passe donc DMARC sur la foi du seul DKIM, ce qui est parfaitement conforme et suffisant.

Cette asymétrie a une limite qu'il faut connaître : la redondance est moindre. Là où un montage à double alignement (SPF et DKIM) survit à la perte de l'un des deux, un envoi HubSpot ne tient que par DKIM. Si une passerelle intermédiaire réécrit le corps du message et invalide la signature, plus rien ne rattrape le message — SPF, non aligné, ne peut pas prendre le relais. En pratique, sur du trafic marketing direct (sans redirection ni liste de diffusion en cascade), ce cas reste rare, et DKIM tient. Les modèles annotés montrent comment poser la consigne _dmarc une fois DKIM en place. Sous DMARCbis, le domaine organisationnel qui sert de référence se détermine par le DNS Tree Walk, sans changement pour ce raisonnement.

Le seul cas où l'asymétrie DKIM-seul mord vraiment est celui des messages retransmis : une redirection automatique, une liste de diffusion qui réécrit l'objet ou ajoute un pied de page. Là, la signature DKIM peut sauter, et sans SPF aligné en secours, le message échoue DMARC. Le protocole ARC a été conçu pour ce cas précis — il permet à un intermédiaire de confiance d'attester l'authentification d'origine —, mais tous les destinataires ne l'évaluent pas encore. Sur du courrier marketing envoyé directement aux abonnés, le sujet reste théorique ; il devient réel dès que des retransmissions s'intercalent.

Ne pas « réparer » SPF à tort

L'erreur la plus fréquente autour de HubSpot consiste à ajouter include:_spf.hubspot.com (ou équivalent) à l'enregistrement SPF racine du domaine, en croyant ainsi aligner SPF. C'est inutile et contre-productif. Inutile, parce que l'alignement SPF dépend du domaine d'enveloppe, pas des include du SPF racine : tant que l'enveloppe reste en hubspotemail.net, aucun include n'alignera quoi que ce soit. Contre-productif, parce que chaque include consomme une des dix requêtes DNS que SPF autorise — et un enregistrement qui empile des services par réflexe finit par déclencher un permerror qui invalide SPF pour tout le domaine, y compris le courrier qui, lui, s'alignait.

La règle est donc claire : chez HubSpot, on ne touche pas au SPF racine pour les campagnes. On s'appuie sur DKIM, on surveille la limite de dix requêtes DNS du SPF pour les autres services, et on laisse l'enveloppe HubSpot vivre sa vie sans chercher à l'aligner.

Sous-domaine d'envoi et IP dédiée

HubSpot envoie par défaut depuis un pool d'IP partagé, mutualisé entre clients. Pour les gros volumes, une IP dédiée est proposée en option : la réputation n'appartient alors qu'au compte, mais elle se construit — une IP neuve doit être chauffée, montée en volume progressivement sur plusieurs jours, sous peine d'être traitée comme suspecte par les fournisseurs destinataires. Ce choix n'a aucun effet sur l'alignement DMARC — DKIM s'aligne de la même façon quelle que soit l'IP émettrice — mais il pèse sur la délivrabilité, donc sur ce que montrent les taux de remise des rapports.

Le trafic marketing a par ailleurs un profil d'envoi particulier : volumes en pics, taux de désabonnement et de plainte plus élevés que le courrier transactionnel. C'est pourquoi il est souvent judicieux de faire partir les campagnes depuis un sous-domaine dédié plutôt que depuis le domaine racine, afin d'isoler la réputation marketing de celle du courrier humain. Cette séparation ne change rien à la mécanique DKIM décrite plus haut : le sélecteur signe au nom du sous-domaine connecté, qui s'aligne en mode relâché avec le domaine organisationnel — et le domaine racine, celui des personnes, conserve une réputation à part.

Les erreurs de configuration courantes

Plusieurs pièges reviennent dans le corpus de rapports que l'analyseur DMARC gratuit traite au quotidien.

Attendre que SPF s'aligne. Le plus courant : un rapport montre SPF « fail » (au sens alignement) sur le trafic HubSpot, et l'on cherche à corriger un défaut qui n'en est pas un. Dès lors que DKIM s'aligne, DMARC passe.

Ajouter HubSpot au SPF racine. Décrit ci-dessus : sans effet sur l'alignement, au risque du permerror.

Publier les CNAME sans connecter le domaine dans HubSpot. Comme ailleurs, la plateforme doit constater la propagation et marquer le domaine d'envoi comme authentifié avant que les signatures ne soient réellement apposées.

Durcir la politique sans vérifier DKIM. Passer à p=reject en s'imaginant couvert alors que les CNAME ne sont pas propagés revient à rejeter ses propres campagnes.

Confondre le domaine connecté et le domaine du champ From. Le domaine authentifié dans HubSpot doit correspondre à celui affiché dans l'adresse d'expéditeur des campagnes ; envoyer sous un From @exemple.fr alors que seul un autre domaine est connecté laisse le trafic sans DKIM aligné, et DMARC échoue pour ces envois précis.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas la console HubSpot, mais ce que rapportent les destinataires. Une fois l'enregistrement _dmarc publié avec une adresse rua=, les rapports agrégés arrivent sous quelques jours et détaillent, source par source, ce qui s'aligne et ce qui échoue. La lecture des rapports DMARC agrégés confirme le cas attendu pour HubSpot : sur la source HubSpot, DKIM aligné, SPF non aligné — et c'est un résultat correct, pas un défaut, tant que la colonne DKIM est verte.

Une cadence simple suffit : une première lecture quelques jours après la publication de l'enregistrement _dmarc, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. Le trafic HubSpot se reconnaît vite à ses plages d'adresses stables ; l'important n'est pas de traquer un SPF non aligné, attendu ici, mais de vérifier que DKIM tient sur l'ensemble des campagnes avant de durcir. Une fois ce point confirmé sur plusieurs jours, la montée vers p=reject se fait sans risque pour le trafic HubSpot. L'analyseur en ligne recompose cet état à partir des enregistrements publiés et des rapports reçus, et situe le domaine sur le chemin qui mène à p=reject.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.