Accueil › Guides

Configurer SPF, DKIM et DMARC : enregistrements, pièges et contrôles

Publié le 2026-11-03 ／ Mis à jour le 2026-11-03 ／ Par Yuki Nakazawa

Une configuration SPF, DKIM et DMARC n'est plus facultative si vous envoyez des e-mails depuis votre propre domaine. Procédez dans cet ordre : publiez un enregistrement SPF unique, activez la signature DKIM avec une clé de 2048 bits, puis publiez un enregistrement DMARC qui démarre à p=none avec les rapports activés. Au passage, vérifiez que l'adresse IP qui envoie vos messages dispose d'un DNS inverse (PTR) correspondant.

Ce guide s'applique que vous envoyiez depuis un hébergement mutualisé, votre propre VPS, Google Workspace, Microsoft 365 ou un service d'e-mailing. Vous y trouverez des enregistrements à adapter, les erreurs qui cassent le plus souvent l'authentification, et la façon de vérifier que tout fonctionne à partir de l'en-tête d'un vrai message.

Les informations ci-dessous ont été vérifiées dans les RFC et sur les pages officielles de Google, Yahoo et Microsoft en date de novembre 2026. Les exigences des fournisseurs de messagerie évoluent : leurs pages font foi.

Ce que prouvent SPF, DKIM et DMARC, et dans quel ordre les configurer

