Enregistrements DNS Microsoft 365 : MX, SPF, DKIM, autodiscover et DMARC

Étapes

1. Ajoutez et vérifiez le domaine. Dans le centre d'administration Microsoft 365, ajoutez le domaine et publiez l'enregistrement TXT de vérification qu'il affiche (il commence par MS=).
2. Créez les boîtes aux lettres et attribuez les licences. Chaque adresse qui doit recevoir des e-mails a besoin d'une boîte aux lettres, d'une boîte partagée, d'un groupe ou d'un alias avant le déplacement des MX.
3. Publiez l'enregistrement MX. Copiez l'hôte MX depuis le centre d'administration. Il est dérivé de votre nom de domaine et se termine par mail.protection.outlook.com, ou par mx.microsoft pour les domaines dont le courrier entrant est protégé par DNSSEC. Priorité 0, et aucun autre enregistrement MX.
4. Publiez SPF. Ajoutez un enregistrement TXT à l'apex : v=spf1 include:spf.protection.outlook.com -all. Ajoutez les autres expéditeurs au même enregistrement.
5. Activez DKIM. Publiez les deux enregistrements CNAME selector1._domainkey et selector2._domainkey avec les cibles que le portail Defender affiche pour votre domaine, attendez qu'ils se résolvent, puis activez la signature pour le domaine.
6. Ajoutez autodiscover et DMARC, puis contrôlez. Publiez le CNAME autodiscover pour qu'Outlook trouve la boîte aux lettres, ajoutez 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"

Clients de messagerie : autodiscover et autoconfig

Outlook localise la boîte aux lettres grâce à l'enregistrement CNAME autodiscover.example.com → autodiscover.outlook.com. Sans lui, Outlook pour ordinateur peut demander les paramètres du serveur ou se connecter à un ancien serveur local qui répond encore sous ce nom.

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

• Construire à la main l'hôte MX ou les cibles DKIM. Un seul caractère de différence suffit à faire échouer la vérification.
• Activer DKIM avant que les deux enregistrements CNAME se résolvent : le portail refuse, et les e-mails restent signés avec le domaine onmicrosoft.com, qui ne s'aligne pas pour DMARC.
• 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.