Alignement DMARC : SPF, DKIM et diagnostic des échecs

L’alignement DMARC est souvent négligé. Une équipe publie SPF, DKIM et DMARC, mais Gmail classe encore certains messages comme spam ou les refuse. Pour revoir l’ensemble, consultez notre guide du courrier professionnel, puis revenez ici examiner l’authentification et l’alignement.

Réussir l’authentification ne suffit pas : le domaine validé par SPF ou DKIM doit être aligné sur celui de From visible. Si aucun mécanisme ne fournit de résultat valide et aligné, DMARC échoue ; cela ne prouve pas à lui seul une usurpation. Ces problèmes concernent les plateformes d’envoi, CRM, services d’assistance, transferts et configurations DNS incomplètes.

Nous verrons comment fonctionne l’alignement, pourquoi corriger uniquement SPF peut être insuffisant et quels en-têtes examiner. Nous préciserons aussi quand DKIM peut préserver la réussite de DMARC lors d’un transfert, sans garantir la conservation de la signature sur toutes les routes.

Qu’est-ce que l’alignement DMARC ?

L’alignement compare le domaine authentifié par SPF ou DKIM au domaine visible de From. DMARC réussit si SPF réussit avec alignement, ou si DKIM réussit avec alignement. Un seul résultat valide et aligné suffit ; DMARC échoue si aucun mécanisme ne le fournit.

Cette règle vient de RFC 7489. DMARC repose sur SPF et DKIM, sans authentifier le courrier indépendamment. Il vérifie si le domaine authentifié est aligné sur celui que voit le destinataire.

Voici les comparaisons :

Vérification	Ce que valide le destinataire	Condition d’alignement DMARC
SPF	Autorisation de l’IP pour le domaine de l’expéditeur d’enveloppe, MAIL FROM / Return-Path	Le domaine authentifié du Return-Path doit s’aligner sur From
DKIM	La signature DKIM et son domaine d=	Le domaine d= doit s’aligner sur From
DMARC	Résultat d’authentification alignée et politique demandée	Au moins un des mécanismes précédents doit réussir avec alignement

En résumé, SPF ou DKIM réussi avec un domaine non aligné ne suffit pas à lui seul. Pour DMARC, au moins un mécanisme doit réussir et s’aligner sur From.

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

Pourquoi SPF réussit sans fournir d’alignement DMARC

L’alignement SPF échoue lorsque le Return-Path utilise un domaine du fournisseur non aligné sur le vôtre. L’IP peut être autorisée et SPF réussir, mais un domaine de rebond SendGrid, Mailchimp, HubSpot ou Shopify peut ne pas être aligné. DMARC peut néanmoins réussir si DKIM fournit un résultat valide et aligné.

C’est un cas courant. Les plateformes gèrent les rebonds, les listes d’exclusion et les événements ; certaines utilisent par défaut leur propre Return-Path.

From visible : billing@example.com
Return-Path: bounces+123@sendgrid.net

SPF peut réussir parce que SendGrid autorise l’IP pour sendgrid.net. Ce résultat ne fournit pas d’alignement DMARC : sendgrid.net n’est pas aligné sur example.com.

Pour aligner SPF, configurez le domaine de rebond ou le Return-Path personnalisé du fournisseur. Ne confondez pas cette fonction avec la personnalisation des liens ou le domaine de suivi : ils ne changent pas nécessairement l’expéditeur d’enveloppe.

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

Ce CNAME est illustratif. Le fournisseur doit activer la fonction et utiliser réellement bounces.example.com dans l’expéditeur d’enveloppe ; vérifiez-le sur des messages. En mode souple, ce domaine s’aligne sur example.com.

Le transfert ajoute une difficulté. Une université, un revendeur ou une boîte personnelle peut transférer depuis sa propre IP, que SPF évalue pour le domaine d’enveloppe utilisé à ce saut. C’est pourquoi les guides sur le transfert du courrier d’un domaine vers Gmail et le transfert avec des alias abordent les échecs SPF. SPF est utile, mais ne garantit pas la réussite de DMARC après transfert.

Pourquoi vérifier l’alignement DKIM

DKIM peut mieux résister à certains transferts que SPF. Pour fournir un résultat DMARC réussi, la signature doit rester valide et alignée, et les données signées doivent être préservées après canonicalisation. Affirmer que le message n’a pas beaucoup changé ne suffit pas.

