Fièrement canadien 
Si les courriels de votre entreprise atterrissent dans des dossiers indésirables, sont silencieusement rejetés ou échouent aux vérifications d'authentification, il y a de fortes chances que l'alignement DMARC soit en cause. C'est l'un des problèmes de délivrabilité les plus courants et les plus mal compris que nous résolvons pour nos clients, et les messages d'erreur impliqués vous disent rarement ce qui ne va pas vraiment.
Ce guide couvre tout ce dont vous avez besoin : ce que signifie réellement l'alignement DMARC, comment SPF et DKIM s'intègrent dans l'équation, et comment configurer correctement les trois protocoles dans Google Workspace, y compris lorsque vous utilisez également des services tiers comme Mailgun, SendGrid, ou toute plateforme marketing qui envoie en votre nom.
Résumé de la correction rapide
- Vérifier que votre enregistrement SPF inclut
include:_spf.google.comet tous les expéditeurs tiers - Générer et publier une clé DKIM dans la Console d'administration Google Workspace
- S'assurer que le domaine de votre adresse De correspond exactement à vos domaines SPF et DKIM
- Publier un enregistrement TXT DMARC en commençant par
p=nonepour surveiller sans bloquer les courriels - Examiner les rapports agrégés DMARC et renforcer la politique vers
p=quarantineoup=rejectavec le temps
Comprendre les trois piliers : SPF, DKIM et DMARC
Avant de passer aux corrections, il vaut la peine de comprendre comment ces trois protocoles fonctionnent ensemble. Chacun remplit une fonction distincte, et DMARC dépend des deux autres pour être utile.
Qu'est-ce que SPF?
SPF (Sender Policy Framework) est un enregistrement DNS qui liste tous les serveurs de messagerie autorisés à envoyer des courriels au nom de votre domaine. Lorsqu'un serveur destinataire reçoit un courriel de votre part, il vérifie votre DNS pour voir si l'adresse IP du serveur expéditeur figure sur la liste approuvée.
Un enregistrement SPF ressemble à ceci :
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Le ~all à la fin est un soft fail qui indique aux serveurs destinataires d'accepter le courriel mais de le signaler. Utiliser -all est plus strict et rejettera catégoriquement les expéditeurs non autorisés.
Qu'est-ce que DKIM?
DKIM (DomainKeys Identified Mail) ajoute une signature numérique cryptographique à chaque courriel envoyé par votre serveur. Le serveur destinataire récupère votre clé publique dans le DNS et l'utilise pour vérifier la signature, confirmant que le courriel n'a pas été altéré en transit et qu'il provient véritablement de votre domaine.
Un enregistrement DKIM dans le DNS ressemble à ceci :
google._domainkey.votredomaine.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."
Qu'est-ce que DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) est la couche de politique au-dessus de SPF et DKIM. Il indique aux serveurs de messagerie destinataires quoi faire lorsqu'un courriel échoue à l'authentification, et introduit le concept d'alignement.
v=DMARC1; p=none; rua=mailto:[email protected]
Que signifie l'alignement?
C'est là que la plupart des échecs DMARC se produisent. L'alignement signifie que le domaine dans l'en-tête De visible du courriel doit correspondre au domaine utilisé dans l'authentification SPF ou DKIM. Il existe deux modes :
- Alignement relaxé (par défaut) : Les sous-domaines sont autorisés.
mail.votredomaine.coms'aligne avecvotredomaine.com. - Alignement strict : Les domaines doivent correspondre exactement.
mail.votredomaine.comne s'aligne pas avecvotredomaine.com.
DMARC réussit si au moins un des protocoles SPF ou DKIM est valide et aligné avec le domaine De. Si aucun des deux ne passe l'alignement, DMARC échoue et votre politique détermine ce qui se passe ensuite.
Comment diagnostiquer un échec DMARC
Avant d'apporter des modifications, vous devez comprendre ce qui échoue réellement. Des modifications aveugles aux enregistrements DNS peuvent aggraver la situation.
Vérifier vos rapports DMARC
Si vous avez déjà un enregistrement DMARC avec une adresse de rapport (rua=), les principaux fournisseurs de messagerie vous envoient des rapports agrégés XML. Ces rapports vous indiquent exactement quelles adresses IP envoient en votre nom, et si SPF et DKIM réussissent ou échouent. Des outils comme MXToolbox DMARC Analyzer, Postmark DMARC Digests, ou Google Postmaster Tools peuvent analyser ces rapports XML en tableaux de bord lisibles.
Inspecter les en-têtes des courriels
Ouvrez un courriel en échec dans Gmail et sélectionnez Afficher l'original depuis le menu à trois points. Recherchez ces en-têtes :
Authentication-Resultsaffiche l'état de réussite ou d'échec de SPF, DKIM et DMARCReceived-SPFindique si SPF a réussi et quelle adresse IP a été vérifiéeDKIM-Signatureest présent si DKIM a été appliqué ; vérifiez que la balised=correspond à votre domaine De
Un échec DMARC dans les en-têtes ressemble à : dmarc=fail (p=none dis=none) header.from=votredomaine.com
Utiliser des outils de recherche DNS en ligne
Utilisez MXToolbox ou Google Admin Toolbox à toolbox.googleapps.com pour vérifier vos enregistrements SPF, DKIM et DMARC actuels. Recherchez un enregistrement SPF qui n'inclut pas Google ou des expéditeurs tiers, un enregistrement DKIM qui n'a jamais été publié, ou l'absence totale d'enregistrement DMARC.
Correction étape par étape pour Google Workspace
Étape 1 : Vérifier et mettre à jour votre enregistrement SPF
Connectez-vous à votre registraire de domaine ou au panneau de gestion DNS. Si votre domaine est géré via notre plateforme, vous trouverez cela sous Mes domaines dans votre espace client WHMCS. Recherchez un enregistrement TXT existant à la racine de votre domaine. Vous ne devez avoir qu'un seul enregistrement SPF. Plusieurs enregistrements SPF sur le même domaine causeront des échecs.
Si vous n'utilisez que Google Workspace pour envoyer des courriels :
v=spf1 include:_spf.google.com ~all
Si vous utilisez également d'autres services, ajoutez chacun d'eux :
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all
SPF a une limite de 10 recherches DNS. Si vous incluez trop de services, votre enregistrement SPF peut dépasser cette limite et commencer à échouer. Utilisez le vérificateur SPF de MXToolbox pour compter vos recherches avant de publier.
Étape 2 : Activer DKIM dans Google Workspace
DKIM n'est pas activé par défaut dans Google Workspace. Vous devez générer et publier la clé manuellement.
- Connectez-vous à votre Console d'administration Google Workspace à admin.google.com
- Accédez à Applications, puis Google Workspace, puis Gmail, puis Authentifier les e-mails
- Sélectionnez votre domaine dans le menu déroulant
- Cliquez sur Générer un nouvel enregistrement et choisissez une longueur de clé de 2048 bits
- Copiez le nom et la valeur de l'enregistrement TXT fournis
- Ajoutez cet enregistrement TXT à votre DNS avec l'hôte défini sur
google._domainkeyet la valeur étant la longue chaîne commençant parv=DKIM1; k=rsa; p=... - Attendez la propagation DNS, puis revenez à la Console d'administration et cliquez sur Démarrer l'authentification
Pour vérifier que DKIM fonctionne, envoyez un courriel de test à n'importe quelle adresse Gmail, ouvrez-le et vérifiez les en-têtes pour dkim=pass.
Étape 3 : Vérifier l'alignement du domaine
Il s'agit de l'étape la plus souvent ignorée. Même avec SPF et DKIM correctement configurés, DMARC peut toujours échouer si les domaines ne s'alignent pas.
Vérifiez les points suivants : votre adresse De utilise [email protected] et non un sous-domaine ou un domaine alias, sauf si vous avez configuré DKIM séparément pour ce sous-domaine.
La balise d= de la signature DKIM doit correspondre à votredomaine.com. L'envelope-from SPF, aussi appelé Return-Path, doit également s'aligner avec votre domaine De.
Un scénario de désalignement courant : vous configurez Google Workspace sur votredomaine.com, mais votre outil d'automatisation des courriels envoie depuis rebond.votredomaine.com ou son propre domaine. Ces courriels échoueront à l'alignement DMARC, sauf si vous configurez également DKIM sur ces services.
Étape 4 : Publier un enregistrement DMARC
Ajoutez un enregistrement TXT à votre DNS à l'hôte _dmarc, ce qui donne comme nom complet _dmarc.votredomaine.com.
Commencez par le mode de surveillance :
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
La balise p=none signifie surveillance uniquement, sans action sur les échecs. L'adresse rua reçoit les rapports agrégés quotidiens. L'adresse ruf reçoit les rapports légaux par échec. La balise fo=1 envoie des rapports légaux chaque fois que SPF ou DKIM échoue.
Après avoir examiné les rapports pendant deux à quatre semaines et confirmé l'alignement, passez à l'application :
v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]
Puis, une fois que vous êtes confiant :
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]
Configurer DMARC pour les services tiers
De nombreuses entreprises utilisent Google Workspace en parallèle avec d'autres outils qui envoient des courriels en leur nom : plateformes marketing, CRM, services de courriel transactionnel, systèmes de support. Chacun doit être correctement configuré pour maintenir l'alignement DMARC.
L'approche recommandée est de configurer la signature DKIM de domaine personnalisé sur chaque service tiers. La plupart des services réputés comme Mailchimp, SendGrid, Mailgun et HubSpot le supportent. Vous ajoutez un enregistrement CNAME ou TXT qu'ils fournissent à votre DNS, ce qui leur permet de signer les courriels sortants avec votre domaine.
Si vous préférez ne pas configurer DKIM sur chaque outil tiers, l'alternative est d'envoyer depuis un sous-domaine. Au lieu d'envoyer des courriels marketing depuis [email protected], envoyez depuis [email protected] et configurez SPF et DKIM spécifiquement pour ce sous-domaine. Cela maintient la réputation de votre domaine principal isolée.
Inclusions SPF courantes pour les services tiers :
- SendGrid :
include:sendgrid.net - Mailgun :
include:mailgun.org - Mailchimp :
include:servers.mcsv.net - HubSpot :
include:hubspotemail.net - Zendesk :
include:mail.zendesk.com - Microsoft 365 :
include:spf.protection.outlook.com
Gestion des enregistrements DNS via WHMCS
Si votre domaine est enregistré ou votre hébergement géré via notre portail client, vous pouvez mettre à jour tous les enregistrements DNS directement sans avoir besoin d'accéder à un panneau de contrôle séparé. Accédez à Mes domaines, cliquez sur Gérer à côté du domaine concerné, et sélectionnez Gestion DNS. Tous les enregistrements SPF, DKIM et DMARC utilisent le type d'enregistrement TXT.
Pour SPF, définissez l'hôte sur @ et la valeur sur votre chaîne SPF complète. Pour DKIM, définissez l'hôte sur google._domainkey et la valeur sur la chaîne de clé copiée depuis la Console d'administration Google. Pour DMARC, définissez l'hôte sur _dmarc et la valeur sur votre chaîne de politique.
Si vous ne voyez pas d'option de gestion DNS dans votre espace client, contactez notre équipe de support car la gestion DNS devra peut-être être activée pour votre compte.
Causes courantes des échecs DMARC
Plusieurs enregistrements SPF sur le même domaine
Un seul enregistrement SPF est autorisé par domaine. Si vous avez deux enregistrements TXT commençant tous les deux par v=spf1, le résultat est indéfini et causera des échecs. Fusionnez toutes les inclusions en un seul enregistrement.
DKIM jamais activé dans Google Workspace
Google Workspace n'active pas DKIM automatiquement lors de la configuration. Si cette étape a été ignorée, chaque courriel quitte votre serveur sans signature et l'alignement DMARC via DKIM échouera toujours.
Clé DKIM pas encore propagée
Après avoir publié l'enregistrement TXT DKIM, Google Workspace peut indiquer qu'il ne trouve pas la clé si la propagation n'est pas terminée. Attendez jusqu'à 48 heures et vérifiez que l'enregistrement est publiquement visible via MXToolbox avant de cliquer sur Démarrer l'authentification.
Enregistrements DNS obsolètes après migration
Migrer vers Google Workspace depuis un autre fournisseur sans nettoyer les anciennes inclusions SPF et les enregistrements DKIM est l'une des causes les plus fréquentes d'échecs intermittents. Les enregistrements de l'ancien fournisseur restent dans le DNS et créent une confusion d'authentification. Supprimez tout ce qui provient du fournisseur précédent une fois que Google Workspace est confirmé comme fonctionnel.
Outil tiers envoyant sans alignement DKIM
Un CRM, un outil marketing ou un service de courriel transactionnel envoie en votre nom en utilisant son propre domaine, causant un désalignement entre l'adresse De et le domaine de signature DKIM. Configurez la signature DKIM de domaine personnalisé sur ce service ou déplacez ces envois vers un sous-domaine dédié.
Transfert de courriel brisant SPF
SPF n'a pas été conçu pour survivre au transfert de courriels. Lorsqu'un message est transféré via un relais, l'adresse IP d'envoi change et SPF échoue. DKIM est plus résilient dans ce scénario puisque la signature voyage avec le message. Si le transfert est impliqué, utilisez DKIM comme mécanisme d'alignement principal.
Comment vérifier que tout fonctionne
Après avoir apporté vos modifications, attendez la propagation DNS et vérifiez à l'aide des méthodes suivantes.
Envoyez un courriel de test à mail-tester.com. L'outil vous donne un score sur 10 et vous montre exactement ce qui a réussi et ce qui a échoué, y compris l'alignement SPF, DKIM et DMARC.
Utilisez Google Admin Toolbox à toolbox.googleapps.com et exécutez l'outil Vérifier MX sur votre domaine. Il signale les erreurs de configuration courantes et affiche le contenu complet de vos enregistrements DNS.
Envoyez-vous un courriel de test et vérifiez les en-têtes bruts. Vous voulez voir dkim=pass, spf=pass et dmarc=pass dans l'en-tête Authentication-Results. Les trois doivent afficher pass avant de considérer la configuration comme complète.
Conseils d'experts issus de déploiements réels
Ne vous précipitez pas vers p=reject. Commencez par p=none, examinez les rapports pendant deux à quatre semaines, puis passez à p=quarantine avant d'aller à p=reject. Sauter ce processus peut bloquer des courriels légitimes provenant de services dont vous aviez oublié qu'ils envoyaient en votre nom.
Utilisez l'isolation par sous-domaine pour les courriels transactionnels et marketing. Envoyer depuis [email protected] plutôt que depuis votre domaine racine protège la réputation de votre domaine principal de tout problème de délivrabilité lié à ces flux.
Abaissez votre TTL avant d'apporter des modifications. Définissez-le à 300 secondes la veille de toute modification DNS. Cela accélère la propagation et rend les retours en arrière plus rapides si quelque chose tourne mal.
Surveillez Google Postmaster Tools à postmaster.google.com. Cet outil vous montre comment Gmail perçoit la réputation de votre domaine, la conformité DMARC et les taux de spam, gratuitement. C'est l'un des outils les plus sous-utilisés disponibles pour les propriétaires de domaines.
Chaque fois que vous intégrez un nouvel outil SaaS qui envoie des courriels en votre nom, revenez vérifier votre enregistrement SPF. Il est facile d'oublier, et un service envoyant des courriels non authentifiés depuis votre domaine peut silencieusement nuire à votre réputation pendant des mois avant que vous ne le remarquiez.
Quand contacter le support?
La plupart des problèmes d'alignement DMARC se résolvent une fois que le DNS est corrigé et que DKIM est correctement activé. Mais certaines situations nécessitent une investigation plus approfondie : des échecs intermittents qui n'affectent que certains destinataires, un nombre de recherches SPF dépassant la limite de 10, des échecs de vérification de signature DKIM malgré des enregistrements DNS corrects, ou des environnements multi-domaines complexes où l'alignement est difficile à retracer.
Si vous avez suivi les étapes ci-dessus et observez toujours des échecs, ouvrez un ticket de support depuis votre espace client en incluant un exemple d'en-tête de courriel. L'en-tête seul contient suffisamment d'informations pour identifier la cause principale dans la plupart des cas et réduit considérablement le temps de diagnostic.
Pourquoi Google Workspace n'envoie pas de rapports RUF forensiques (et quoi faire à la place)
Si votre enregistrement DMARC inclut une balise ruf= pointant vers une adresse de rapport, vous avez peut-être remarqué que Google Workspace n'envoie jamais de rapports forensiques à cette adresse. Il ne s'agit pas d'une mauvaise configuration de votre côté. Google Workspace ne génère délibérément aucun rapport RUF forensique, peu importe la structure de votre enregistrement DMARC. C'est la politique officielle de Google et elle s'applique à tous les domaines Google Workspace.
Les rapports RUF, également appelés rapports forensiques, sont des rapports au niveau du message qui contiennent les en-têtes ou le contenu expurgé des courriels individuels ayant échoué à DMARC. Comme ils peuvent contenir des données de message sensibles, de nombreux fournisseurs dont Google ont choisi de ne pas les générer. Google envoie uniquement des rapports agrégés RUA, qui résument les résultats d'authentification sur toutes vos sources d'envoi sur une fenêtre de 24 heures sans inclure le contenu des messages.
La conséquence pratique est que si vous comptez sur les rapports RUF pour diagnostiquer des échecs DMARC spécifiques pour les expéditeurs Google Workspace, vous ne les recevrez pas. Ce que vous recevrez sont des rapports agrégés RUA, qui contiennent suffisamment d'informations pour identifier quelles sources d'envoi échouent et pourquoi.
Quoi configurer à la place
Assurez-vous que votre enregistrement DMARC inclut une balise rua= avec une adresse de rapport valide. Google Workspace enverra des rapports agrégés à cette adresse. Un enregistrement DMARC de base avec rapport agrégé ressemble à ceci :
v=DMARC1; p=none; rua=mailto:[email protected]
Comme les rapports RUA sont au format XML et difficiles à lire directement, utilisez un service d'analyse de rapports DMARC pour les rendre exploitables. Les options qui fonctionnent bien avec les données agrégées Google Workspace incluent Postmark DMARC Digests, Dmarcian, la surveillance DMARC de MXToolbox, et les Outils pour les postmasters de Google, qui fournissent des données de délivrabilité et d'authentification spécifiques aux courriels envoyés aux destinataires Gmail.
Google Postmaster Tools est particulièrement utile pour les expéditeurs Google Workspace car il affiche le taux de spam de votre domaine, la réputation IP et le taux de réussite d'authentification DMARC tel que vu par Gmail. Pour le configurer, accédez à postmaster.google.com, ajoutez votre domaine et vérifiez la propriété via un enregistrement DNS TXT. Une fois vérifié, le tableau de bord se remplit dans les quelques jours suivant l'activité d'envoi.
Si vous constatez des échecs DMARC dans vos rapports agrégés et ne pouvez pas isoler quelle source est responsable faute de détails forensiques, le champ source ip du rapport agrégé combiné à une recherche DNS inverse sur cette IP est généralement suffisant pour identifier le service d'envoi. À partir de là, vous pouvez configurer DKIM pour ce service ou ajouter son infrastructure d'envoi à votre enregistrement SPF pour le mettre en alignement.
Gotekky
Besoin d’aide pour choisir la prochaine étape?
Décrivez ce que vous observez et le résultat recherché. Nous identifierons si un service géré, un projet défini ou une évaluation technique payante est la bonne prochaine étape.