DMARC
← Blog

Authentifier Brevo : SPF, DKIM et alignement DMARC

Par Thomas · RSSI virtuel · 2026-07-28

Brevo — la plateforme d'emailing née sous le nom de Sendinblue — expédie chaque jour les newsletters, les confirmations de commande et les scénarios d'automatisation de centaines de milliers d'organisations. Une part considérable de ces comptes tourne pourtant en configuration « par défaut » : les messages partent, arrivent le plus souvent, et tout semble fonctionner. En coulisses, le tableau est moins flatteur. Sans authentification de domaine, ces envois sont signés au nom d'une infrastructure mutualisée, pas au nom de l'organisation qui s'affiche dans le champ expéditeur. DMARC ne peut donc jamais les valider, et la délivrabilité plafonne à un niveau qu'aucune optimisation de contenu, d'objet ou d'horaire ne viendra débloquer.

Le paradoxe, c'est que Brevo fait correctement les choses : la plateforme propose une authentification de domaine complète, avec des enregistrements DNS fournis clé en main dans l'interface. Ce qui manque le plus souvent, c'est l'étape de configuration elle-même — ou la compréhension de ce qu'elle change vraiment. Publier deux enregistrements TXT prend dix minutes ; saisir pourquoi la signature DKIM au nom du domaine est précisément ce qui fait passer DMARC demande un peu plus d'attention, et c'est l'objet de ce guide.

Au programme : pourquoi un ESP non authentifié bride la délivrabilité, la configuration côté Brevo (mail._domainkey et code de vérification), le point décisif de l'alignement DKIM, la question de l'enveloppe SPF — la plus mal comprise de toutes —, les exigences des grandes messageries pour les expéditeurs en volume, puis la preuve finale, à lire dans les rapports RUA.

Pourquoi un ESP non authentifié plafonne la délivrabilité

Un compte Brevo sans authentification de domaine envoie des messages techniquement corrects : la plateforme les signe en DKIM, mais avec un domaine qui lui appartient ou qui est partagé entre des milliers de clients. Le champ From: affiche marketing@exemple.fr, tandis que la cryptographie parle au nom d'un tiers. Les deux voix ne coïncident pas, et cette dissonance a deux conséquences bien distinctes.

La première est mécanique : DMARC échoue. Le protocole n'exige pas seulement que SPF ou DKIM passent ; il exige qu'au moins l'un des deux passe et soit aligné avec le domaine du From:. Une signature DKIM parfaitement valide posée par un domaine mutualisé ne remplit pas cette condition. Tant que rien n'est aligné, la politique DMARC d'exemple.fr reste condamnée à p=none : la durcir enverrait les propres campagnes de l'organisation en quarantaine, puis au rejet.

La seconde est plus insidieuse : la réputation. Les filtres de Gmail, de Yahoo ou de Microsoft construisent leur confiance par domaine authentifié. Quand la signature est celle d'une infrastructure partagée, la réputation gagnée par de bonnes pratiques d'envoi se dilue dans le comportement de milliers d'autres expéditeurs — les moins scrupuleux compris. exemple.fr n'accumule rien en propre : chaque campagne repart de zéro, et le plafond de verre reste en place quel que soit le soin apporté au contenu.

L'authentification de domaine chez Brevo

Dans l'interface Brevo, tout se joue dans les réglages, à la rubrique des expéditeurs et domaines. Pour chaque domaine d'envoi, la plateforme génère un jeu d'enregistrements DNS à publier dans la zone du domaine, chez l'hébergeur DNS habituel. Deux enregistrements portent l'essentiel : la clé publique DKIM, placée sous le sélecteur mail, et un code de vérification qui prouve la maîtrise du domaine.

mail._domainkey.exemple.fr.   TXT   "k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…"
exemple.fr.                   TXT   "brevo-code:7f3a92c1d5e84b06"