Configurer DKIM aligné est donc recommandé, notamment avec des intermédiaires. Ce n’est pas une obligation universelle du protocole si SPF réussit déjà avec alignement. Une signature utilisant le domaine d’un outil peut réussir DKIM sans contribuer à l’alignement de votre domaine.

From visible : newsletter@example.com
Signature DKIM : d=mailchimpapp.net

DKIM peut réussir, mais le domaine signataire n’est pas aligné. DMARC échoue si SPF ne réussit pas non plus avec alignement.

Configurez l’authentification du domaine dans chaque plateforme. Elle peut nécessiter la publication des enregistrements DKIM indiqués par le fournisseur et l’activation de leur utilisation, pas simplement une attente après publication.

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

Après configuration et vérification, la plateforme peut signer avec d=example.com ou un sous-domaine aligné en mode souple, comme d=mail.example.com. DKIM peut alors fournir l’alignement même si SPF échoue lors d’un transfert, à condition que la signature reste valide.

Les consignes Google citées demandent aux expéditeurs en nombre qu’au moins SPF ou DKIM réussisse avec alignement sur From et recommandent de configurer correctement les deux. Vérifiez les exigences actuelles et leur portée ; un défaut d’authentification peut contribuer aux restrictions, mais l’alignement ne garantit pas la boîte de réception.

Alignement souple ou strict

Le mode souple compare le domaine organisationnel ; le mode strict exige le domaine complet exact. Le mode souple est utilisé par défaut, mais le choix dépend des expéditeurs et des risques réels, pas d’une règle universelle.

Les balises aspf pour SPF et adkim pour DKIM contrôlent le mode dans DMARC.

Mode	Ce qui est aligné	Effet opérationnel
Souple	`mail.example.com` s’aligne sur `example.com`	Permet les sous-domaines du même domaine organisationnel, pas toute relation entre domaines
Strict	Seul le domaine exact correspond	Peut exclure des flux légitimes authentifiés avec un autre sous-domaine

Exemple :

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

Le mode strict peut compliquer l’exploitation. Si une application signe avec mail.example.com et que From utilise example.com, DKIM ne fournit plus l’alignement strict ; DMARC peut toutefois réussir grâce à SPF valide et aligné.

Activez le mode strict pour un besoin précis et après examen de tous les flux. En mode souple aussi, vérifiez que chaque expéditeur autorisé fournit un résultat valide et aligné.

Examiner l’alignement DMARC

Examinez les en-têtes reçus : Authentication-Results, le domaine d= de la signature DKIM, smtp.mailfrom pour SPF et le résultat dmarc associé à header.from. Fiez-vous uniquement à Authentication-Results produit par le destinataire qui évalue le message, pas à des en-têtes ajoutés par l’expéditeur.

Si un message semble légitime mais échoue à DMARC, ces en-têtes et sa signature peuvent aider à identifier les domaines utilisés. Confrontez-les à la configuration et aux journaux du service.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

Lisez les données dans cet ordre :

Vérifiez header.from, le domaine visible évalué par DMARC.
Vérifiez le domaine SPF dans smtp.mailfrom. S’il appartient au fournisseur sans être aligné, SPF ne fournit pas l’alignement DMARC.
header.i ne remplace pas le domaine d= de la signature, utilisé pour l’alignement DKIM et susceptible de différer de l’identité i. Vérifiez la signature réelle ; un domaine fournisseur non aligné ne fournit pas l’alignement.
Si aucun résultat réussi n’est aligné sur From, DMARC échoue même si SPF et DKIM réussissent pour d’autres domaines.

Vous pouvez aussi interroger le DNS :

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

Lors d’un transfert, un échec SPF peut être attendu, mais il ne doit pas être ignoré automatiquement. Vérifiez la réussite de DKIM avec alignement et la préservation des données signées après canonicalisation ; DKIM valide sans alignement ne sauve pas DMARC.

Pour un nouveau domaine, le guide de configuration TrekMail et celui pour créer des e-mails avec votre domaine aident à organiser SPF, DKIM et DMARC. Conservez un SPF valide par domaine d’enveloppe réel et respectez son plafond de mécanismes et modificateurs déclenchant des recherches DNS, évaluations imbriquées comprises. Supprimez les anciens enregistrements seulement après confirmation qu’ils sont inutiles ; ne retirez pas tous les MX ou sélecteurs indistinctement.

Les schémas fréquents d’échec d’alignement

Fournisseurs externes, transferts, sous-domaines et enregistrements DNS anciens ou en double sont des pistes fréquentes. Reconnaître un schéma oriente l’examen, sans prouver à lui seul la cause.

Examinez ces cas :