SPF (Sender Policy Framework) permet à un domaine d'indiquer, dans le DNS, quels serveurs ont le droit d'envoyer ses messages. Le serveur destinataire regarde l'expéditeur d'enveloppe (l'adresse SMTP MAIL FROM, qui apparaît ensuite comme Return-Path), récupère l'enregistrement SPF de ce domaine et vérifie si l'adresse IP qui se connecte figure dans la liste. À lui seul, SPF ne dit rien de l'adresse From que voit le lecteur.

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque message. Le système d'envoi signe avec une clé privée, et les destinataires vérifient la signature avec une clé publique publiée dans le DNS. Une signature valide prouve que le domaine signataire (la valeur d=) a pris la responsabilité du message et que les en-têtes signés et le corps n'ont pas été modifiés en chemin.

DMARC (Domain-based Message Authentication, Reporting and Conformance) rattache les deux au domaine From visible. Un message ne passe DMARC que si SPF ou DKIM réussit et que le domaine authentifié est aligné sur le domaine From. L'enregistrement DMARC indique aussi aux destinataires ce que vous souhaitez faire des échecs (rien, mise en quarantaine ou rejet) et où envoyer les rapports agrégés, ce qui vous permet de découvrir les sources d'envoi oubliées.

Ordre de configuration

1. Recensez tous les systèmes qui envoient des messages au nom de votre domaine : votre propre serveur, Google Workspace ou Microsoft 365, les services de newsletters et d'e-mails transactionnels, les formulaires web, les outils de facturation et de support.
2. Publiez un enregistrement SPF unique qui les couvre tous.
3. Activez DKIM sur chaque système d'envoi et publiez sa clé publique.
4. Publiez DMARC avec p=none et une adresse de rapport rua. Google suggère d'attendre 48 heures après la configuration de SPF et DKIM avant d'ajouter DMARC.
5. Lisez les rapports, corrigez les sources en échec, puis passez à p=quarantine et enfin à p=reject.

Configurer SPF : un seul enregistrement, dix requêtes

SPF est un enregistrement TXT placé sur le domaine lui-même. Voici un domaine qui envoie depuis son propre serveur en IPv4 et IPv6 et qui utilise aussi Google Workspace :

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

Dans la plupart des interfaces de gestion DNS, vous laissez le champ hôte vide (ou saisissez @), choisissez TXT et collez la valeur à partir de v=spf1. Éléments courants :

Les pièges de SPF

• Un seul enregistrement SPF par nom. La RFC 7208 interdit plusieurs enregistrements SPF pour un même domaine ; les destinataires renvoient permerror et SPF échoue pour tous les messages. Lorsque vous ajoutez un service, modifiez l'enregistrement existant pour y ajouter son include: au lieu de créer un second enregistrement v=spf1.
• La limite de 10 requêtes. Les mécanismes include, a, mx, ptr et exists, ainsi que le modificateur redirect, déclenchent chacun des requêtes DNS, et leur total sur l'ensemble de l'évaluation, y compris les requêtes des include imbriqués, ne doit pas dépasser 10. Au-delà, le résultat est permerror. ip4:, ip6: et all ne coûtent rien. La RFC 7208 indique aussi que les destinataires devraient s'arrêter après deux requêtes sans réponse : supprimez donc les include des services que vous n'utilisez plus.
• ~all ou -all. -all signifie que les sources non listées ne sont pas autorisées (fail) ; ~all signifie qu'elles ne sont probablement pas autorisées (softfail). Google recommande ~all pour les domaines Workspace ; Microsoft recommande -all pour les domaines Microsoft 365 qui utilisent aussi DKIM et DMARC. Si vous n'êtes pas encore certain d'avoir trouvé tous les expéditeurs, commencez par ~all et laissez DMARC se charger de l'application.
• Les sous-domaines ont besoin de leur propre enregistrement. L'enregistrement SPF de example.com ne couvre pas news.example.com. Placer un service d'e-mailing sur son propre sous-domaine lui donne en outre un budget distinct de 10 requêtes et sépare sa réputation de celle des messages de vos collaborateurs.
• Erreurs de syntaxe. Microsoft cite les plus courantes : include= au lieu de include:, une espace après les deux-points, et un point final après le domaine inclus.

Pour les domaines qui n'envoient jamais de messages, publiez v=spf1 -all afin de les rendre plus difficiles à usurper.

Configurer DKIM : clés 2048 bits et sélecteurs

DKIM comporte deux volets : le système d'envoi signe avec une clé privée, et le DNS publie la clé publique correspondante. Avec Google Workspace, Microsoft 365, la plupart des panneaux d'hébergement et la plupart des services d'e-mailing, vous générez la clé dans la console d'administration et copiez la valeur DNS affichée.

Longueur de clé et sélecteurs

Utilisez une clé RSA de 2048 bits. La RFC 8301 fixe le minimum à 1024 bits et indique que les signataires devraient utiliser au moins 2048 bits ; elle interdit aussi rsa-sha1. Les recommandations de Google vont dans le même sens : choisissez 2048 bits si votre hébergeur DNS le permet, et ne vous rabattez sur 1024 que dans le cas contraire.

Le sélecteur est une étiquette qui identifie la clé ayant signé un message : un domaine peut ainsi avoir plusieurs clés en même temps, une par service d'envoi ou une par période de rotation. La clé publique se trouve sur selector._domainkey.yourdomain. Google Workspace utilise google comme sélecteur par défaut. Microsoft 365 utilise deux enregistrements CNAME, selector1._domainkey et selector2._domainkey, qui pointent vers des clés hébergées par Microsoft ; reprenez les cibles exactes depuis le portail Defender ou Get-DkimSigningConfig, car leur format varie selon le locataire (tenant).

Publier une clé publique longue

Une clé publique de 2048 bits dépasse les 255 caractères autorisés dans une seule chaîne de caractères DNS : dans un fichier de zone, elle s'écrit donc sous forme de plusieurs chaînes entre guillemets dans un même enregistrement TXT :

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Remplacez les parties entre parenthèses par votre clé réelle. Les destinataires concatènent les chaînes sans espace : vous pouvez donc couper n'importe où dans la clé. De nombreux panneaux découpent automatiquement les valeurs longues : collez d'abord la valeur entière et ne la découpez vous-même que si le panneau la refuse. Veillez à ne rien perdre lors du copier-coller ; un p= vide signifie que la clé a été révoquée.

Sur votre propre VPS sous Postfix ou un MTA similaire, un milter de signature comme OpenDKIM peut créer la paire de clés, par exemple opendkim-genkey -b 2048 -s selector1 -d example.com. Publiez le contenu du fichier de clé publique généré comme indiqué ci-dessus.

Vérifier que les messages sont bien signés

Ouvrez un message que vous avez envoyé et cherchez un en-tête DKIM-Signature:. Sa balise d= doit correspondre à votre domaine et s= au sélecteur que vous avez publié. De nombreux services d'e-mailing signent par défaut avec leur propre domaine ; DKIM réussit alors, mais n'est pas aligné sur votre domaine From et n'aide donc pas DMARC. Activez l'authentification de domaine personnalisé du service pour que d= devienne votre domaine.

Configurer DMARC : commencer à p=none, puis appliquer

DMARC est un enregistrement TXT placé sur _dmarc sous votre domaine. Commencez en mode surveillance, qui demande aux destinataires de ne rien changer à leur traitement de vos messages, et demandez des rapports agrégés :

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

Les rapports agrégés sont des synthèses lisibles par machine indiquant quelles adresses IP ont envoyé des messages au nom de votre domaine et si ces messages ont réussi les contrôles ; Google suggère une boîte ou un groupe dédié pour les recevoir. Une fois que les rapports montrent que toutes les sources légitimes réussissent avec alignement, durcissez la politique en modifiant le même enregistrement plutôt qu'en en ajoutant un second :

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

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

L'alignement, en termes simples

Pour passer DMARC, au moins l'un des deux, SPF ou DKIM, doit réussir pour un domaine qui correspond au domaine From. En mode souple (relaxed), les domaines organisationnels doivent correspondre : une signature DKIM avec d=example.com est donc alignée avec un message de alerts@news.example.com. Le mode strict exige une correspondance exacte. Les services d'e-mailing utilisent souvent leur propre domaine dans le Return-Path : SPF ne sera alors pas aligné même s'il réussit, et un DKIM aligné est le moyen pratique de faire passer ces messages DMARC.

Si vous souhaitez une politique différente pour les sous-domaines, ajoutez sp=. Par exemple, p=reject; sp=quarantine rejette les messages en échec provenant du domaine principal, tout en se contentant de mettre en quarantaine les échecs des sous-domaines.

À propos de la norme mise à jour

En mai 2026, DMARC a été republié sous la forme de la RFC 9989, qui rend obsolète la RFC 7489. Les enregistrements existants continuent de fonctionner et commencent toujours par v=DMARC1. La nouvelle norme supprime la balise pct, rarement appliquée avec précision sauf à 0 ou 100, et ajoute des balises comme t=y (mode test) et np (politique pour les sous-domaines inexistants). Certaines pages d'aide de fournisseurs mentionnent encore pct : la façon la moins ambiguë de déployer l'application est donc de passer progressivement par les valeurs de p=.

DNS inverse (PTR) pour votre IP d'envoi

Le DNS inverse associe une adresse IP à un nom d'hôte. Google exige de tous les expéditeurs vers des comptes Gmail personnels un enregistrement PTR dont le nom d'hôte renvoie vers la même IP d'envoi, et Yahoo exige un DNS direct et inverse valides pour les IP d'envoi et recommande un enregistrement PTR explicite, non générique.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

L'enregistrement PTR ne se trouve pas dans la zone de votre domaine. C'est le propriétaire de l'adresse IP qui le contrôle : sur un VPS, vous le définissez dans le panneau de configuration du fournisseur (souvent appelé reverse DNS ou rDNS), puis vous créez un enregistrement A correspondant (AAAA pour l'IPv6) dans votre propre DNS. Si vous envoyez en IPv6, l'adresse IPv6 doit être traitée de la même façon. Avec Google Workspace, Microsoft 365, les services d'e-mailing et la plupart des hébergements mutualisés, le fournisseur gère pour vous les IP d'envoi et leur DNS inverse.

