Comment authentifier un domaine d'envoi : guide de configuration SPF, DKIM et DMARC

Pour authentifier un domaine d'envoi, vous publiez trois enregistrements DNS qui prouvent à Gmail, Yahoo, Outlook et à tous les autres serveurs destinataires que vos messages sont bien les vôtres : SPF liste les serveurs autorisés à envoyer pour vous, DKIM ajoute une signature cryptographique à chaque message, et DMARC indique aux destinataires quoi faire lorsque ces contrôles échouent. En une seule séance, cela prend généralement environ 30 minutes, et c'est la mesure la plus efficace que vous puissiez prendre pour la réception en boîte de réception.

La version courte

1. Vérifiez l'existant. Consultez vos enregistrements SPF, DKIM et DMARC actuels afin de les modifier plutôt que de les dupliquer.
2. Publiez un seul enregistrement SPF. Un unique enregistrement TXT à la racine de votre domaine, qui inclut tous les services envoyant en votre nom.
3. Publiez DKIM. L'enregistrement de sélecteur fourni par votre tableau de bord, afin que chaque message soit signé.
4. Publiez DMARC avec p=none. Démarrez en mode surveillance avec une adresse de réception des rapports.
5. Vérifiez. Exécutez dig, puis envoyez un message de test et lisez les en-têtes.
6. Appliquez. Examinez les rapports, puis passez à p=quarantine et à p=reject.

Que signifie authentifier un domaine d'envoi ?

L'e-mail a été conçu sans moyen de vérifier l'expéditeur d'un message. N'importe qui peut saisir votre adresse dans le champ From, ce qui explique pourquoi le phishing et l'usurpation d'identité sont si répandus. L'authentification comble cette lacune grâce à trois contrôles complémentaires, chacun répondant à une question différente pour le serveur destinataire :

• Ce serveur est-il autorisé à envoyer pour ce domaine ? C'est SPF (Sender Policy Framework, défini dans la RFC 7208).
• Le message provient-il réellement de ce domaine et n'a-t-il pas été altéré ? C'est DKIM (DomainKeys Identified Mail, RFC 6376).
• Que doit-il se passer si l'un des contrôles échoue, et qui reçoit le rapport ? C'est DMARC (RFC 7489).

Les destinataires combinent les trois en un signal de confiance. Les messages qui s'authentifient et s'alignent avec votre domaine From construisent, avec le temps, une réputation de domaine stable. Les autres sont filtrés, retardés ou rejetés, et à plus grande échelle ils sont désormais purement et simplement refusés par les principaux fournisseurs de messagerie.

SPF, DKIM et DMARC en un coup d'œil

	SPF	DKIM	DMARC
