DMARC Google Workspace : configuration

Que vérifie concrètement le DMARC dans Google Workspace ?

Le DMARC indique aux serveurs destinataires quoi faire des e-mails qui affichent votre domaine dans l'en-tête From visible sans pouvoir le prouver. Selon la spécification DMARC, un message passe lorsque le SPF ou le DKIM passe et que le domaine validé est aligné sur le domaine du From. L'un des deux suffit. Dans Google Workspace, le DKIM signe avec la clé que vous générez dans la console d'administration (le sélecteur par défaut est google), et le SPF couvre les serveurs de Google via include:_spf.google.com. Ces deux enregistrements se trouvent sur votre domaine. Le DMARC vient se poser par-dessus ces deux contrôles et les transforme en politique. Beaucoup ne s'y attendent pas : Google Workspace ne publie jamais d'enregistrement DMARC pour vous. La console d'administration propose une page pour le DKIM, mais aucune pour le DMARC. C'est à vous d'ajouter l'enregistrement chez votre hébergeur DNS, et il couvre tous les services qui envoient au nom de votre domaine, pas seulement Gmail. Les consignes de Google pour les expéditeurs d'e-mails (Email sender guidelines) exigent des expéditeurs en masse vers des comptes Gmail personnels un enregistrement DMARC publié. p=none est accepté, et le domaine du From doit être aligné sur le SPF ou le DKIM.

Comment configurer le DMARC pour Google Workspace ?

Configurer le DMARC pour Google Workspace est une tâche DNS, et les étapes suivent un ordre précis. Google recommande lui-même que le SPF et le DKIM authentifient déjà vos e-mails avant de publier le DMARC. Ainsi, vos premiers rapports agrégés reflètent une configuration qui fonctionne, et non un domaine à moitié paramétré. Si vos enregistrements MX, SPF et DKIM ne sont pas encore en place, commencez par les enregistrements DNS de Google Workspace pour le MX, le SPF et le DKIM, puis revenez une fois qu'ils sont actifs.

1. 1 Publiez le SPF sous la forme d'un seul enregistrement TXT à la racine du domaine, contenant include:_spf.google.com. Le SPF limite le nombre de mécanismes qui déclenchent une requête DNS (include, a, mx, ptr, exists, redirect) lors d'une même vérification. Chaque include ajouté pour un autre expéditeur compte dans cette limite, et la dépasser renvoie un permerror au lieu d'un pass.
2. 2 Dans la console d'administration, allez dans Applications, Google Workspace, Gmail, Authentifier les e-mails, et générez une clé DKIM. Choisissez la longueur de clé la plus élevée, sauf si votre hébergeur DNS ne peut pas la stocker. Publiez l'enregistrement TXT google._domainkey, puis cliquez sur Démarrer l'authentification.
3. 3 Attendez que vos e-mails envoyés affichent dkim=pass et spf=pass dans l'en-tête Authentication-Results. Tant que ce n'est pas le cas, un enregistrement DMARC ne fait que rendre compte d'une configuration inachevée.
4. 4 Créez un enregistrement TXT avec l'hôte _dmarc et la valeur v=DMARC1; p=none; rua=mailto:votre-adresse-de-rapport.
5. 5 Vérifiez-le avec dig TXT _dmarc.votredomaine.com. Un seul et unique enregistrement commençant par v=DMARC1 doit être renvoyé.

À quoi doit ressembler l'enregistrement DMARC pour Google Workspace ?

Un enregistrement DMARC pour Google Workspace ressemble à celui de n'importe quel autre domaine. Google n'exige aucune balise particulière, et il n'y a aucune valeur propre à Google à copier-coller. Une première version raisonnable est v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com. Elle collecte les données des rapports sans demander aux destinataires d'agir sur les échecs. Le tableau ci-dessous liste les balises que vous modifierez réellement et ce qui se passe si vous en omettez une. Seules v et p sont obligatoires, et v=DMARC1 doit figurer en premier.

Balise	Rôle	Valeur de départ
v	Version ; doit être la première balise	DMARC1
p	Politique du domaine : none, quarantine ou reject	none
rua	Adresse de réception des rapports agrégés (XML)	mailto:dmarc@votredomaine.com
sp	Politique des sous-domaines ; hérite de p si omise	à omettre au début
adkim / aspf	Mode d'alignement : r (relâché, par défaut) ou s (strict)	laisser la valeur par défaut r
pct	Part des e-mails en échec à laquelle la politique s'applique ; si omise, elle s'applique à tous les e-mails en échec	à omettre tant que p=none

Deux erreurs reviennent sans cesse. La première consiste à publier deux enregistrements TXT sur _dmarc. Si une requête trouve plus d'un enregistrement DMARC, la spécification demande aux destinataires de n'appliquer aucun traitement DMARC. La seconde consiste à faire pointer rua vers une boîte aux lettres d'un autre domaine alors que ce domaine n'a pas publié d'enregistrement d'autorisation sur votredomaine.com._report._dmarc.autredomaine.com. Sans cet enregistrement, les rapports n'arrivent jamais.

Quand passer de p=none à quarantine ou reject ?