Le marketing utilise son domaine de rebond : SPF réussit sans alignement ; DMARC peut réussir grâce à DKIM valide et aligné.
Le fournisseur signe avec son domaine : DKIM réussit sans alignement ; SPF valide et aligné peut encore faire réussir DMARC.
Un transfert fait échouer SPF : DKIM doit rester valide et aligné pour fournir le résultat restant.
Le mode strict empêche l’alignement d’un sous-domaine autorisé ; vérifiez si l’autre mécanisme fournit l’alignement.
Des DNS anciens subsistent : confirmez leur utilisation avant de les modifier ; un enregistrement obsolète ne prouve pas qu’une plateforme envoie ou signe encore.

L’erreur Gmail 4.7.32, lorsqu’elle indique que From n’est pas aligné sur SPF ou DKIM, signale un problème précis d’alignement. Des difficultés de réputation ou d’envoi peuvent aussi coexister. Consultez les consignes d’envoi de Google et leur portée actuelle.

Corriger l’alignement avec TrekMail

TrekMail peut réunir gestion des boîtes, contrôles DNS et choix d’envoi selon le plan. Centraliser peut faciliter la coordination entre cinq interfaces, sans supprimer les configurations correctes ni les tests de chaque expéditeur.

Voici des options concrètes.

Gestion dispersée et gestion centralisée

Gestion dispersée	Gestion avec TrekMail
Héberger les boîtes, envoyer et suivre le DNS dans des outils séparés	Gérer domaines, boîtes, choix SMTP et contrôles DNS dans l’interface disponible
Dépendre des instructions de chaque fournisseur	Utiliser l’assistant et confronter les enregistrements au service réel et aux recherches externes
Examiner manuellement transferts et incidents spam	Vérifier DKIM aligné et les transferts dans un processus organisé

Avec le SMTP géré des plans payants concernés, publiez les DNS indiqués et testez l’authentification alignée sur des messages réels. Avec votre propre SMTP sur Nano ou un plan compatible, configurez le fournisseur réel, SES, SendGrid, Mailgun ou autre. L’objectif est un résultat valide et aligné, pas seulement un indicateur positif dans l’interface.

Références utiles :

Mes e-mails arrivent dans le spam traite des échecs SPF et réussites DKIM lors des transferts, qui ne passent DMARC que si DKIM est également aligné. La documentation des paramètres IMAP & SMTP présente les points de connexion pour tester l’accès des clients, distinct de l’alignement de l’envoi.

L’offre décrite présente Starter à partir de $3.50 par mois et un essai gratuit de 14 jours sur les plans payants nécessitant une carte de crédit pour démarrer. Nano est proposé sans frais avec votre SMTP, jusqu’à 10 domaines et 5 GB de stockage mutualisé selon ses conditions. Consultez tarifs, limites et fonctionnalités actuels sur la page des tarifs TrekMail. La copie IMAP ne remplace pas le changement des MX et ne migre pas toutes les applications ; comparer les modèles tarifaires ne garantit pas des économies.

Liste finale pour l’alignement DMARC

Un déploiement maîtrisé vise la réussite de SPF ou DKIM avec alignement pour chaque expéditeur autorisé, voire les deux lorsque possible. Cela aide à évaluer les restrictions, sans éliminer tous les risques de transfert ni garantir la remise.

Recensez tous les expéditeurs : hébergement des boîtes, CRM, facturation, assistance, boutique, formulaires et marketing.
Confirmez le domaine visible de From de chaque service.
Vérifiez SPF et l’alignement du domaine réel du Return-Path, pas seulement sa présence.
Configurez et vérifiez DKIM avec alignement sur votre domaine, surtout pour les routes avec transfert.
Conservez aspf=r et adkim=r sauf besoin testé justifiant le mode strict.
Envoyez des tests vers Gmail et examinez Authentication-Results produit par le destinataire et le domaine réel de la signature DKIM.
Envisagez de conserver p=none pendant la validation des flux ; cette politique ne demande pas de restrictions DMARC, mais les filtres locaux restent actifs.
Appliquez des restrictions après confrontation des rapports partiels aux inventaires, journaux et tests des flux critiques rares, puis évaluation des échecs restants et des exceptions locales.

L’alignement est une condition d’authentification DMARC, pas un classement infaillible entre messages légitimes et usurpés ni une garantie de contenu sûr. Pour coordonner plusieurs domaines, évaluez TrekMail selon ses plans et votre exploitation, sans supposer d’économies face à une facturation par utilisateur.