Mailchimp et DMARC : obtenir un alignement complet

k1._domainkey.exemple.fr.  CNAME  dkim.mcsv.net.
k2._domainkey.exemple.fr.  CNAME  dkim2.mcsv.net.
k3._domainkey.exemple.fr.  CNAME  dkim3.mcsv.net.

Pourquoi l'alignement SPF ne viendra pas — et pourquoi c'est sans gravité

Le réflexe qui suit souvent la pose des CNAME consiste à vouloir « compléter » le travail avec SPF, en ajoutant l'include de la plateforme dans l'enregistrement du domaine. Ce réflexe repose sur une confusion. SPF s'évalue sur le domaine de l'enveloppe (le Return-Path), pas sur le domaine affiché dans le From. Or chez Mailchimp, l'enveloppe reste sur les serveurs de la plateforme : c'est ainsi que les retours d'erreur — adresses invalides, boîtes pleines — reviennent vers ses systèmes de gestion de listes. Aucune option ne permet d'y substituer un domaine personnalisé.

Conséquence : SPF passera toujours pour le domaine de la plateforme et ne s'alignera jamais avec le From. Ajouter l'include au SPF du domaine n'y change rien — cela ne fait que consommer une des dix résolutions DNS autorisées, pour un mécanisme qui ne participera pas au verdict. La plateforme elle-même ne recommande plus cet ajout depuis longtemps.

Et c'est sans gravité, parce que DMARC n'exige pas les deux mécanismes : un seul résultat aligné suffit à produire un pass. Le DKIM aligné obtenu par les CNAME couvre l'intégralité du besoin. Il présente même un avantage de robustesse : la signature DKIM voyage avec le message et survit à la plupart des transferts automatiques, là où SPF casse dès qu'un intermédiaire ré-expédie. Pour un flux marketing, dont les destinataires transfèrent volontiers, l'alignement DKIM est le bon cheval.

Ce que montrent les rapports RUA, avant et après

Les rapports agrégés racontent cette histoire avec précision. Avant l'authentification, chaque ligne attribuée aux adresses IP de la plateforme présente la même signature caractéristique :

<record>
  <row>
    <source_ip>205.201.131.xx</source_ip>
    <policy_evaluated><dkim>fail</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <auth_results>
    <dkim><domain>mcsv.net</domain><result>pass</result></dkim>
    <spf><domain>mail01.rsgsv.net</domain><result>pass</result></spf>
  </auth_results>
</record>

La nuance à lire est dans le contraste : dans auth_results, tout passe ; dans policy_evaluated, tout échoue. C'est l'empreinte typique d'un problème d'alignement, pas d'un problème d'authentification — le diagnostic le plus utile qu'un rapport RUA puisse livrer.

Après la pose des CNAME, la même plage d'adresses bascule : dkim=pass avec exemple.fr comme domaine signataire, policy_evaluated au vert, et le SPF toujours non aligné — sans aucune conséquence. Constater cette bascule sur un cycle complet de campagnes est la preuve qui autorise à durcir la politique. Encore faut-il collecter les rapports : un enregistrement du type v=DMARC1; p=none; rua=mailto:rapports@exemple.fr est le point d'entrée, et les exemples commentés d'enregistrements DMARC fournissent des modèles prêts à adapter selon la maturité du domaine.

La même grille de lecture s'applique aux autres plateformes du parc : la logique est proche pour SPF et DKIM chez Brevo, et le cas SendGrid illustre un curseur placé autrement entre enveloppe personnalisable et DKIM délégué. Chaque plateforme fait ses choix ; la question à poser reste la même : qui signe, et pour quel domaine ?

Le sous-domaine dédié : isoler la réputation

Plutôt que de faire porter les campagnes par le domaine racine, beaucoup d'organisations les confient à un sous-domaine dédié : news.exemple.fr, info.exemple.fr. Les CNAME d'authentification se posent alors sur ce sous-domaine, et le From des campagnes l'affiche. Les bénéfices sont concrets. La réputation d'envoi du flux marketing se construit à part : un incident de campagne — pic de plaintes, liste mal nettoyée — n'entame pas la réputation du domaine racine, dont dépendent les e-mails transactionnels et la correspondance individuelle. L'inventaire des sources gagne aussi en lisibilité : dans les rapports, tout ce qui émane du sous-domaine relève d'un flux unique, ce qui simplifie l'attribution.

Côté DMARC, l'alignement en mode détendu — le défaut — accepte qu'un From en news.exemple.fr s'aligne aussi bien avec une signature d=news.exemple.fr qu'avec une signature du domaine organisationnel. DMARCbis, la révision courante du standard, détermine ce domaine organisationnel par le DNS Tree Walk, la remontée de l'arbre DNS, et non plus par la Public Suffix List. La révision apporte aussi le tag np, qui règle le sort des sous-domaines inexistants : de quoi verrouiller paie.exemple.fr ou tout autre sous-domaine fantôme pendant que news.exemple.fr déroule ses campagnes légitimes. Un sous-domaine dédié peut enfin porter sa propre politique, publiée sur _dmarc.news.exemple.fr, et durcir à son rythme.

À p=reject sans authentification : la double peine

Reste le scénario du pire : un domaine qui passe à p=reject sans avoir authentifié son routeur. Deux mécaniques se combinent. Pour les flux où le From conserve le domaine, les campagnes non alignées sont rejetées net par les destinataires qui honorent la politique — des envois entiers évaporés, souvent découverts des semaines plus tard, en cherchant pourquoi « la newsletter ne part plus ». Et pour les flux passés par la réécriture du From, la sanction est plus insidieuse : les messages partent et arrivent, mais sous send.mailchimpapp.com — la marque a disparu du champ expéditeur, la reconnaissance chute, et les filtres apprennent un domaine qui n'appartient pas à l'organisation.

La politique stricte reste la bonne cible ; c'est l'ordre des opérations qui n'est pas négociable : authentifier d'abord, constater l'alignement dans les rapports ensuite, durcir enfin. DMARCbis fournit d'ailleurs un outil d'essai propre, le tag t=y, qui signale aux destinataires qu'une politique est en mode test — le successeur assumé de l'ancien pct, disparu de la révision courante.

En résumé

Par défaut, Mailchimp authentifie ses propres domaines, pas celui de la marque : SPF et DKIM passent, rien ne s'aligne, DMARC échoue — et depuis les exigences des grands fournisseurs, le From est réécrit vers un domaine de la plateforme dès que l'authentification manque. La correction tient en quelques CNAME posés sous _domainkey, qui font signer les campagnes au nom du domaine : DKIM s'aligne, et cela suffit, car l'alignement SPF est structurellement hors de portée chez ce prestataire — l'enveloppe reste sur ses serveurs. Les rapports RUA apportent la preuve de la bascule, le sous-domaine dédié isole la réputation marketing, et le durcissement vers p=reject vient après la preuve, jamais avant.

Pour situer le point de départ, un passage du domaine par l'analyse DMARC gratuite montre en quelques secondes si les campagnes signent déjà au nom du domaine ou encore à celui de la plateforme. Ensuite, la création d'un compte permet de suivre la bascule dans les rapports, campagne après campagne, jusqu'à une politique stricte qui protège la marque sans perdre une seule newsletter.