Les valeurs ci-dessus sont illustratives : chaque compte reçoit les siennes, à copier telles quelles depuis l'interface — la clé publique notamment, longue et sans aucune tolérance à la faute de frappe. Deux pièges classiques guettent la saisie : certains hébergeurs DNS ajoutent automatiquement le nom du domaine à la fin du champ « nom » (il faut alors saisir mail._domainkey seul, sous peine d'obtenir mail._domainkey.exemple.fr.exemple.fr), et les clés longues doivent parfois être découpées en plusieurs chaînes entre guillemets selon l'éditeur de zone. Une vérification en ligne de commande lève le doute :

dig TXT mail._domainkey.exemple.fr +short

Si aucun enregistrement DMARC n'existe encore sur _dmarc.exemple.fr, c'est le bon moment pour en publier un — en p=none avec une adresse rua, afin de commencer à recevoir les rapports sans rien bloquer. Des exemples d'enregistrements DMARC prêts à adapter couvrent les configurations de départ les plus courantes. Une fois les enregistrements propagés — de quelques minutes à quelques heures selon les TTL —, Brevo valide le domaine, et chaque message part désormais signé d=exemple.fr, sélecteur mail.

L'alignement DKIM : ce qui fait réellement passer DMARC

Le mot qui compte dans toute cette opération n'est ni « signature » ni « clé » : c'est alignement. Un message signé par un domaine technique de la plateforme passe DKIM au sens cryptographique — la signature est valide, personne n'a altéré le contenu. Mais DMARC ajoute une exigence d'identité : le domaine d= de la signature doit correspondre au domaine du From: visible. d=exemple.fr avec un From: en exemple.fr : aligné, DMARC passe. d= sur un domaine mutualisé : DKIM « pass », DMARC « fail ».

En mode relaxed — le défaut, et le bon choix pour un ESP —, la correspondance se joue au niveau du domaine organisationnel : un From: en news.exemple.fr signé d=exemple.fr reste aligné. DMARCbis, la version courante du standard, détermine désormais ce domaine organisationnel par un parcours de l'arbre DNS (le Tree Walk) plutôt que par l'ancienne Public Suffix List — un changement de mécanique interne qui ne modifie en rien le geste de configuration. Le mode strict, lui, exige l'identité exacte des deux domaines ; il se réserve aux organisations où le contrôle fin prime sur la souplesse.

Toute la valeur de l'authentification de domaine Brevo tient dans ce déplacement : la signature mutualisée devient une signature au nom de l'organisation. La mécanique n'a d'ailleurs rien de spécifique à Brevo : la configuration équivalente chez Mailjet suit le même schéma, et l'alignement chez Mailchimp pose exactement la même question avec d'autres écrans et un CNAME de plus. Le principe reste constant d'un ESP à l'autre : le domaine qui signe doit être celui qui s'affiche.

SPF et enveloppe : pourquoi l'alignement ne viendra pas de là

Le réflexe le plus répandu consiste à ajouter un include de la plateforme dans le SPF du domaine et à considérer le travail terminé. C'est une double erreur de lecture. SPF ne s'évalue pas sur le From: visible : il s'évalue sur le MAIL FROM de l'enveloppe SMTP — le Return-Path, cette adresse technique qui collecte les rebonds. Or chez Brevo, comme chez la plupart des ESP, cette adresse d'enveloppe reste sur un domaine opéré par la plateforme : c'est ce qui lui permet de traiter les bounces et l'hygiène de liste à l'échelle. SPF passe donc bel et bien… mais au nom du domaine d'enveloppe de Brevo, pas au nom d'exemple.fr. Résultat : un « pass » sans alignement, donc aucune contribution à DMARC.

Modifier le SPF d'exemple.fr n'y change rien — les serveurs destinataires interrogent l'enregistrement du domaine d'enveloppe, jamais celui du From:. Un include superflu ne fait que consommer le budget des dix consultations DNS de SPF, sans rien apporter en face. Cette dissociation entre le SPF brut et le verdict DMARC est l'une des confusions les plus fréquentes en lecture de rapports ; elle est décortiquée dans pourquoi DMARC échoue alors que SPF passe.

