Enregistrements DNS e-mail : MX, SPF, DKIM et DMARC

La messagerie repose sur plusieurs enregistrements DNS qui remplissent des rôles différents. Les enregistrements MX indiquent aux systèmes de messagerie expéditeurs où livrer les messages entrants d'un domaine. SPF publie, dans des données TXT, une politique indiquant quels systèmes d'envoi sont autorisés. DKIM utilise une clé publique publiée dans le DNS pour que les destinataires puissent vérifier une signature cryptographique, et DMARC indique aux destinataires comment évaluer les messages dont l'alignement échoue et où envoyer les rapports. Ces mécanismes sont complémentaires : un enregistrement MX correct n'authentifie pas le courrier sortant, et un enregistrement SPF valide ne configure pas la livraison entrante.

Le routage entrant commence par MX

Un serveur de messagerie expéditeur interroge les enregistrements MX du domaine destinataire et reçoit un ou plusieurs noms d'hôte d'échangeurs de messagerie, accompagnés de valeurs de préférence. Les nombres de préférence les plus bas sont privilégiés lorsque plusieurs destinations sont disponibles, même si les systèmes de livraison peuvent appliquer une logique de nouvelle tentative et de disponibilité. Les noms d'hôte cibles doivent ensuite eux-mêmes être résolus en adresses. Si le domaine n'a pas d'enregistrement MX, le comportement du courrier peut se rabattre sur d'autres règles DNS, mais s'appuyer sur ce repli implicite est généralement moins clair que de publier la configuration voulue. Comparez les valeurs MX aux instructions de configuration actuelles du fournisseur de messagerie et vérifiez le domaine racine exact utilisé pour le courrier.

SPF est publié sous forme d'enregistrement TXT au niveau du domaine concerné et évalué par rapport à l'expéditeur qui se connecte. Il comporte des limites de recherches et des règles de syntaxe : copier plusieurs chaînes SPF indépendantes dans des enregistrements TXT séparés peut donc provoquer un permerror. Les enregistrements DKIM sont généralement publiés sous des noms propres à un sélecteur, fournis par l'expéditeur, et l'absence d'un sélecteur peut rendre les signatures invérifiables. DMARC utilise un nom bien connu sous _dmarc et peut démarrer en mode de surveillance avant d'envisager une politique plus stricte. Évitez d'inventer des valeurs : obtenez-les auprès de chaque plateforme de messagerie autorisée à envoyer au nom du domaine.

Pourquoi l'authentification du courrier exige un alignement

DMARC vérifie si le domaine From visible d'un message est aligné avec un domaine authentifié par SPF ou DKIM, selon le mode d'alignement configuré. Cela aide les destinataires à distinguer l'usage autorisé d'un domaine des messages qui prétendent simplement en provenir. Un domaine peut réussir SPF mais échouer à DMARC si l'expéditeur d'enveloppe authentifié n'est pas aligné avec le domaine From visible, et une signature DKIM peut échouer si la clé publiée est absente ou incorrecte. Les plateformes de messagerie recourent souvent à plusieurs services d'envoi : toutes les sources légitimes doivent donc être inventoriées avant de durcir une politique.

• Listez tous les systèmes qui envoient du courrier pour le domaine avant de modifier SPF.
• Publiez les sélecteurs DKIM fournis par les prestataires et vérifiez le nom exact du sélecteur.
• Démarrez les rapports DMARC avec une politique adaptée à votre niveau de préparation à la surveillance.
• Contrôlez les priorités MX et la résolution des adresses cibles après les migrations de fournisseur.
• Examinez les rapports agrégés et enquêtez sur les expéditeurs inconnus avant de passer à l'application stricte.

Vérifier les enregistrements après une migration

Lorsque vous changez de fournisseur de messagerie, exportez l'ancienne configuration DNS, puis comparez les nouveaux enregistrements MX, SPF, DKIM et DMARC avec la liste de contrôle de configuration du nouveau fournisseur. Certains fournisseurs exigent un enregistrement TXT de vérification de domaine en plus des enregistrements de messagerie. Ne gardez les anciens systèmes d'envoi autorisés que tant qu'ils envoient encore du trafic légitime, et retirez avec précaution les autorisations obsolètes après surveillance. La mise en cache liée au TTL DNS fait que tous les destinataires ne voient pas un changement en même temps. Confirmez les réponses publiques et envoyez des messages de test vers des systèmes destinataires représentatifs, mais rappelez-vous que les résultats de livraison dépendent aussi de la réputation, du contenu et du filtrage côté destinataire.

Une recherche DNS peut montrer si les enregistrements sont visibles publiquement ; elle ne peut pas, à elle seule, prouver qu'un message arrivera en boîte de réception. Le guide des enregistrements MX et l'explication de SPF, DKIM et DMARC couvrent chaque mécanisme. Utilisez un vérificateur DNS pour inspecter des noms et des types précis, puis validez en envoyant des messages de test contrôlés et en consultant les journaux du fournisseur. Séparer le routage et l'authentification dans votre liste de contrôle rend les changements de messagerie beaucoup plus sûrs.

Dresser un inventaire avant de modifier le DNS de messagerie

De nombreuses organisations ont plus d'un expéditeur légitime : un fournisseur de boîtes aux lettres, une plateforme de marketing, un système de tickets, une application de comptabilité et un service de supervision peuvent tous envoyer sous le même domaine. Créez un inventaire indiquant, pour chaque prestataire, le domaine d'envoi, l'exigence SPF, le sélecteur DKIM et le responsable. Confirmez si chaque prestataire utilise le domaine From visible ou un sous-domaine délégué. Cet inventaire est le fondement d'une politique DMARC sûre, car les rapports révèlent souvent des systèmes dont l'administrateur de messagerie principal ignorait l'existence. Validez les prestataires avec leur documentation actuelle et un vrai message de test, puis ne supprimez les expéditeurs obsolètes qu'une fois que l'équipe a confirmé que leur trafic n'est plus nécessaire.