Arrêtez de deviner votre DNS : tour d’horizon de MX, SPF, DKIM et DMARC pour les développeurs

Pourquoi les enregistrements DNS liés aux emails comptent aujourd’hui

L’authentification des emails était autrefois facultative. En 2026, c’est un prérequis. Gmail et Outlook imposent tous deux SPF et DKIM aux expéditeurs en masse, et DMARC devient rapidement obligatoire pour tout domaine qui envoie des emails transactionnels. Si vos enregistrements DNS sont incorrects, vos emails n’arrivent pas — pas de rebond, pas d’avertissement, juste le silence.

Le problème, c’est que ces enregistrements sont documentés comme des RFC, pas comme des outils. La plupart des développeurs copient-collent des exemples depuis le guide de configuration de leur fournisseur d’email et espèrent que tout ira bien. Cela fonctionne jusqu’au moment où vous devez dépanner, ajouter un deuxième service d’envoi ou expliquer à un client pourquoi les emails de son formulaire de contact arrivent dans les spams.

Ce guide parcourt MX, SPF, DKIM et DMARC dans l’ordre où vous les rencontrerez réellement, avec assez de détails pour les configurer correctement et assez de contexte pour les déboguer lorsqu’ils cassent.

Enregistrements MX : où va l’email entrant

Les enregistrements MX indiquent à Internet quels serveurs de messagerie acceptent les emails pour votre domaine. Ce sont les plus simples des quatre, mais aussi les plus faciles à mal configurer.

Un enregistrement MX comporte deux parties : un numéro de priorité et un nom d’hôte. Les numéros de priorité les plus bas sont essayés en premier. Si vous utilisez Google Workspace, vos enregistrements MX peuvent ressembler à ceci :

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Les points finaux comptent : ils indiquent que le nom d’hôte est pleinement qualifié. La plupart des fournisseurs DNS les ajoutent automatiquement, mais pas tous.

Erreurs courantes : faire pointer les enregistrements MX vers un enregistrement A plutôt que vers un nom d’hôte, définir toutes les priorités sur le même nombre (ce qui annule l’intérêt d’avoir des serveurs de secours), ou oublier de supprimer d’anciens enregistrements MX lors d’une migration de fournisseur. Les enregistrements MX obsolètes ne restent pas là sans effet : ils peuvent provoquer des boucles de courrier ou répartir la livraison entre deux boîtes de réception.

Si vous exploitez votre propre formulaire de contact et souhaitez éviter le spam sans dépendre de services tiers, comprendre comment les formulaires deviennent des vecteurs de spam est un bon point de départ.

SPF : quels serveurs sont autorisés à envoyer en votre nom

SPF (Sender Policy Framework) est un enregistrement TXT qui liste les adresses IP et les domaines autorisés à envoyer des emails au nom de votre domaine. C’est le premier contrôle que la plupart des serveurs de messagerie effectuent lorsqu’ils reçoivent un message prétendant venir de vous.

Un enregistrement SPF de base ressemble à ceci :

v=spf1 include:_spf.google.com ~all

Décomposons-le :

• v=spf1 déclare la version de SPF
• include:_spf.google.com délègue à l’enregistrement SPF de Google
• ~all est un échec léger : rejeter le courrier provenant de sources non listées, mais sans être trop strict

Vous pouvez aussi utiliser ip4: ou ip6: pour autoriser explicitement des adresses précises, ou a et mx pour référencer les enregistrements A et MX de votre domaine. Le mécanisme all à la fin contrôle ce qui arrive au courrier provenant de sources que vous n’avez pas listées : -all est un échec strict (rejet), ~all est un échec léger (marquer comme suspect), ?all est neutre (aucun avis), et +all ouvre la porte à tout le monde (à ne pas utiliser).

SPF a deux angles morts. D’abord, il casse lorsque l’email est transféré, car le serveur de transfert ne figure pas dans votre enregistrement SPF. Ensuite, les enregistrements SPF ont une limite de dix requêtes DNS. Si vous incluez trop de services tiers, vous dépasserez cette limite et SPF cessera de fonctionner. La solution consiste à aplatir votre enregistrement SPF — remplacer les directives include: par les plages IP réelles — mais cela demande de la maintenance lorsque les fournisseurs changent leurs IP.

DKIM : preuve cryptographique de l’identité de l’expéditeur

DKIM (DomainKeys Identified Mail) ajoute une signature numérique à vos emails sortants. Le serveur destinataire vérifie la signature à l’aide d’une clé publique publiée dans votre DNS. Si la signature est valide et que le message n’a pas été altéré, DKIM réussit.

Contrairement à SPF, DKIM survit aux transferts, car la signature voyage avec le message. Il est aussi plus flexible : vous pouvez avoir plusieurs clés DKIM pour différents services d’envoi, chacune avec son propre sélecteur.

