Un e-mail qui n’arrive pas coûte davantage qu’un e-mail mal écrit. Depuis février 2024, Google et Yahoo imposent aux expéditeurs de volume une authentification complète et un enregistrement DMARC ; Microsoft a suivi en 2025 pour Outlook.com. L’authentification n’est plus une bonne pratique parmi d’autres : c’est la condition d’entrée. Voici ce que recouvrent SPF, DKIM et DMARC, et l’ordre dans lequel les mettre en place.
Trois mécanismes, trois questions différentes
| Mécanisme | Question à laquelle il répond | Où il vit |
|---|---|---|
| SPF | Ce serveur a-t-il le droit d’envoyer pour ce domaine ? | Enregistrement DNS TXT |
| DKIM | Le message a-t-il été altéré depuis son envoi ? | Signature dans l’en-tête + clé publique en DNS |
| DMARC | Que faire quand SPF ou DKIM échoue, et qui en est informé ? | Enregistrement DNS TXT |
La confusion la plus répandue consiste à croire que ces mécanismes se remplacent. Ils se complètent : DMARC ne fonctionne qu’adossé à SPF et DKIM, et son intérêt principal — les rapports — n’existe pas sans eux.
SPF : déclarer les serveurs autorisés
SPF est un enregistrement TXT à la racine du domaine qui énumère les serveurs habilités à envoyer en son nom. Un site auto-hébergé qui délègue ses envois à une plateforme d’e-mailing doit y inclure cette plateforme.
; enregistrement TXT sur exemple.fr
"v=spf1 include:spf.brevo.com include:_spf.ovh.net -all"Deux points décident du résultat :
- La terminaison.
-all(rejet strict) est le bon choix une fois la liste des expéditeurs vérifiée.~all(échec doux) est une étape de transition, pas une destination. - La limite de dix requêtes DNS. Chaque
include:déclenche une résolution ; au-delà de dix, la vérification renvoie une erreur permanente et SPF cesse de protéger. Les enregistrements accumulés au fil des outils sont la cause la plus fréquente de ce dépassement.
Un enregistrement SPF qui dépasse dix résolutions DNS ne protège plus rien : il échoue silencieusement, et personne ne s’en aperçoit avant une chute de délivrabilité.
DKIM : signer pour prouver l’intégrité
DKIM ajoute une signature cryptographique aux en-têtes du message. Le destinataire récupère la clé publique dans le DNS de l’expéditeur et vérifie que le contenu signé n’a pas été modifié en route.
; clé publique, sur un sélecteur dédié
mail._domainkey.exemple.fr. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."En pratique, la clé est générée par la plateforme d’envoi, qui fournit l’enregistrement à publier. Le point de vigilance porte sur le sélecteur : chaque service utilise le sien, ce qui permet de faire cohabiter plusieurs expéditeurs sur un même domaine sans conflit. Une rotation de clé côté prestataire impose de republier l’enregistrement — un oubli fréquent lors des changements de plateforme.
DMARC : la politique et les rapports
DMARC indique aux serveurs destinataires quoi faire lorsque l’authentification échoue, et où envoyer les rapports. C’est aussi lui qui impose l’alignement : le domaine visible dans le champ From: doit correspondre à celui validé par SPF ou DKIM. Un message parfaitement signé pour un domaine tiers mais affichant votre nom échoue à DMARC — c’est précisément le mécanisme qui bloque l’usurpation.
; démarrage en observation
_dmarc.exemple.fr. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
; cible après analyse des rapports
_dmarc.exemple.fr. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s"La progression recommandée
p=none— aucun effet sur la remise, mais les rapports commencent à arriver. Compter deux à quatre semaines pour recenser tous les expéditeurs légitimes : outil de facturation, CRM, formulaire du site, plateforme d’e-mailing.p=quarantine— les messages non authentifiés partent en indésirables. À activer une fois les rapports propres, éventuellement sur un pourcentage partiel viapct=.p=reject— les messages non authentifiés sont refusés. C’est la cible, et c’est ce que les grands fournisseurs attendent des expéditeurs de volume.
p=reject sur un domaine qui envoie depuis plusieurs outils revient à couper la remise de ceux qu’on avait oubliés. Les rapports agrégés existent précisément pour éviter cela.Ce que l’authentification ne règle pas
SPF, DKIM et DMARC répondent à la question « ce message vient-il bien de ce domaine ». Ils ne disent rien de sa qualité. Un domaine parfaitement authentifié qui envoie du contenu non sollicité finit en indésirables comme les autres : réputation d’adresse IP, taux de plainte, taux de désinscription et engagement pèsent ensuite. L’authentification ouvre la porte ; elle ne garantit pas l’accueil.
Deux compléments méritent d’être posés dans la foulée : BIMI, qui affiche le logo de l’expéditeur dans les clients compatibles et exige p=quarantine au minimum, et un lien de désinscription en un clic conforme au RFC 8058, désormais exigé des expéditeurs de volume.
Vérifier avant de conclure
| Contrôle | Méthode |
|---|---|
| Enregistrements publiés | dig +short TXT exemple.fr et dig +short TXT _dmarc.exemple.fr |
| Nombre de résolutions SPF | Un validateur SPF en ligne ; au-delà de 10, réduire les include: |
| Alignement réel | Envoi test vers une adresse Gmail, puis « Afficher l’original » : les trois lignes doivent indiquer PASS |
| Couverture des expéditeurs | Lecture des rapports agrégés DMARC pendant deux à quatre semaines |
Ce qu’il faut retenir
L’ordre de mise en place ne varie pas : SPF d’abord, DKIM ensuite, DMARC en observation, puis durcissement progressif de la politique. Chaque étape se vérifie avant la suivante. Le raccourci — publier les trois enregistrements le même jour en p=reject — est la façon la plus rapide de couper des envois légitimes sans savoir lesquels.
Sur les domaines que j’administre, le passage en p=reject a systématiquement révélé un expéditeur oublié : un outil de facturation, une notification de sauvegarde, un vieux formulaire. Les rapports DMARC en p=none ne servent pas à cocher une case — ils servent à découvrir ce qui envoie en votre nom sans que vous le sachiez. — Simon Janvier
Pour aller plus loin
Les exigences des fournisseurs sont documentées côté Google Workspace. La spécification DMARC fait l’objet du RFC 7489.
