L’alignement DMARC vérifie que le domaine affiché dans l’en-tête « From » de votre e-mail correspond au domaine authentifié par SPF ou par DKIM. Si ce lien n’existe pas, DMARC échoue, même quand SPF et DKIM affichent « pass » chacun de leur côté. Pour un expéditeur de cold emailing qui envoie depuis des domaines secondaires et des outils tiers, c’est l’une des causes les plus fréquentes de mails qui finissent en spam sans explication apparente.

Cet article explique le mécanisme, les deux modes (relaxed et strict), la lecture des rapports rua et ruf, puis une méthode pas à pas pour contrôler l’alignement avant de monter en volume.

TL;DR

• DMARC passe si au moins un des deux mécanismes, SPF ou DKIM, réussit et s’aligne avec le domaine du champ From. Un seul suffit, pas besoin des deux.
• Le mode relaxed (par défaut) accepte les sous-domaines d’un même domaine organisationnel. Le mode strict exige une correspondance exacte et casse facilement des flux légitimes.
• Pour la plupart des entreprises, relaxed suffit. Google ne recommande le strict que dans des cas précis, par exemple quand des sous-domaines sont gérés par des tiers.
• Misez sur les rapports agrégés rua pour le suivi quotidien. Gmail ne prend pas en charge ruf.
• En cold emailing, vérifiez que votre outil signe en DKIM avec votre domaine d’envoi, pas avec le sien.

Table des matières

• Ce que l’alignement ajoute à SPF et à DKIM
• Relaxed ou strict : les deux modes d’alignement
• Un exemple d’enregistrement DMARC commenté
• Lire les rapports : rua et ruf
• Pourquoi le cold emailing casse l’alignement
• Méthode : vérifier l’alignement avant de lancer une campagne
• Notre point de vue : l’alignement est un sujet d’infrastructure, pas de réglage
• Mettre l’infrastructure en place avec PlusVibe
• FAQ
• Sources

Ce que l’alignement ajoute à SPF et à DKIM

SPF et DKIM authentifient des choses différentes. SPF contrôle que le serveur qui envoie est autorisé pour le domaine du MAIL FROM (l’adresse d’enveloppe, invisible pour le destinataire). DKIM contrôle une signature cryptographique attachée au message, rattachée au domaine indiqué dans le paramètre d= de la signature. Aucun des deux n’oblige ce domaine à être celui que le destinataire voit dans son client de messagerie.

C’est exactement la faille que l’alignement referme. Selon la RFC 9989, DMARC rend un verdict « pass » ou « fail », et un « pass » exige non seulement un résultat SPF ou DKIM positif, mais aussi que le domaine associé à ce résultat corresponde au domaine du champ From. Microsoft décrit la même logique : DMARC commence par vérifier que les domaines des adresses MAIL FROM et From s’alignent, là où SPF et DKIM seuls ne l’exigent pas.

Conséquence concrète : un message peut réussir SPF ou DKIM sur le plan technique et échouer à DMARC faute d’alignement. Le « pass » de SPF ou de DKIM ne vaut donc pas validation de votre identité d’expéditeur.

La règle de décision, en une phrase

DMARC échoue uniquement si SPF (ou son alignement) et DKIM (ou son alignement) échouent tous les deux, comme le précise la RFC 9989. Il suffit donc qu’un seul des deux soit valide et aligné.

Relaxed ou strict : les deux modes d’alignement

DMARC propose deux modes, réglables séparément pour SPF et pour DKIM. D’après l’aide Google Workspace, le mode relaxed est le défaut : le domaine du champ From et le domaine authentifié doivent partager le même domaine organisationnel (le domaine racine), ce qui laisse passer les sous-domaines. En mode strict, les deux noms de domaine complets doivent être identiques. Le relaxed se règle avec adkim=r ou aspf=r, le strict avec adkim=s ou aspf=s.

Quel mode choisir

Les guides vantent souvent le strict pour la sécurité maximale. Dans la pratique, il provoque des faux négatifs sur des expéditeurs légitimes, notamment les messages automatiques envoyés par des plateformes tierces depuis des sous-domaines. Google indique que le relaxed suffit dans la grande majorité des cas, et ne suggère d’envisager le strict que si des sous-domaines sont gérés par des entités externes ou échappent au contrôle de l’organisation (aide Google Workspace).

Notre recommandation pour un expéditeur B2B : restez en relaxed tant que vous n’avez pas une raison documentée de faire autrement, par exemple un domaine très exposé à l’usurpation exacte. Le strict ne se décide qu’après plusieurs semaines de rapports propres.

Un exemple d’enregistrement DMARC commenté

L’enregistrement DMARC est un TXT publié sur _dmarc.votredomaine.fr. Voici une base prudente pour démarrer :

v=DMARC1; p=none; rua=mailto:dmarc-rapports@votredomaine.fr; adkim=r; aspf=r

