Salesforce : DKIM et alignement DMARC des différents clouds

<sélecteur1>._domainkey.exemple.fr.  CNAME  <sélecteur1>.<clé>.dkim.sfdc.net.
<sélecteur2>._domainkey.exemple.fr.  CNAME  <sélecteur2>.<clé>.dkim.sfdc.net.

L'alignement DMARC repose sur DKIM

DMARC ne valide un message que si SPF ou DKIM passe et s'aligne avec le domaine du champ From. Pour chaque cloud Salesforce correctement configuré, c'est DKIM qui porte l'alignement : la signature d=exemple.fr (Sales/Service) ou celle du sous-domaine SAP (Marketing Cloud) s'aligne avec le domaine du From, en mode relâché pour un sous-domaine, en strict pour le domaine lui-même.

SPF, lui, est plus délicat. Selon la configuration de gestion des rebonds, l'enveloppe des messages Salesforce peut rester à un domaine de la plateforme, auquel cas SPF passe sans s'aligner — et ne compte pas. S'appuyer sur DKIM est donc le choix fiable et recommandé pour Salesforce. Les exemples commentés, balise par balise montrent comment poser la consigne _dmarc une fois les clouds authentifiés. Sous DMARCbis, le domaine organisationnel de référence se détermine par le DNS Tree Walk, sans changement pour ce raisonnement.

Le budget de dix requêtes DNS du SPF

Un piège spécifique à Salesforce mérite une section. Beaucoup de guides recommandent d'ajouter include:_spf.salesforce.com à l'enregistrement SPF racine du domaine. Or cet include est lourd : il en imbrique d'autres, et consomme à lui seul plusieurs des dix requêtes DNS que SPF autorise avant de basculer en permerror. Combiné à d'autres services (une suite bureautique, un ESP), il fait vite dépasser le plafond — et un permerror invalide SPF pour tout le domaine, y compris le courrier qui s'alignait.

Deux conséquences pratiques. D'abord, ajouter cet include n'aligne pas SPF pour autant si l'enveloppe reste à un domaine Salesforce : on paie le coût sans le bénéfice. Ensuite, quand SPF n'est pas le mécanisme d'alignement retenu (et il ne l'est pas, ici, au profit de DKIM), l'include Salesforce est souvent superflu. Surveiller la limite de dix requêtes DNS du SPF est d'autant plus utile dans un environnement Salesforce que la tentation d'empiler les include y est grande.

Le sous-domaine du Marketing Cloud

Le Sender Authentication Package du Marketing Cloud mérite qu'on s'y arrête, car c'est la configuration la plus complète des clouds Salesforce. Le SAP provisionne un sous-domaine dédié — souvent de la forme mkt.exemple.fr — qui devient le domaine d'expédition des campagnes : SPF, signature DKIM et domaine de suivi des liens y sont tous rattachés. L'alignement y est donc double, SPF et DKIM, en mode relâché vis-à-vis de exemple.fr, ce qui apporte la redondance qui protège en cas de redirection.

Cette complétude a une contrepartie : le SAP se configure une fois, et son sous-domaine dédié doit rester réservé au Marketing Cloud. Le mélanger avec d'autres usages, ou changer de sous-domaine sans reprendre la configuration, casse l'ensemble. Pour une organisation qui diffuse à grande échelle, c'est néanmoins l'assise la plus solide — et la plus lisible dans les rapports, où le sous-domaine apparaît comme une source nette et alignée, facile à distinguer du trafic Sales/Service.

Relais d'e-mails et gestion des rebonds

Deux réglages Salesforce touchent indirectement à l'authentification et méritent d'être connus. Le premier, l'Email Relay, fait transiter le courrier Salesforce par le serveur SMTP de l'organisation avant remise : dans ce montage, l'e-mail sort de l'infrastructure interne, hérite de son SPF et de sa réputation, et l'alignement se raisonne alors comme pour n'importe quel serveur maison — un cas différent de l'envoi direct par Salesforce. Le second, la gestion des rebonds, détermine le domaine d'enveloppe des messages : selon qu'elle est activée ou non, le Return-Path penche vers un domaine Salesforce ou vers celui de l'organisation, ce qui change l'alignement SPF.

Ces réglages ne remplacent pas DKIM — qui reste le mécanisme d'alignement fiable — mais ils expliquent pourquoi deux organisations sous Salesforce peuvent voir des résultats SPF différents dans leurs rapports. Comprendre lequel est en place évite de chercher un défaut d'alignement SPF là où il n'y a qu'un choix de configuration de rebonds.

Les erreurs de configuration courantes

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

N'authentifier qu'un seul cloud. Le plus fréquent : DKIM posé pour le Sales Cloud, Marketing Cloud ou Pardot oubliés — ces derniers échouent à DMARC sous politique stricte.

Générer la clé sans l'activer. Dans Setup, une clé DKIM créée mais laissée inactive ne signe rien ; le domaine paraît configuré, les messages ne sont pas signés.

Empiler l'include SPF Salesforce sans nécessité. Décrit ci-dessus : coût en lookups, risque de permerror, sans bénéfice d'alignement quand c'est DKIM qui aligne.

Durcir avant d'avoir tout couvert. Passer à p=reject en croyant Salesforce authentifié alors qu'un cloud émet encore sans signature alignée revient à rejeter une partie de son propre trafic métier.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas l'écran Setup, 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 est ici particulièrement précieuse, car elle révèle chaque cloud Salesforce comme une source distincte : on voit d'un coup d'œil si le Sales Cloud, le Marketing Cloud et Account Engagement s'alignent tous, ou si l'un d'eux échoue encore.

Une cadence simple suffit : une première lecture quelques jours après la configuration, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. C'est la confirmation que tous les clouds émetteurs s'alignent qui autorise à durcir — un seul cloud non aligné suffit à justifier d'attendre. Une fois cette couverture complète observée sur plusieurs jours, la montée vers p=reject se fait sans risque. 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.