DNS Google Workspace : MX, SPF, DKIM, DMARC

Quels enregistrements DNS Google Workspace faut-il vraiment pour un domaine ?

Un domaine Google Workspace a besoin d'un petit ensemble fixe d'enregistrements DNS. Chacun a son propre rôle, et la plupart des configurations ratées viennent d'une confusion entre eux. La validation prouve à Google que le domaine vous appartient. Le MX indique aux autres serveurs où livrer le courrier qui vous est destiné. SPF, DKIM et DMARC couvrent les e-mails que vous envoyez. Si vous comptez faire de la prospection à froid depuis ce domaine, aucun des enregistrements de ce tableau n'est facultatif. Les consignes de Gmail pour les expéditeurs attendent une authentification de chaque expéditeur, et ses règles pour les envois en masse exigent SPF, DKIM et un enregistrement DMARC d'au moins p=none.

Enregistrement	Type	Hôte / nom	Valeur (exemple)
Validation du domaine	TXT	@	google-site-verification=… (chaîne fournie par la console d'administration)
Courrier entrant	MX	@	smtp.google.com, priorité 1
SPF	TXT	@	v=spf1 include:_spf.google.com ~all
DKIM	TXT	google._domainkey	v=DKIM1; k=rsa; p=… (générée dans la console d'administration)
DMARC	TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com

Les modifications DNS ne s'appliquent pas instantanément. Les résolveurs continuent de servir l'ancienne valeur jusqu'à expiration du TTL de l'enregistrement : vérifiez donc l'enregistrement en ligne avec dig avant de conclure qu'une modification a échoué.

Quels enregistrements DNS Google Workspace pour l'envoi d'e-mails ?

Les enregistrements qui concernent l'envoi sont SPF, DKIM et DMARC. Le MX ne couvre que la réception. SPF liste les serveurs autorisés à envoyer pour votre domaine. DKIM ajoute une signature cryptographique que les destinataires vérifient à l'aide d'une clé publique publiée dans le DNS. DMARC indique aux destinataires quoi faire lorsque le domaine From d'un message n'est pas aligné avec un résultat SPF ou DKIM valide. Configurez-les dans cet ordre :

1. 1 SPF : publiez exactement un enregistrement TXT à la racine, qui commence par v=spf1 et inclut _spf.google.com. Si vous publiez deux enregistrements SPF, le résultat est un permerror et SPF échoue.
2. 2 DKIM : dans la console d'administration, allez dans Applications > Google Workspace > Gmail > Authentifier les e-mails, générez une clé et publiez-la sous forme d'enregistrement TXT sur google._domainkey.
3. 3 Activation DKIM : une fois l'enregistrement résolu, revenez sur le même écran et cliquez sur Commencer l'authentification (Start authentication). Tant que vous ne l'avez pas fait, Gmail ne signe pas avec votre clé.
4. 4 DMARC : publiez v=DMARC1; p=none avec une adresse rua pour recevoir les rapports agrégés avant de durcir la politique.
5. 5 Restez sous la limite de requêtes DNS de SPF. Chaque include compte, tout comme les include imbriqués qu'il contient.

Une clé DKIM longue peut dépasser la longueur maximale autorisée pour une seule chaîne TXT. Certains hébergeurs DNS la découpent automatiquement, d'autres non : vérifiez chez le vôtre comment la valeur est enregistrée, et contrôlez ensuite que la clé publiée est complète.

Quels sont les enregistrements MX Google Workspace ?

Les domaines Google Workspace récents utilisent un seul enregistrement MX qui pointe vers smtp.google.com. Les domaines plus anciens ont souvent encore l'ancien jeu de plusieurs enregistrements, avec ASPMX.L.GOOGLE.COM comme hôte principal et plusieurs hôtes ALT en secours, et Google le prend toujours en charge. Vous pouvez garder l'un ou l'autre, mais ne les mélangez pas et ne laissez aucun enregistrement pointer vers votre ancien hébergeur. Lorsque plusieurs MX coexistent, les serveurs expéditeurs essaient d'abord celui dont la valeur de priorité est la plus basse. Un MX résiduel qui pointe vers un ancien fournisseur répartit donc votre courrier entrant entre deux systèmes.

Configuration	Hôte MX	Priorité
Actuelle (enregistrement unique)	smtp.google.com	1
Ancienne	ASPMX.L.GOOGLE.COM	1
Ancienne	ALT1.ASPMX.L.GOOGLE.COM	5
Ancienne	ALT2.ASPMX.L.GOOGLE.COM	5
Ancienne	ALT3.ASPMX.L.GOOGLE.COM	10
Ancienne	ALT4.ASPMX.L.GOOGLE.COM	10

Le MX n'a aucun effet sur l'authentification sortante, mais il compte en prospection à froid. Les réponses à vos messages partent vers l'adresse indiquée en From ou en Reply-To : si le MX est faux, ces réponses rebondissent ou atterrissent dans une boîte que vous ne consultez jamais. Lancez dig MX votredomaine.com et vérifiez que seuls des hôtes Google apparaissent.

Les enregistrements DNS Google Workspace couvrent-ils les e-mails envoyés via Brevo ?

Non. La clé google._domainkey de Google ne signe que le courrier qui sort des serveurs de Google. Voici comment fonctionne EmailFlow OS : vous enregistrez une seule vidéo et vous la téléversez, vous connectez votre propre compte Brevo et votre domaine d'envoi, puis vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS crée ensuite une version personnalisée de cet enregistrement pour chaque destinataire, et non par entreprise, et l'envoie via votre compte Brevo, depuis votre domaine, jamais depuis une adresse partagée de la plateforme. C'est Brevo qui est le serveur d'envoi, pas Google. Le domaine a donc besoin des enregistrements DKIM de Brevo, exactement tels que Brevo les affiche dans ses paramètres d'authentification de domaine, en plus de ceux de Google. Les deux cohabitent parce que chacun utilise un sélecteur différent.

C'est sur le SPF qu'on se trompe le plus souvent. Regroupez tout dans un seul enregistrement, pas un par fournisseur. Chaque include consomme une partie de la limite de requêtes de SPF. L'alignement DMARC est validé dès que SPF ou DKIM est aligné avec le domaine From : c'est donc une clé DKIM Brevo publiée sur votre propre domaine qui permet au courrier envoyé par Brevo d'être aligné. Comme le domaine et le compte Brevo vous appartiennent, les enregistrements restent dans votre DNS et sous votre contrôle, sans dépendre d'un expéditeur mutualisé.

Pourquoi des enregistrements DNS Google Workspace échouent-ils alors qu'ils semblent corrects ?

La plupart des échecs s'expliquent par quelques causes que l'on repère avec dig, ou avec Afficher l'original dans Gmail, qui affiche les résultats SPF, DKIM et DMARC d'un message reçu :

• Deux enregistrements SPF à la racine : SPF renvoie un permerror, que les destinataires traitent comme un échec.
• Trop de requêtes DNS dans le SPF : même permerror, souvent dû à l'empilement d'un include par outil.
• Une clé DKIM publiée mais jamais activée : l'enregistrement existe, mais Gmail ne signe pas tant que vous n'avez pas cliqué sur Commencer l'authentification.
• Une clé DKIM tronquée : l'hébergeur DNS a coupé la valeur, la clé publique ne correspond donc plus à la signature.
• Un enregistrement DMARC sur le mauvais hôte : il doit se trouver sur _dmarc. Un enregistrement DMARC placé à la racine est ignoré.
• Un TTL pas encore expiré : vous avez modifié un enregistrement, mais les résolveurs servent l'ancienne valeur jusqu'à expiration du TTL.

Des enregistrements corrects sont un prérequis. Ils ne décident pas de l'endroit où vos e-mails arrivent, car c'est le serveur destinataire qui en décide. Un domaine tout neuf a toujours besoin d'une montée en volume progressive, autrement dit d'un warm-up, avant d'envoyer vos campagnes de prospection à plein régime.

Questions fréquentes

? Quel est l'enregistrement MX de Google Workspace ?

Les domaines récents utilisent un seul enregistrement MX qui pointe vers smtp.google.com. Les domaines plus anciens peuvent utiliser l'ancien jeu, avec ASPMX.L.GOOGLE.COM comme hôte principal et plusieurs hôtes ALT en secours. Google prend en charge les deux, mais n'en utilisez qu'un, et supprimez tout MX qui pointe vers votre ancien fournisseur. Sinon, le courrier entrant et les réponses se répartissent entre deux systèmes.

? Quel est l'enregistrement SPF de Google Workspace ?

C'est v=spf1 include:_spf.google.com ~all, publié sous forme d'un seul enregistrement TXT à la racine du domaine. Si vous envoyez aussi via Brevo ou un autre service, ajoutez son include dans ce même enregistrement au lieu d'en créer un second. Un domaine ne peut avoir qu'un seul enregistrement SPF, et SPF plafonne le nombre de requêtes DNS qu'un enregistrement peut déclencher.

? Combien de temps faut-il pour que les enregistrements DNS Google Workspace fonctionnent ?

Cela dépend du TTL de l'enregistrement. Les résolveurs servent la valeur en cache jusqu'à son expiration, si bien qu'une modification apparaît par étapes. DKIM demande une étape de plus : une fois l'enregistrement google._domainkey résolu, vous devez cliquer sur Commencer l'authentification dans la console d'administration pour que Gmail signe vos e-mails. Publier l'enregistrement ne suffit pas à activer la signature.

? Ai-je besoin de DMARC pour Google Workspace ?

Oui, si vous envoyez en masse. Les règles de Gmail pour les envois en masse exigent un enregistrement DMARC d'au moins p=none, et une politique p=none vous permet quand même de recevoir les rapports agrégés sans rien bloquer. Publiez-le sous forme d'enregistrement TXT sur _dmarc.votredomaine.com avec une adresse rua pour voir quels serveurs envoient au nom de votre domaine.