Un enregistrement DNS DKIM ressemble à ceci :

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Le sélecteur (default dans cet exemple) est arbitraire : votre fournisseur d’email le choisit. La valeur p= est la clé publique, généralement une longue chaîne encodée en base64. Votre fournisseur d’email génère la clé privée et l’utilise pour signer les messages sortants.

La configuration de DKIM est presque toujours gérée par votre fournisseur d’email. Votre travail consiste à copier l’enregistrement TXT qu’il vous fournit et à le coller dans votre DNS. La partie délicate est que certains fournisseurs DNS gèrent mal les longs enregistrements TXT : ils les tronquent ou exigent que vous divisiez la valeur en plusieurs chaînes entre guillemets.

Pour vérifier que DKIM fonctionne, envoyez un email de test à une adresse Gmail et vérifiez les en-têtes. Cherchez dkim=pass dans l’en-tête Authentication-Results.

DMARC : application de la politique et rapports

DMARC (Domain-based Message Authentication, Reporting and Conformance) relie SPF et DKIM et indique aux serveurs destinataires quoi faire lorsque l’authentification échoue. Il active aussi les rapports, afin que vous puissiez voir qui envoie des emails en tant que votre domaine — qu’il s’agisse d’envois légitimes ou usurpés.

Un enregistrement DMARC minimal ressemble à ceci :

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none signifie surveillance uniquement : ne pas rejeter ni mettre en quarantaine les messages en échec
• rua=mailto:[email protected] précise où envoyer les rapports agrégés

Une fois que vous êtes sûr que SPF et DKIM fonctionnent, vous pouvez renforcer la politique en p=quarantine (envoyer les échecs dans les spams) ou p=reject (les rejeter purement et simplement). Vous pouvez aussi définir une politique de sous-domaine avec sp= et préciser le pourcentage de messages auquel appliquer la politique avec pct=.

Les rapports DMARC sont des fichiers XML envoyés quotidiennement par les grands destinataires. Ils sont verbeux et difficiles à lire bruts, mais ils vous indiquent exactement quels messages ont réussi ou échoué à l’authentification, et pourquoi. Si vous voyez du courrier légitime rejeté, les rapports vous montreront quel contrôle SPF ou DKIM échoue.

Un piège : DMARC exige l’alignement. Pour SPF, le domaine dans l’en-tête Return-Path doit correspondre au domaine dans l’en-tête From (ou être un sous-domaine). Pour DKIM, le domaine d= dans la signature DKIM doit correspondre au domaine From. Si vous utilisez un service d’envoi tiers, celui-ci doit prendre en charge des chemins de retour personnalisés ou la signature DKIM avec votre domaine, pas le sien.

Comment auditer votre configuration actuelle

La plupart des problèmes DNS sont invisibles jusqu’à ce qu’ils causent une panne. Voici comment vérifier vos enregistrements avant que quelque chose casse :

1. Interrogez vos enregistrements MX : dig MX example.com doit retourner les noms d’hôtes et les priorités de vos serveurs de messagerie. Vérifiez qu’ils correspondent à la documentation de votre fournisseur d’email.

1. Vérifiez la syntaxe SPF : dig TXT example.com et cherchez l’enregistrement v=spf1. Passez-le dans un validateur SPF pour détecter les erreurs de syntaxe et les dépassements de limite de requêtes.

1. Vérifiez les clés DKIM : envoyez un email de test et inspectez l’en-tête DKIM-Signature. Extrayez le sélecteur et le domaine, puis interrogez dig TXT selector._domainkey.example.com pour confirmer que la clé publique existe.

1. Validez la politique DMARC : dig TXT _dmarc.example.com doit retourner votre enregistrement DMARC. Assurez-vous que rua= pointe vers une adresse que vous surveillez réellement.

1. Testez de bout en bout : utilisez un service comme mail-tester.com ou envoyez un message à une adresse Gmail et vérifiez les en-têtes complets. Cherchez spf=pass, dkim=pass et dmarc=pass dans l’en-tête Authentication-Results.

Si vous déboguez des emails qui n’arrivent pas, les en-têtes sont votre meilleur outil. La plupart des clients de messagerie permettent d’afficher les en-têtes bruts : dans Gmail, ouvrez le message, cliquez sur les trois points, puis sélectionnez « Afficher l’original ». L’en-tête Authentication-Results vous dira exactement quel contrôle a échoué et pourquoi.

Quand utiliser des politiques de sous-domaine

Si vous envoyez des emails depuis plusieurs sous-domaines — par exemple newsletter.example.com pour le marketing et app.example.com pour les emails transactionnels — vous pouvez définir des politiques DMARC par sous-domaine. Cela vous permet d’appliquer des politiques strictes sur les sous-domaines que vous contrôlez tout en conservant une politique plus souple sur votre domaine principal.

Le compromis, c’est la complexité. Chaque sous-domaine a besoin de ses propres enregistrements SPF, DKIM et DMARC, et vous devez suivre quels services d’envoi sont autorisés pour quels sous-domaines. Pour la plupart des petites équipes, un seul domaine bien configuré est plus simple et tout aussi sûr.