• p=none : on observe sans rien bloquer. C’est le bon point de départ pour découvrir tous vos flux d’envoi.
• rua= : l’adresse qui reçoit les rapports agrégés.
• adkim=r; aspf=r : alignement relaxed, explicite par clarté (c’est déjà le défaut).

Le passage à quarantine puis reject se fait ensuite, flux par flux, une fois les rapports propres. Nous détaillons cette progression dans notre article sur la politique DMARC à définir avant de monter en volume.

Une exigence récente rend ce chantier moins optionnel : depuis février 2024, Gmail et Yahoo demandent aux expéditeurs en volume de s’authentifier avec SPF, DKIM et DMARC, sous peine de mails ralentis, classés en spam ou rejetés, comme le résume dmarc.com.

Lire les rapports : rua et ruf

DMARC sert aussi à observer. Deux tags définissent où partent les rapports.

rua : le rapport agrégé, votre outil de suivi

Le tag rua désigne l’adresse de réception des rapports agrégés : des résumés XML quotidiens du trafic d’e-mail que les fournisseurs de messagerie observent pour votre domaine. On y trouve, par source d’envoi (adresse IP), le nombre de messages, les résultats SPF et DKIM et leur alignement. Suped détaille le contenu de ces rapports et rappelle qu’un pass SPF ou DKIM brut ne garantit pas un pass DMARC.

Ces fichiers deviennent vite volumineux et sont pratiquement illisibles à la main. Prévoyez une boîte dédiée, ou un service tiers d’analyse DMARC, plutôt que votre messagerie personnelle (aide Google Workspace). Si l’adresse rua appartient à un autre domaine que celui du DMARC, Google renvoie à une procédure d’autorisation spécifique sur sa page dédiée aux rapports.

ruf : le rapport d’échec, rarement exploitable

Le tag ruf demande des rapports par message en échec. En théorie, c’est précieux. En pratique, Gmail indique qu’il ne prend pas en charge ce tag, et la plupart des grands fournisseurs n’en envoient pas à une échelle significative, notamment pour des raisons de vie privée (Suped). SAP Emarsys recommande lui aussi de privilégier les rapports agrégés rua plutôt que les rapports d’échec ruf.

À retenir : configurez rua en premier, et considérez ruf comme un bonus éventuel, pas comme une source de vérité.

Pourquoi le cold emailing casse l’alignement

Un expéditeur classique envoie depuis un seul système. Un expéditeur de prospection en a plusieurs : plusieurs domaines secondaires, plusieurs boîtes, un outil d’envoi, parfois un CRM qui envoie aussi en parallèle. Les points de rupture se répètent.

1. Signature DKIM au nom de l’outil. Si l’outil signe avec son propre domaine, DKIM peut être « pass » mais non aligné avec votre From. Il faut publier la clé DKIM de votre domaine d’envoi. Nous creusons le sujet dans DKIM alignment : le tueur silencieux de la délivrabilité.
2. SPF aligné sur le mauvais domaine. Le SPF valide le domaine du MAIL FROM. Si un prestataire utilise son propre domaine de retour (bounce), SPF passe mais ne s’aligne pas. Dans ce cas, c’est DKIM qui doit porter l’alignement. Voir aussi notre guide pratique de l’enregistrement SPF.
3. Sous-domaines et mode strict. Un From en contact@exemple.fr avec une signature d=mail.exemple.fr passe en relaxed et échoue en strict.
4. Transferts et listes de diffusion. Un message transféré fait souvent échouer SPF, car l’IP du serveur qui retransmet n’est pas dans votre enregistrement. DKIM, lui, survit au transfert tant que le contenu signé n’est pas modifié. C’est une raison de plus de soigner l’alignement DKIM.
5. Plusieurs outils sur le même domaine. Chaque nouvel outil d’envoi doit être ajouté et vérifié, sinon il apparaît dans vos rapports rua comme source non alignée.

Méthode : vérifier l’alignement avant de lancer une campagne

1. Inventoriez vos expéditeurs. Listez chaque domaine d’envoi, chaque boîte et chaque outil qui envoie en votre nom.
2. Publiez SPF et DKIM pour chaque domaine d’envoi. Un enregistrement SPF unique par domaine, une clé DKIM par service d’envoi.
3. Envoyez un message de test vers une boîte que vous contrôlez et ouvrez les en-têtes complets. Cherchez la ligne Authentication-Results : elle indique spf=, dkim= et dmarc=, avec les domaines concernés.
4. Comparez les domaines. Le domaine du header.from doit être le même (ou, en relaxed, de même domaine organisationnel) que header.d pour DKIM ou smtp.mailfrom pour SPF.
5. Publiez DMARC en p=none avec rua. Laissez tourner une à deux semaines.
6. Corrigez les sources non alignées repérées dans les rapports : ajoutez la clé DKIM manquante, supprimez un outil oublié ou retirez-le de vos envois.
7. Durcissez progressivement : quarantine, puis reject, en surveillant les rapports à chaque palier.

