Configurer les enregistrements MX, SPF, DKIM et DMARC de Google Workspace

Étapes

1. Vérifiez le domaine. Ajoutez votre domaine dans la console d'administration Google et publiez l'enregistrement TXT de vérification qu'elle affiche. La valeur est propre à votre compte.
2. Créez les utilisateurs. Créez chaque boîte aux lettres et chaque alias avant de déplacer les MX, afin qu'aucune adresse ne soit rejetée après la bascule.
3. Publiez l'enregistrement MX. Supprimez les enregistrements MX de l'ancien fournisseur et ajoutez un seul enregistrement MX de priorité 1 qui pointe vers smtp.google.com.
4. Publiez SPF. Ajoutez un enregistrement TXT à l'apex : v=spf1 include:_spf.google.com ~all. Si d'autres services envoient pour le domaine, ajoutez leur include: au même enregistrement.
5. Activez DKIM. Dans la console d'administration, générez une clé de 2048 bits, publiez l'enregistrement TXT qu'elle affiche sous google._domainkey, puis revenez dans ces mêmes paramètres DKIM et lancez-y l'authentification. Tant que vous ne l'avez pas fait, Google signe avec son propre domaine et DKIM ne s'aligne pas sur le vôtre.
6. Ajoutez DMARC et contrôlez. Publiez un enregistrement DMARC avec p=none, puis lancez les vérifications de cette page.

DMARC

DMARC est identique chez tous les fournisseurs : un enregistrement TXT sous _dmarc.example.com. Commencez par p=none et une adresse de rapport, afin de recevoir des rapports sans affecter la livraison.

Lisez les rapports pendant quelques semaines. Lorsque chaque expéditeur légitime réussit SPF ou DKIM avec un domaine aligné, passez à p=quarantine, puis à p=reject. Passer à reject avant que DKIM soit activé pour tous les expéditeurs est la façon habituelle de perdre des e-mails légitimes.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Facultatif : MTA-STS, TLS-RPT et BIMI

MTA-STS demande aux serveurs expéditeurs d'exiger TLS lorsqu'ils vous livrent des e-mails. Il lui faut un enregistrement TXT et un fichier de politique servi en HTTPS sous mta-sts.example.com ; la politique doit lister exactement les hôtes MX de votre fournisseur.

TLS-RPT demande aux expéditeurs de signaler les échecs de livraison TLS à une adresse que vous choisissez. Un seul enregistrement TXT, sans effet sur la livraison.

BIMI permet à certains fournisseurs de messagerie d'afficher votre logo. Il exige DMARC en quarantine ou en reject, et la plupart des fournisseurs exigent aussi un certificat de marque vérifiée.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

Conseils sur le TTL

Avant de modifier les enregistrements MX d'un domaine qui reçoit déjà des e-mails, abaissez leur TTL à 300 secondes et attendez que l'ancien TTL soit écoulé. Les résolveurs prennent alors en compte les nouveaux enregistrements en quelques minutes.

Quand la nouvelle configuration fonctionne depuis quelques jours, remontez le TTL : 3600 secondes est une valeur courante. Les enregistrements SPF, DKIM et DMARC changent rarement et peuvent rester à 3600.

Combien de temps prennent les modifications ?

Vos serveurs de noms faisant autorité répondent avec le nouvel enregistrement dès que votre hébergeur DNS l'a publié. Un résolveur qui a mis l'ancienne réponse en cache la garde jusqu'à l'expiration de l'ancien TTL ; un nom qui n'existait pas auparavant peut être mémorisé comme absent pendant la durée de cache négatif de votre enregistrement SOA.

Il n'existe aucun moment où une modification est présente partout à la fois. L'outil de propagation montre ce que répond un ensemble fixe de résolveurs publics au moment de la vérification, sous forme d'un décompte tel que « 9 résolveurs sur 12 », et rien de plus.

Les fournisseurs recontrôlent vos enregistrements à leur propre rythme ; un bouton de vérification dans l'interface peut donc rester rouge un moment alors que le DNS est déjà correct.

Erreurs fréquentes

• Publier l'enregistrement DKIM sans jamais lancer l'authentification dans la console d'administration.
• Garder ~all indéfiniment est acceptable avec Google ; c'est le passage à -all avant que chaque expéditeur soit listé qui casse les services de transfert et les outils d'envoi.
• Deux enregistrements SPF. Un domaine ne peut avoir qu'un seul enregistrement TXT commençant par v=spf1 ; un second fait échouer SPF avec une erreur permanente. Fusionnez les mécanismes include: dans un seul enregistrement.
• Laisser les enregistrements MX de l'ancien fournisseur à côté des nouveaux. Les e-mails sont alors livrés à l'un ou à l'autre, selon la priorité et le hasard.
• Saisir le nom complet dans un champ d'hôte qui ajoute le domaine, ce qui produit google._domainkey.example.com.example.com. Recherchez l'enregistrement après l'avoir enregistré.
• Une clé DKIM coupée en deux. Les valeurs TXT longues doivent être découpées en chaînes entre guillemets de 255 caractères au plus ; la plupart des hébergeurs DNS le font pour vous, certains non.
• Plus de dix requêtes DNS dans SPF après l'ajout de plusieurs mécanismes include:. La vérification SPF les compte.
• Un enregistrement MX qui pointe vers un CNAME ou vers une adresse IP. Il doit pointer vers un nom d'hôte qui possède des enregistrements A ou AAAA.