Que faire lorsque l’authentification casse

Le mode de défaillance le plus courant consiste à ajouter un nouveau service d’envoi sans mettre à jour le DNS. Si vous commencez à utiliser un nouveau fournisseur d’email transactionnel, vous devez ajouter son include SPF ou sa plage IP, configurer la signature DKIM avec votre domaine et vérifier l’alignement DMARC.

Le deuxième problème le plus courant est le transfert. Si des utilisateurs transfèrent votre email vers une autre adresse, SPF échouera parce que le serveur de transfert ne figure pas dans votre enregistrement SPF. DKIM survit généralement au transfert ; donc, tant que DKIM réussit et que votre politique DMARC autorise un alignement partiel, le message devrait quand même être livré. Si vous voyez du courrier transféré rejeté, vérifiez votre politique DMARC : p=reject avec un alignement strict cassera le transfert.

Le troisième problème est la propagation DNS. Les changements apportés aux enregistrements DNS peuvent prendre des heures à se propager, et différents serveurs de messagerie mettent les enregistrements en cache pendant des durées différentes. Si vous venez de mettre à jour un enregistrement et qu’il ne fonctionne pas, attendez quelques heures et testez à nouveau. Vous pouvez vérifier la propagation avec un outil comme whatsmydns.net.

Points clés

• Les enregistrements MX routent le courrier entrant ; SPF, DKIM et DMARC authentifient le courrier sortant. Ils résolvent des problèmes différents et vous avez besoin des quatre.
• SPF casse lors du transfert et a une limite de dix recherches. DKIM survit au transfert, mais exige une configuration par service. DMARC les relie et active les rapports.
• Commencez avec p=none dans DMARC, surveillez les rapports pendant quelques semaines, puis renforcez en p=quarantine ou p=reject lorsque vous êtes sûr que le courrier légitime passe.
• Les erreurs DNS sont silencieuses. Testez votre configuration avec de vrais emails et inspectez les en-têtes pour confirmer que SPF, DKIM et DMARC réussissent.
• Si l’authentification casse après l’ajout d’un nouveau service d’envoi, vérifiez les includes SPF, les sélecteurs DKIM et l’alignement DMARC. Les en-têtes vous diront quel contrôle a échoué.

FAQ

Q: Can I have multiple SPF records?

A: Non. Plusieurs enregistrements SPF feront en sorte qu’ils seront tous ignorés. Si vous devez autoriser plusieurs services, utilisez des directives include: dans un seul enregistrement SPF, ou listez directement les plages IP. Surveillez la limite de dix recherches.

Q: Do I need DMARC if I'm only sending a few emails a day?

A: Oui. DMARC n’est pas une question de volume : il s’agit de prouver que vous êtes bien qui vous prétendez être. Même les petits domaines bénéficient de DMARC, car il empêche l’usurpation et vous donne de la visibilité sur les problèmes de livraison. Commencez avec p=none et une adresse de rapport.

Q: What happens if DKIM and SPF both fail but the email looks legitimate?

A: Cela dépend de votre politique DMARC. Si p=none, le courrier est livré avec un avertissement. Si p=quarantine, il va dans les spams. Si p=reject, il est rejeté. C’est pourquoi vous devriez surveiller les rapports DMARC avant d’appliquer une politique stricte : vous pourriez avoir des expéditeurs légitimes dont vous ignoriez l’existence.

Q: Can I use the same DKIM key for multiple domains?

A: Techniquement oui, mais ne le faites pas. Chaque domaine devrait avoir sa propre paire de clés DKIM. Partager des clés rend la rotation plus difficile et augmente le rayon d’impact si une clé privée est compromise.

Q: How often should I rotate DKIM keys?

A: Il n’existe pas de règle universelle, mais une fois par an est raisonnable pour la plupart des domaines. Si vous soupçonnez qu’une clé a été compromise, effectuez une rotation immédiatement. Assurez-vous de publier la nouvelle clé publique dans le DNS avant de commencer à signer avec la nouvelle clé privée, et laissez l’ancienne clé dans le DNS pendant quelques jours après la rotation pour gérer les emails retardés.

<!-- tool-cta:start -->

💡 Essayez ceci : Inspectez la politique publiée de n’importe quel domaine avec DMARC Lookup pour voir comment les enregistrements MX, SPF et DMARC s’articulent en pratique.

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — La spécification SPF, y compris les règles de syntaxe et la limite de dix recherches.
• RFC 6376: DomainKeys Identified Mail (DKIM) — La spécification DKIM, couvrant la génération et la vérification des signatures.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — La spécification DMARC, y compris la syntaxe des politiques et le format des rapports agrégés.
• Google Workspace: Prevent spoofing and spam — Conseils pratiques sur la configuration de SPF, DKIM et DMARC pour les domaines Google Workspace.