Ce qu'il prouve	Le serveur d'envoi est autorisé pour le domaine	Le message a été signé par le domaine et n'a pas été modifié en transit	Les contrôles s'alignent avec le domaine From visible, et il définit la politique
Où il se trouve dans le DNS	Enregistrement TXT à la racine du domaine	TXT ou CNAME sur selector._domainkey	Enregistrement TXT sur _dmarc
Ce qui est contrôlé	Domaine du Return-Path (expéditeur d'enveloppe) et IP d'envoi	Signature dans l'en-tête DKIM-Signature	Domaine de l'en-tête From comparé aux résultats SPF et DKIM
Résiste au transfert ?	Généralement non	Oui, si le contenu n'est pas modifié	Réussit si DKIM réussit et s'aligne
Cause principale d'échec	Expéditeur manquant ou plus de 10 requêtes	Mauvais sélecteur ou clé mal copiée	Défaut d'alignement

Avant de commencer : ce dont vous avez besoin

• Un accès pour modifier le DNS du domaine (registraire, Cloudflare, cPanel ou votre hébergeur DNS).
• La liste de tous les services qui envoient des e-mails avec votre domaine : votre compte MigoSMTP, votre messagerie d'entreprise (Google Workspace ou Microsoft 365), votre CRM, vos outils de facturation et de support.
• Une boîte aux lettres pour recevoir les rapports DMARC, de préférence une adresse dédiée comme dmarc-reports sur votre domaine.
• Les valeurs d'include SPF et d'enregistrement DKIM de la page Domaines de votre tableau de bord MigoSMTP.

Étape 1 : vérifier vos enregistrements actuels

Les enregistrements en double sont la cause la plus fréquente d'échec de l'authentification. Consultez ce qui est déjà publié avant d'ajouter quoi que ce soit. Sous macOS ou Linux, utilisez dig ; sous Windows, utilisez nslookup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

Cherchez tout enregistrement TXT qui commence par v=spf1 (SPF) et tout enregistrement sur _dmarc qui commence par v=DMARC1. Si l'un des deux existe, vous le modifierez au lieu d'en ajouter un autre.

Étape 2 : ajouter votre enregistrement SPF

SPF est un unique enregistrement TXT à la racine de votre domaine. Il liste les services autorisés à envoyer des e-mails en utilisant votre domaine comme expéditeur d'enveloppe (le Return-Path).

Syntaxe de l'enregistrement SPF

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

Élément	Signification
v=spf1	Obligatoire. Indique que l'enregistrement est de type SPF version 1.
include:domain	Autorise tout ce que l'enregistrement SPF de ce domaine autorise. Utilisez la valeur de votre tableau de bord MigoSMTP.
ip4:203.0.113.10	Autorise une adresse IPv4 ou une plage précise. IPv6 utilise ip6:.
a, mx	Autorise les IP des enregistrements A ou MX de votre domaine.
~all	Soft fail : tout ce qui n'est pas listé est suspect mais pas rejeté d'emblée. Courant tant que vous ajoutez encore des expéditeurs.
-all	Hard fail : tout ce qui n'est pas listé n'est pas autorisé. À utiliser lorsque vous êtes certain que tous les expéditeurs sont listés.

La limite de 10 requêtes

L'évaluation SPF ne peut déclencher que 10 requêtes DNS au maximum. Chaque include, a, mx, exists et redirect compte, y compris les requêtes effectuées dans les enregistrements que vous incluez. Si vous dépassez la limite, les destinataires renvoient une erreur permanente et SPF échoue pour chaque message. Gardez ce nombre bas en supprimant les services que vous n'utilisez plus, en remplaçant a et mx par des plages ip4 explicites lorsqu'elles sont stables, et en déplaçant les outils rarement utilisés vers leur propre sous-domaine.

Erreurs SPF courantes

• Deux enregistrements SPF sous le même nom (fusionnez-les en un seul).
• L'utilisation de +all, qui autorise tout Internet.
• La saisie de la valeur include avec des espaces superflus ou sans les deux-points.
• L'oubli d'un expéditeur comme un système de facturation ou un centre d'assistance, dont les e-mails échouent alors à SPF.
• La publication de SPF sur le mauvais nom, par exemple l'hôte www au lieu de la racine du domaine.

Étape 3 : publier votre enregistrement DKIM

DKIM ajoute une signature numérique à chaque message. Votre plateforme d'envoi signe les e-mails sortants avec une clé privée qu'elle garde secrète, et vous publiez la clé publique correspondante dans le DNS afin que les destinataires puissent vérifier la signature.

Sélecteurs et emplacement de l'enregistrement

Chaque clé est placée sous un nom appelé sélecteur, sous la forme selector._domainkey.yourdomain.com. Le sélecteur permet de publier plusieurs clés en même temps et de les renouveler sans interruption. Votre tableau de bord MigoSMTP affiche le nom et la valeur exacts pour votre domaine.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

TXT ou CNAME ?

Certaines plateformes vous demandent de publier la clé publique directement sous forme d'enregistrement TXT. D'autres vous fournissent un CNAME qui pointe vers un enregistrement qu'elles hébergent, ce qui leur permet de renouveler les clés pour vous. Publiez exactement le type indiqué par votre tableau de bord. Ne convertissez pas l'un en l'autre.

Longueur de clé et mise en forme

• Utilisez des clés RSA de 2048 bits lorsque c'est possible. Les clés de 1024 bits sont encore acceptées par de nombreux destinataires mais sont considérées comme faibles.
• Une clé de 2048 bits dépasse 255 caractères, et une chaîne DNS unique ne peut pas dépasser 255 caractères. Votre hébergeur DNS doit découper la valeur en plusieurs chaînes entre guillemets au sein d'un même enregistrement TXT. La plupart des tableaux de bord le font automatiquement ; si le vôtre ne le fait pas, découpez-la manuellement.
• Copiez la valeur sans sauts de ligne ajoutés ni guillemets typographiques, et ne l'entourez pas de guillemets supplémentaires, sauf si votre hébergeur DNS l'exige.

Renouvellement

Renouvelez les clés DKIM tous les six à douze mois, ou immédiatement si une clé privée a pu être exposée. Publiez d'abord le nouveau sélecteur, basculez la signature vers celui-ci, et ne supprimez l'ancien sélecteur qu'une fois que les messages signés avec lui ont fini d'arriver.

Étape 4 : publier votre enregistrement DMARC

DMARC relie SPF et DKIM au domaine que vos destinataires voient réellement dans la ligne From, et indique aux destinataires quoi faire des e-mails qui échouent. C'est un enregistrement TXT sur _dmarc.yourdomain.com. Démarrez en mode surveillance afin de voir qui envoie en votre nom avant d'appliquer quoi que ce soit.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Balise	Rôle	Valeur typique
v	Version. Doit être en premier.	DMARC1
p	Politique pour les e-mails qui échouent : none (surveillance), quarantine (dossier spam) ou reject (refus).	none au début
rua	Destination des rapports agrégés quotidiens.	mailto:dmarc-reports@example.com
ruf	Destination des échantillons d'échec. Peu de destinataires en envoient.	Facultatif
pct	Pourcentage des e-mails en échec auquel la politique s'applique, utilisé lors d'un déploiement progressif.	25, 50, 100
sp	Politique pour les sous-domaines si elle diffère de celle du domaine parent.	Identique à p sauf besoin particulier
adkim, aspf	Mode d'alignement : r (relaxed, souple) ou s (strict).	r (souple) est la valeur par défaut
fo	Moment où générer les rapports d'échec.	1

Ce que signifie vraiment l'« alignement »

DMARC réussit lorsque SPF ou DKIM réussit et que le domaine concerné s'aligne avec le domaine From. Avec l'alignement souple, un sous-domaine du domaine From est considéré comme aligné : un Return-Path bounce.example.com s'aligne donc avec un From news@example.com. Avec l'alignement strict, les domaines doivent correspondre exactement. La cause la plus courante du cas « SPF réussit mais DMARC échoue » est un domaine de Return-Path ou de DKIM qui appartient à votre plateforme d'envoi et non à vous. Activez un Return-Path personnalisé et votre propre domaine de signature DKIM pour y remédier.

Étape 5 : vérifier que tout fonctionne

Vérifier les enregistrements dans le DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Chaque commande doit renvoyer l'enregistrement que vous avez publié. Si rien ne revient, l'enregistrement se trouve sur le mauvais nom ou ne s'est pas encore propagé. Attendez l'expiration du TTL et testez à nouveau.

Envoyer un message de test et lire les en-têtes

1. Envoyez un message depuis votre domaine authentifié vers une adresse Gmail que vous contrôlez.
2. Ouvrez le message, choisissez le menu à trois points et sélectionnez Afficher l'original.
3. En haut, vous verrez SPF, DKIM et DMARC avec un résultat PASS ou FAIL pour chacun.
4. Vérifiez que le domaine affiché à côté de chaque PASS correspond à votre domaine From.

Déployer DMARC en toute sécurité : de p=none à p=reject

L'objectif est p=reject, car c'est la seule politique qui empêche des tiers d'usurper votre domaine. Mais y passer à l'aveugle peut bloquer des e-mails légitimes provenant d'outils que vous aviez oubliés. Avancez par étapes et laissez les rapports vous guider.

Étape	Politique	Durée	Que faire
1. Surveillance	p=none	2 à 4 semaines	Lisez les rapports agrégés. Listez chaque source qui envoie en votre nom et corrigez ou autorisez chaque source légitime.
2. Quarantaine partielle	p=quarantine; pct=25	1 à 2 semaines	Les e-mails en échec pour 25 pour cent du trafic vont en spam. Surveillez les plaintes concernant des e-mails manquants.
3. Quarantaine complète	p=quarantine	2 semaines	Passez pct à 100 lorsque les rapports montrent que seules des sources non autorisées échouent.
4. Rejet	p=reject	En continu	Passez à reject, en augmentant éventuellement pct par paliers. Continuez à lire les rapports chaque mois.

Les rapports agrégés DMARC arrivent sous forme de fichiers XML compressés et ne sont pas faits pour être lus à la main. Utilisez un analyseur de rapports DMARC gratuit ou payant pour les transformer en un tableau des sources d'envoi, des volumes et des résultats de réussite ou d'échec.

Exigences de Gmail, Yahoo et Microsoft pour les expéditeurs en masse

Depuis février 2024, Gmail et Yahoo appliquent des règles d'authentification et de désabonnement à tous ceux qui envoient en volume, et Microsoft applique des exigences comparables aux boîtes grand public Outlook.com depuis mai 2025. En résumé :

Exigence	Tous les expéditeurs	Expéditeurs en masse (environ 5 000 messages par jour et plus vers le fournisseur)
SPF ou DKIM	Obligatoire	Les deux sont obligatoires
Enregistrement DMARC	Recommandé	Obligatoire, au moins p=none, aligné avec From
Désabonnement en un clic	Non exigé pour les e-mails transactionnels	Obligatoire pour les e-mails marketing et les e-mails auxquels on s'est abonné (en-têtes RFC 8058) ; traiter les demandes sous deux jours
Taux de plaintes pour spam	Le maintenir bas	Rester sous 0,10 pour cent et ne jamais atteindre 0,30 pour cent (Google Postmaster Tools)
DNS direct et inverse valides, TLS	Obligatoire	Obligatoire

Les fournisseurs peuvent modifier leurs seuils ; consultez donc leurs directives actuelles pour les expéditeurs. Les liens figurent dans la liste de références à la fin de ce guide.

Séparer les e-mails marketing et transactionnels avec des sous-domaines

La réputation est suivie par domaine d'envoi et par IP. Si une campagne promotionnelle génère des plaintes, vous ne voulez pas que vos e-mails de réinitialisation de mot de passe atterrissent en spam. Le schéma habituel consiste à utiliser un sous-domaine par flux :

Flux	Exemple d'adresse From	Pourquoi les séparer
Transactionnel	noreply@mail.example.com	Doit toujours arriver rapidement. Un faible volume et un fort engagement maintiennent une bonne réputation.
Marketing	hello@news.example.com	Volume plus élevé et plus de plaintes. Les problèmes restent contenus.
Messagerie d'entreprise	name@example.com	Les boîtes aux lettres de vos collaborateurs restent à l'abri des risques liés aux envois en masse.

Chaque sous-domaine a besoin de ses propres enregistrements SPF et DKIM. Un enregistrement DMARC sur le domaine parent protège les sous-domaines par défaut ; ajoutez une balise sp= ou un enregistrement distinct sur le sous-domaine si vous avez besoin d'une politique différente.

Erreurs d'authentification courantes et comment les corriger

Symptôme	Cause probable	Solution
SPF permerror ou « too many DNS lookups »	Plus de 10 requêtes, ou une erreur de syntaxe	Supprimez les include inutilisés, aplatissez les plages stables en ip4, déplacez les expéditeurs rares vers un sous-domaine.
Multiple SPF records found	Deux enregistrements TXT commencent par v=spf1	Fusionnez-les en un seul enregistrement.
DKIM: no key for signature	Nom de sélecteur incorrect ou enregistrement non publié	Vérifiez le sélecteur dans l'en-tête DKIM-Signature et comparez-le au nom dans votre DNS.
DKIM: body hash did not verify	Le message a été modifié après la signature (pieds de page, réécriture des liens par un autre système)	Désactivez l'étape de modification ou placez-la avant la signature.
Échec DMARC avec SPF réussi	Le domaine du Return-Path ne s'aligne pas avec From	Utilisez un Return-Path personnalisé sur votre propre domaine.
Échec DMARC avec DKIM réussi	Le domaine d= de DKIM ne s'aligne pas avec From	Signez avec votre propre domaine, et non avec celui de la plateforme par défaut.
Enregistrement introuvable	Mauvais nom d'hôte, point final en trop ou domaine ajouté deux fois par votre interface DNS	De nombreuses interfaces ajoutent automatiquement le domaine. Saisissez uniquement la partie qui le précède, par exemple selector1._domainkey.
Enregistrements non mis à jour	Ancien enregistrement en cache	Attendez l'expiration du TTL. Réduisez le TTL avant les modifications planifiées.

Liste de contrôle de l'authentification

• Un seul enregistrement SPF à la racine du domaine, sous 10 requêtes, se terminant par ~all ou -all.
• Enregistrement de sélecteur DKIM publié, en 2048 bits si votre hébergeur DNS le permet.
• Enregistrement DMARC sur _dmarc avec p=none et une adresse rua fonctionnelle.
• Return-Path et domaine DKIM personnalisés, afin que les deux s'alignent avec votre domaine From.
• Le message de test affiche SPF, DKIM et DMARC en PASS.
• Rapports DMARC examinés chaque semaine pendant le déploiement.
• E-mails marketing et transactionnels séparés par sous-domaine.
• Rappel dans votre calendrier pour renouveler les clés DKIM.

Pour aller plus loin et sources

• RFC 7208 : Sender Policy Framework (SPF)
• RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489 : Domain-based Message Authentication, Reporting and Conformance (DMARC)
• RFC 8058 : Signaling One-Click Functionality for List Email Headers
• Google : consignes pour les expéditeurs d'e-mails
• Yahoo : bonnes pratiques pour les expéditeurs
• Guides associés : Guide de montée en charge des e-mails et Les codes de rebond SMTP expliqués.