Comment vérifier votre configuration

Lire Authentication-Results

Envoyez un message de test vers une boîte externe et affichez les en-têtes complets. Dans Gmail, ouvrez le message et choisissez Afficher l'original. L'aide de Google sur DKIM précise qu'il faut envoyer le message à un autre utilisateur plutôt qu'à vous-même. Recherchez un en-tête comme celui-ci :

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

La présentation exacte varie selon le destinataire. L'essentiel est d'avoir spf=pass, dkim=pass et dmarc=pass, avec votre propre domaine dans header.i ou header.d et dans header.from. Si SPF réussit pour le domaine d'un service mais que DKIM affiche un autre domaine, DMARC échouera : corrigez d'abord l'alignement DKIM.

Interroger directement le DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Sous Windows, nslookup -type=TXT _dmarc.example.com fait la même chose. Les modifications DNS peuvent mettre du temps à se propager ; selon Google, SPF et DKIM peuvent chacun mettre jusqu'à 48 heures à devenir effectifs. Des outils en ligne gratuits peuvent aussi analyser vos enregistrements et compter les requêtes SPF à votre place.

Si l'authentification réussit mais que vos messages sont toujours rejetés ou arrivent en spam, vérifiez si votre IP d'envoi ou votre domaine figure sur une DNSBL avec notre outil de vérification de listes noires, et consultez e-mails non distribués à cause d'une liste noire pour la suite.