La conclusion pratique est limpide : chez un ESP, c'est DKIM qui porte l'alignement, seul — et cela suffit, puisque DMARC ne demande qu'un des deux mécanismes aligné. Certains ESP proposent en option un domaine d'enveloppe personnalisé qui ajoute l'alignement SPF par-dessus ; c'est un raffinement bienvenu, pas un prérequis.

Gmail, Yahoo, Microsoft : un sujet devenu non optionnel

Depuis février 2024, Gmail et Yahoo imposent un socle aux expéditeurs en volume — de l'ordre de 5 000 messages par jour vers leurs boîtes : SPF et DKIM en place, un enregistrement DMARC publié (au minimum p=none), un From: effectivement aligné, la désinscription en un clic et un taux de plainte maintenu sous environ 0,3 %. Microsoft a suivi en 2025 avec des exigences comparables pour ses boîtes grand public. Une newsletter Brevo un peu active franchit vite ces seuils.

Concrètement, un compte Brevo sans authentification de domaine coche la case « DKIM » au sens technique, mais échoue au critère d'alignement — celui-là même que ces exigences visent. Les conséquences s'observent par paliers : placement en spam plus fréquent d'abord, puis rejets purs et simples sur les campagnes les plus volumineuses. Ce qui relevait de la bonne pratique est devenu le prix d'entrée de la boîte de réception ; l'authentification de domaine n'est plus un réglage d'expert, c'est le ticket de base.

La preuve dans les rapports RUA

Une fois le domaine authentifié, la validation ne se lit ni dans l'interface de Brevo ni sur la foi d'un unique message de test : elle se lit dans les rapports agrégés DMARC (RUA), envoyés chaque jour par les destinataires eux-mêmes. Ces rapports recensent, IP par IP, ce que Gmail, Microsoft ou Yahoo ont réellement observé. Après l'activation, les IP d'envoi de Brevo doivent y apparaître avec un DKIM « pass » dont le domaine de signature est exemple.fr :

<row>
  <policy_evaluated><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
</row>
<auth_results>
  <dkim><domain>exemple.fr</domain><selector>mail</selector><result>pass</result></dkim>
</auth_results>

La ligne spf de l'évaluation reste souvent en « fail » au sens DMARC — c'est l'enveloppe de la plateforme, non alignée — et c'est parfaitement normal : le dkim aligné suffit à porter le verdict global. Les vrais points de vigilance sont ailleurs : des envois qui continueraient d'être signés par le domaine mutualisé (un sous-compte oublié, un flux transactionnel configuré à part, un service qui a branché un autre outil dans son coin), ou une source inconnue qui émettrait au nom du domaine sans aucun rapport avec Brevo. C'est exactement le genre de dérive qu'une lecture continue des rapports révèle — et que des fichiers XML ouverts à la main ne révéleront jamais bien longtemps : la surveillance outillée existe pour cela.

En résumé

Un compte Brevo non authentifié fonctionne, mais plafonne : signature mutualisée, réputation diluée, DMARC en échec permanent. L'authentification de domaine — la clé DKIM sous mail._domainkey et le code de vérification, valeurs fournies par la plateforme — déplace la signature sur le domaine de l'organisation ; c'est l'alignement de ce d= avec le From: qui fait passer DMARC. SPF, évalué sur l'enveloppe de la plateforme, n'apporte généralement pas cet alignement : DKIM le porte seul, et cela suffit. Les exigences de Gmail, Yahoo et Microsoft en font désormais une condition d'entrée pour l'envoi en volume, et les rapports RUA en apportent la preuve, IP par IP.

Pour situer le point de départ, un passage du domaine par l'analyse DMARC gratuite montre en quelques secondes si les envois signent au bon nom et ce que vaut la politique publiée. L'ouverture d'un compte permet ensuite de suivre les rapports RUA semaine après semaine et de faire monter la politique vers p=reject une fois l'alignement démontré — avec le trafic Brevo authentifié en tête de cortège.

Appliquer DMARC, concrètement

Thomas, le RSSI virtuel de DMARC.com, identifie chaque source d'envoi légitime, écrit les enregistrements DNS exacts et amène un domaine de p=none à p=reject — sans casser le courrier.

Atteindre p=reject — gratuit

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.