Pour la partie technique complète, notre guide de configuration SPF, DKIM et DMARC pour le cold email déroule les enregistrements un par un, et le guide SPF, DKIM et DMARC pose les bases si vous partez de zéro.

Si vous êtes sur Microsoft 365 ou Google Workspace

Les deux fournisseurs documentent la mise en place pas à pas : la page Configurer DMARC dans Microsoft 365 et l’aide Google Workspace. Dans les deux cas, DMARC se publie dans la zone DNS du domaine, via un enregistrement TXT.

Notre point de vue : l’alignement est un sujet d’infrastructure, pas de réglage

Chez PlusVibe, nous voyons le même schéma revenir : on cherche une réponse dans le contenu des mails ou dans le volume d’envoi, alors que le problème se trouve dans l’architecture. Un domaine mal aligné, une signature DKIM au nom de l’outil, un warm-up partagé avec des inconnus : ce sont des causes structurelles, et aucun copywriting ne les compense.

C’est pourquoi nous défendons une infrastructure d’envoi isolée et un warm-up privé, non partagé : chaque client garde ses serveurs et ses IP à lui, et sa réputation ne dépend pas du comportement d’autres expéditeurs. L’alignement DMARC fait partie du même raisonnement : votre identité d’expéditeur doit être cohérente de bout en bout, du domaine visible jusqu’à la signature.

Notre conseil de praticien : alignez d’abord, montez en volume ensuite. Traitez le p=none avec rua comme une phase d’audit obligatoire, pas comme une formalité, et ne passez en reject qu’une fois chaque source d’envoi identifiée. Pour la suite, notre checklist de délivrabilité et nos bonnes pratiques de délivrabilité couvrent les autres leviers, et notre méthode de warm-up d’une boîte avant le cold emailing prolonge le sujet côté réputation.

— Yaro

Mettre l’infrastructure en place avec PlusVibe

Si vous gérez plusieurs domaines et boîtes d’envoi, la configuration DNS devient vite chronophage. PlusVibe propose les plans Personal, Business et Agency : Personal de 37 à 58 $ par mois, Business de 77 à 220 $ par mois, Agency à partir de 497 $ par mois. Les boîtes Google Workspace sont proposées à partir de 4 $ par mois et par boîte, celles de Microsoft 365 à partir de 4,5 $ par mois et par boîte.

Si vous préférez déléguer la partie technique, le service Done-for-you Email Setup est facturé 1 500 $ par mois. Il prend en charge la mise en place de l’infrastructure d’envoi, pour que vous puissiez vous concentrer sur vos campagnes.

FAQ

Quelle est la différence entre DKIM et DMARC ?

DKIM signe chaque message et prouve qu’il n’a pas été modifié, au nom d’un domaine donné. DMARC est une politique qui s’appuie sur SPF et DKIM : elle exige que le domaine authentifié s’aligne avec le domaine du champ From, et indique au destinataire quoi faire en cas d’échec. DKIM prouve une signature, DMARC relie cette preuve à l’identité visible.

Faut-il que SPF et DKIM soient tous les deux alignés ?

Non. DMARC passe dès qu’un seul des deux réussit et s’aligne, et il échoue seulement si les deux échouent (RFC 9989). Il reste préférable de configurer les deux, car SPF casse souvent lors des transferts alors que DKIM tient mieux.

Dois-je configurer le tag ruf ?

Ce n’est pas prioritaire. Gmail ne le prend pas en charge, et peu de fournisseurs envoient ces rapports à grande échelle. Concentrez-vous sur rua, qui donne la vue d’ensemble de vos sources d’envoi.

L’alignement strict est-il plus sûr que le relaxed ?

Il est plus restrictif, mais pas forcément plus adapté. Il peut bloquer des mails légitimes envoyés depuis des sous-domaines ou par des plateformes tierces. Google considère le relaxed comme suffisant dans la grande majorité des cas.

Comment savoir si mon alignement est correct ?

Envoyez un message de test vers une boîte que vous contrôlez et lisez la ligne Authentication-Results dans les en-têtes. Vérifiez que le domaine du From correspond au domaine DKIM (d=) ou au domaine du MAIL FROM, puis confirmez avec vos rapports rua sur plusieurs jours.

Sources

• RFC 9989, DMARC
• Google Workspace : configurer DMARC
• Microsoft Learn : configurer DMARC dans Microsoft 365
• Suped : contenu des rapports DMARC rua et ruf
• SAP Emarsys : options de rapport DMARC supplémentaires
• dmarc.com : exigences expéditeurs de Gmail et Yahoo

Recommandations

• Politique DMARC : que définir avant de déployer à grande échelle
• Enregistrement SPF Email expliqué : un guide pratique
• Configuration technique pour les emails à froid - SPF, DKIM, DMARC
• SPF, DKIM & DMARC : le guide ultime de sécurité des emails