Ne changez de politique qu'une fois que les rapports agrégés montrent que toutes les sources légitimes qui envoient au nom de votre domaine passent le DMARC : Google Workspace, Brevo, votre CRM, vos outils de facturation et tout le reste. Chaque destinataire envoie ses rapports à intervalle régulier et ne couvre que les e-mails reçus sur cette période ; une seule série de rapports ne montre donc que les expéditeurs actifs à ce moment-là. Attendez assez longtemps pour repérer les expéditeurs occasionnels, comme un système de facturation qui ne tourne qu'une fois par mois. Ensuite, montez par paliers : d'abord p=quarantine, éventuellement avec une valeur pct pour ne couvrir qu'une partie des e-mails en échec, puis p=reject. Passer directement à reject est l'erreur la plus fréquente. Si un outil oublié envoie des factures depuis votre domaine, les destinataires qui respectent la politique refuseront ces e-mails, et personne ne s'en rendra compte avant qu'un client ne réclame sa facture. Le transfert est l'autre point faible connu : les e-mails transférés cassent souvent le SPF, et les listes de diffusion qui réécrivent le corps du message cassent le DKIM, si bien que certains e-mails légitimes échoueront sous n'importe quelle politique stricte. Pour un domaine de prospection à froid, p=none avec des rapports propres satisfait déjà le minimum DMARC des consignes de Google pour les expéditeurs d'e-mails. Durcir la politique est une décision distincte, liée au risque d'usurpation, et non un levier de délivrabilité. La vue d'ensemble se trouve dans notre guide DKIM, DMARC et SPF pour les expéditeurs de cold emails.

Avant de durcir, vérifiez ces points dans chaque rapport agrégé :

• Chaque IP d'envoi doit appartenir à une source que vous connaissez. Une source inconnue qui envoie au nom de votre domaine est soit un outil oublié, soit une usurpation, et vous devez savoir laquelle avant de passer à reject.
• Les résultats DKIM indiquent le domaine d=. Un pass sur le propre domaine d'un fournisseur n'est pas aligné sur votre domaine From et ne compte pas pour le DMARC.
• Les résultats SPF indiquent le domaine d'enveloppe. Un pass pour le domaine de rebond d'un fournisseur n'est pas aligné non plus.
• La colonne disposition. En p=none, elle doit indiquer none sur chaque ligne. En quarantine, tout e-mail que vous avez vous-même envoyé et qui apparaît en quarantaine provient d'une source que vous avez oubliée.

Comment EmailFlow OS s'intègre-t-il à une configuration DMARC Google Workspace ?

EmailFlow OS n'ajoute aucun expéditeur qui lui serait propre sur votre domaine : vous n'avez donc aucune source supplémentaire à autoriser dans votre enregistrement DMARC. Vous enregistrez une seule vidéo et la téléversez dans EmailFlow OS, vous connectez votre compte Brevo et votre domaine d'envoi, puis vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS personnalise ensuite cet unique enregistrement pour chaque destinataire, et non pour chaque entreprise, et envoie chaque version depuis votre propre boîte, via votre compte Brevo et votre domaine d'envoi. Aucune adresse partagée de plateforme n'apparaît dans le champ From.

Le résultat DMARC de ces messages dépend donc d'enregistrements que vous contrôlez déjà : la clé DKIM de Brevo publiée sur votre domaine et votre unique enregistrement TXT _dmarc. La clé DKIM de Google ne sert à rien pour les e-mails envoyés par Brevo, car Brevo signe avec sa propre clé. Le Return-Path des e-mails Brevo se trouve généralement sur le domaine de Brevo, c'est donc au DKIM seul d'assurer l'alignement. La publication des deux clés côte à côte est traitée dans notre article sur le DKIM G Suite avec l'enregistrement Google et la configuration Brevo. Si vos e-mails Brevo sont déjà alignés dans vos rapports agrégés, les e-mails vidéo empruntent le même chemin. Sinon, corrigez les enregistrements DKIM de Brevo avant d'envoyer, car aucun outil ne peut aligner une signature que votre DNS ne publie pas. L'acceptation du message reste, dans tous les cas, la décision du serveur destinataire. Sur un nouveau domaine, augmentez d'abord progressivement les volumes, comme décrit dans notre guide du warm-up e-mail avec volumes quotidiens et configuration DNS.

Questions fréquentes

? Google Workspace crée-t-il automatiquement un enregistrement DMARC ?

Non. La console d'administration génère votre clé DKIM et vous affiche l'enregistrement google._domainkey, mais elle ne crée jamais de DMARC. Vous publiez chez votre hébergeur DNS un enregistrement TXT sur _dmarc.votredomaine.com, qui commence par v=DMARC1 et contient une balise p. Sans lui, les destinataires n'appliquent aucune politique DMARC à votre domaine, et vous ne respectez pas l'exigence DMARC des consignes de Google pour les expéditeurs en masse vers Gmail.

? Puis-je avoir deux enregistrements DMARC, un pour Google et un pour Brevo ?

Non. Un domaine a exactement un enregistrement DMARC sur _dmarc. Si une requête renvoie plus d'un enregistrement v=DMARC1, la spécification DMARC demande aux destinataires de n'appliquer aucun traitement DMARC. Google Workspace et Brevo partagent cet unique enregistrement. Chaque service a besoin de sa propre clé DKIM alignée, mais la politique tient en une seule entrée TXT.

? p=none suffit-il pour les exigences d'expéditeur de Gmail ?

Oui, pour la partie DMARC. Pour les expéditeurs en masse vers Gmail, les consignes de Google pour les expéditeurs d'e-mails exigent un enregistrement DMARC publié avec au minimum p=none et un domaine From aligné sur le SPF ou le DKIM. Elles exigent aussi un faible taux de spam signalé par les utilisateurs, que vous pouvez suivre dans Google Postmaster Tools. Avec p=none, vous recevez quand même les rapports agrégés. Contrairement à quarantine ou reject, cette politique ne demande simplement pas aux destinataires d'agir sur les e-mails en échec.