Exigences de Gmail, Yahoo et Outlook.com envers les expéditeurs

Les grands fournisseurs de messagerie imposent désormais l'authentification. En date de novembre 2026, leurs pages officielles indiquent ce qui suit.

• Gmail (en vigueur depuis le 1er février 2024) : toute personne qui envoie vers des comptes Gmail personnels doit disposer de SPF ou DKIM, d'un DNS direct et inverse concordants, d'une connexion TLS et d'un taux de spam inférieur à 0,3% dans Postmaster Tools. Les expéditeurs de plus de 5 000 messages par jour doivent en outre disposer à la fois de SPF et de DKIM, d'un enregistrement DMARC (p=none est accepté), d'un domaine From aligné sur SPF ou DKIM, et du désabonnement en un clic pour les messages marketing. Les clés DKIM doivent faire au moins 1024 bits, 2048 étant recommandé.
• Yahoo (application depuis février 2024) : tous les expéditeurs doivent disposer de SPF ou DKIM, d'un DNS direct et inverse valides et d'un taux de spam inférieur à 0,3%. Les expéditeurs en masse doivent disposer à la fois de SPF et de DKIM, d'une politique DMARC au moins égale à p=none qui réussit, d'un alignement du From (le mode souple suffit), d'un désabonnement en un clic fonctionnel et d'un DNS direct et inverse valides pour les IP d'envoi.
• Outlook.com (le service grand public derrière outlook.com, hotmail.com et live.com) : les domaines qui envoient plus de 5 000 e-mails par jour doivent réussir SPF et DKIM et publier un DMARC au moins égal à p=none, aligné sur SPF ou DKIM. Microsoft a indiqué qu'à partir du 5 mai 2025, les messages non conformes seraient rejetés avec l'erreur 550; 5.7.515.

Lisez le texte complet dans les consignes de Google pour les expéditeurs d'e-mails, les bonnes pratiques de Yahoo pour les expéditeurs et l'annonce de Microsoft concernant Outlook.com. Même si vous envoyez beaucoup moins de messages, configurer les trois dès maintenant vous évitera d'être pris au dépourvu si le seuil est abaissé plus tard. Pour un dépannage propre à Gmail, consultez Gmail ne distribue pas vos e-mails.

Erreurs fréquentes

• Un second enregistrement SPF. Ajouter un nouvel enregistrement v=spf1 pour chaque service invalide SPF pour tout le domaine. Regroupez tout dans un seul.
• Trop d'include. Les anciens services laissés dans SPF entament le budget de 10 requêtes. Supprimez ce que vous n'utilisez plus et déplacez les envois en masse vers un sous-domaine.
• Clé publiée, signature non activée. Dans Google Workspace, il faut encore cliquer sur Démarrer l'authentification une fois l'enregistrement DNS en ligne ; d'autres plateformes ont un interrupteur similaire.
• Le service signe avec son propre domaine. SPF et DKIM réussissent tous deux, DMARC échoue. Activez la signature avec un domaine personnalisé.
• Passer directement à p=reject. Un formulaire web ou un système de facturation oublié cesse d'être distribué du jour au lendemain. Commencez à p=none et lisez les rapports.
• Dégâts du copier-coller. Des guillemets en trop dans la valeur, une clé tronquée, ou un nom d'hôte qui devient _dmarc.example.com.example.com parce que le panneau ajoute le domaine à votre place. Un simple dig permet de repérer tous ces problèmes.

Questions fréquentes

Pages officielles consultées

Les informations de cet article ont été vérifiées sur les pages officielles ci-dessous à la date de publication. Les politiques et le fonctionnement peuvent changer sans préavis : consultez les pages officielles avant de vous fier à une information importante.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Guides associés

Tous les guides →