Ce bon vieux protocole des Emails, le pilier de l'internet… et source de tant de frustrations quand vos messages n'arrivent jamais à bon port. Je ne compte plus les heures passées à me demander pourquoi mon serveur auto-hébergé, configuré avec amour, voyait ses emails finir dans les spams de Gmail ou, pire, être carrément rejetés par Outlook. La cause ? Une réputation d'expéditeur en berne et un manque de preuves que j'étais bien le propriétaire légitime de mes envois.
C'est là que le trio infernal entre en scène : SPF, DKIM et DMARC. Pendant longtemps, je les ai vus comme des acronymes barbares, des options obscures dans mes enregistrements DNS. Mais croyez-moi, les comprendre et bien les configurer, c'est la clé pour que vos emails soient enfin pris au sérieux. Et DMARC, c'est un peu le chef d'orchestre qui fait le lien entre tout ça, tout en vous donnant les outils pour surveiller ce qui se passe sous le capot. Prêts à ne plus jamais voir vos emails finir dans le dossier « Indésirables » ? C'est parti !
Les fondations : SPF, le gardien des expéditeurs
Commençons par le plus simple, ou du moins celui qui semble l'être : le Sender Policy Framework, ou SPF. Son rôle est de dire au monde entier quels serveurs sont autorisés à envoyer des emails en votre nom. Imaginez que vous ayez une liste de personnes autorisées à prendre votre courrier à la poste. SPF, c'est cette liste.
Comment ça marche ?
SPF est un enregistrement DNS de type TXT. Dedans, vous listez les adresses IP ou les noms de domaines de vos serveurs d'envoi. Quand un serveur reçoit un email de votre domaine, il regarde l'adresse de l'expéditeur de l'enveloppe (le fameux MAIL FROM), puis consulte votre enregistrement SPF. Si le serveur d'envoi n'est pas dans la liste, ça sent le poisson. Le RFC qui le définit, c'est le RFC 7208 (d'avril 2014).
Exemple de configuration SPF
Un enregistrement SPF ressemble à ceci :
votredomaine.com. IN TXT "v=spf1 mx a ip4:192.0.2.1 include:autreservicedemail.com -all"
v=spf1: Indique la version de SPF.mx: Autorise les serveurs listés dans vos enregistrements MX (ceux qui reçoivent vos emails, souvent les mêmes qui les envoient).a: Autorise les adresses IP des enregistrements A de votre domaine.ip4:192.0.2.1: Autorise une adresse IPv4 spécifique (utile pour votre serveur auto-hébergé).include:autreservicedemail.com: Si vous utilisez un service tiers pour envoyer des emails (transactionnels, newsletters), vous devez inclure leur politique SPF.-all: C'est la politique stricte. Tout email venant d'un serveur non listé DOIT être rejeté. C'est ce que je vise à terme.~all: Moins strict, indique un 'softfail'. L'email est marqué comme suspect mais souvent livré (placé en spam). C'est un bon point de départ.
Les pièges à éviter avec SPF
Le plus gros piège, c'est la limite des 10 requêtes DNS. Chaque include, a, mx ou autre mécanisme peut potentiellement générer une requête DNS. Si vous en avez plus de 10, votre SPF sera ignoré, ce qui est une catastrophe pour votre réputation ! Vérifiez-le régulièrement. Autre souci : le forwarding. Quand un email est transféré, l'expéditeur de l'enveloppe change souvent, et SPF échoue. Et enfin, SPF ne protège que l'adresse de l'enveloppe, pas l'adresse « From » que voit l'utilisateur. C'est là que DKIM et DMARC entrent en jeu.
DKIM, la signature numérique de vos emails
DKIM (DomainKeys Identified Mail) est une méthode plus sophistiquée. Elle ajoute une signature cryptographique à vos emails. C'est comme un sceau que vous apposez sur votre courrier : le destinataire peut vérifier que le courrier vient bien de vous et qu'il n'a pas été ouvert ou modifié en chemin. Le RFC 6376 (septembre 2011) en est la référence.
Comment ça marche ?
Vous générez une paire de clés RSA : une clé privée, que votre serveur de messagerie utilise pour signer chaque email sortant, et une clé publique, que vous publiez dans votre DNS. Le serveur de réception récupère votre clé publique via DNS et l'utilise pour vérifier la signature de l'email. Si la signature est valide, l'email est authentifié.
Générer et configurer une clé DKIM
Sur votre serveur Linux, avec OpenSSL :
openssl genrsa -out private.key 2048openssl rsa -in private.key -pubout -out public.key
La clé privée (private.key) doit être placée dans un endroit sécurisé sur votre serveur de messagerie (par exemple, /etc/opendkim/keys/votredomaine.com/default.private si vous utilisez OpenDKIM avec Postfix). La configuration d'OpenDKIM varie selon votre MTA, mais l'idée est de lui dire d'utiliser cette clé pour signer les emails de votre domaine.
Vous choisissez un sélecteur DKIM (par exemple default ou mail2026). Ce sélecteur permet au serveur destinataire de savoir quelle clé publique récupérer dans le DNS. Il permet également de gérer plusieurs clés et de les renouveler sans interrompre le service.
Votre enregistrement DNS prendra cette forme :
default._domainkey.votredomaine.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
Quelques explications :
default._domainkey: le nom du sélecteur et l'emplacement de la clé dans le DNS.v=DKIM1: la version du protocole DKIM.k=rsa: l'algorithme utilisé pour la clé.p=: la clé publique encodée en Base64, sans les lignesBEGIN PUBLIC KEYetEND PUBLIC KEY.
Attention, la commande OpenSSL précédente génère une clé au format PEM. Il ne suffit donc pas de copier son contenu directement dans l'enregistrement DNS. Il faut en extraire la partie Base64, retirer les retours à la ligne et conserver uniquement les données de la clé. Si vous utilisez OpenDKIM, son outil opendkim-genkey facilite considérablement l'opération en produisant directement la clé privée et un fichier contenant l'enregistrement DNS adapté.
Une fois votre serveur configuré, chaque email sortant contient un en-tête DKIM-Signature. Celui-ci précise notamment le domaine signataire (d=) et le sélecteur (s=). Le destinataire peut alors retrouver la bonne clé et vérifier la signature.
Pourquoi DKIM est indispensable
L'un des gros avantages de DKIM, c'est qu'il résiste généralement mieux aux transferts d'emails que SPF. Tant que le contenu signé et les en-têtes protégés ne sont pas modifiés d'une manière incompatible avec la signature, celle-ci reste valide, même si le message transite par un autre serveur.
Mais attention, DKIM n'est pas magique. Une liste de diffusion qui ajoute une signature en bas du message, un antispam qui réécrit certains contenus ou une passerelle qui modifie les en-têtes peuvent casser la signature.
Et surtout, une signature DKIM valide ne signifie pas automatiquement que l'expéditeur affiché est légitime. Un domaine malveillant peut parfaitement signer ses propres emails. Ce que DKIM prouve, c'est qu'un domaine donné a signé le message. Reste à vérifier que ce domaine correspond bien à celui que l'utilisateur voit dans son logiciel de messagerie.
C'est précisément le problème que DMARC va résoudre.
DMARC, le véritable chef d'orchestre
Nous y voilà ! DMARC, pour Domain-based Message Authentication, Reporting and Conformance, est la troisième pièce du puzzle. Et personnellement, c'est celle que je trouve la plus intéressante, parce qu'elle ne se contente pas de vérifier une information technique : elle permet au propriétaire d'un domaine de définir une véritable politique de protection.
DMARC s'appuie sur SPF et DKIM, mais ajoute une notion fondamentale : l'alignement des domaines.
L'alignement, ce détail qui change tout
Imaginons que je reçoive un email affichant contact@votredomaine.com comme expéditeur. Le serveur qui l'envoie possède un SPF parfaitement valide, mais pour le domaine autreservicedemail.com. Techniquement, SPF peut réussir. Pourtant, rien ne prouve que ce service soit autorisé à utiliser l'adresse visible contact@votredomaine.com.
DMARC va donc comparer les domaines utilisés pour l'authentification avec celui présent dans l'en-tête From:, celui que voit réellement le destinataire.
Pour qu'un email passe DMARC, il suffit que l'une des deux conditions suivantes soit remplie :
- SPF réussit et le domaine authentifié par SPF est aligné avec le domaine du
From:. - DKIM réussit et le domaine de la signature DKIM est aligné avec le domaine du
From:.
Il n'est donc pas nécessaire que SPF et DKIM réussissent tous les deux. Un seul mécanisme correctement authentifié et aligné suffit.
Par défaut, DMARC utilise un alignement dit « relaxé » : un sous-domaine peut être considéré comme aligné avec son domaine organisationnel. Il existe également un alignement strict, qui exige une correspondance exacte.
Cette distinction est particulièrement importante lorsqu'on utilise plusieurs services d'envoi, comme un serveur Postfix, une plateforme de newsletters et un prestataire chargé des emails transactionnels.
Créer son premier enregistrement DMARC
Comme SPF et DKIM, DMARC se configure dans le DNS avec un enregistrement TXT. Pour commencer, je conseille une politique de surveillance, sans rejet ni mise en quarantaine :
_dmarc.votredomaine.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com"
Décomposons cet enregistrement :
v=DMARC1: indique la version du protocole.p=none: demande aux destinataires de ne prendre aucune mesure particulière liée à la politique DMARC. Les échecs sont néanmoins visibles dans les rapports.rua=mailto:dmarc@votredomaine.com: adresse destinée à recevoir les rapports agrégés DMARC.
À ce stade, vous ne bloquez rien. Vous observez simplement ce qui se passe. Et croyez-moi, les premiers rapports peuvent réserver quelques surprises !
Les trois politiques DMARC
DMARC propose trois niveaux de protection :
p=none: surveillance uniquement. C'est le mode idéal pour découvrir les sources d'envoi de son domaine.p=quarantine: demande aux serveurs destinataires de traiter les messages échouant à DMARC comme suspects, généralement en les plaçant dans les indésirables.p=reject: demande aux serveurs destinataires de rejeter les messages qui ne passent pas DMARC.
Il faut bien comprendre qu'il s'agit d'une politique demandée aux serveurs de réception. Ceux-ci conservent leur propre logique de filtrage et peuvent prendre des décisions différentes selon leurs règles locales.
Mon objectif final est généralement d'arriver à cette configuration :
_dmarc.votredomaine.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.com; adkim=r; aspf=r"
Avec adkim=r et aspf=r, je conserve un alignement relaxé pour DKIM et SPF. C'est largement suffisant dans la majorité des environnements et cela évite de casser certains scénarios légitimes utilisant des sous-domaines.
Mais surtout, ne passez jamais directement en p=reject sur un domaine en production sans avoir analysé vos sources d'envoi. C'est le meilleur moyen de découvrir, un lundi matin, que votre application métier n'envoie plus ses notifications, que votre ERP ne transmet plus ses factures ou que les emails de votre site e-commerce disparaissent.
Les rapports DMARC : découvrir ce qui se passe réellement
C'est probablement la fonctionnalité la plus sous-estimée de DMARC. Grâce au paramètre rua, les fournisseurs de messagerie participants peuvent vous transmettre des rapports agrégés décrivant les messages qu'ils ont reçus en utilisant votre domaine.
Ces rapports contiennent notamment les adresses IP des serveurs émetteurs, les volumes de messages, les résultats SPF et DKIM, les informations d'alignement et les décisions DMARC.
Le problème ? Ils arrivent généralement sous forme de fichiers XML compressés. Autant dire que lire ça directement dans Thunderbird ou Outlook n'a rien d'une partie de plaisir.
Utiliser un analyseur de rapports
Heureusement, il existe plusieurs solutions pour rendre ces rapports exploitables. Des services comme URIports, EasyDMARC ou DMARCian proposent des tableaux de bord permettant de visualiser les sources d'envoi et les problèmes d'authentification.
Pour les amateurs d'auto-hébergement, des projets comme parsedmarc permettent également de traiter les rapports soi-même, de les stocker et de les exploiter dans des outils de visualisation.
C'est d'ailleurs une approche que j'apprécie particulièrement : récupérer automatiquement les rapports depuis une boîte dédiée, les analyser, puis disposer d'un tableau de bord qui présente les différents serveurs utilisant mon domaine.
On peut ainsi repérer :
- Un ancien serveur SMTP oublié qui continue à envoyer des messages.
- Une application web dont le serveur n'est pas autorisé dans le SPF.
- Un service externe qui signe ses emails avec son propre domaine au lieu du vôtre.
- Une machine compromise ou une tentative d'usurpation de votre domaine.
- Une augmentation inhabituelle du nombre de messages échouant aux vérifications DMARC.
Attention toutefois à ne pas confondre un échec DMARC et une attaque. Les transferts d'emails, certaines listes de diffusion ou des erreurs de configuration parfaitement légitimes peuvent aussi provoquer des échecs.
Les rapports ne couvrent pas non plus nécessairement tous les emails envoyés : tous les opérateurs ne transmettent pas de rapports, et les informations disponibles varient d'un fournisseur à l'autre.
Passer progressivement de la surveillance au rejet
La configuration de DMARC ne devrait pas être une opération ponctuelle réalisée en cinq minutes puis oubliée. Pour moi, c'est plutôt un petit projet d'assainissement de son infrastructure de messagerie.
Étape 1 : inventorier les serveurs d'envoi
Avant toute chose, je commence par identifier tous les systèmes capables d'envoyer des emails avec mon domaine. Le serveur SMTP principal, évidemment, mais aussi les applications PHP, les scripts cron, les outils de supervision, les plateformes commerciales, les services de newsletter et parfois même certains équipements réseau.
Dans une infrastructure qui a vécu plusieurs années, cette liste est rarement aussi courte qu'on l'imagine.
Étape 2 : vérifier SPF et DKIM
Chaque source d'envoi légitime doit disposer d'une méthode d'authentification correctement alignée. Lorsque c'est possible, je privilégie DKIM avec une signature utilisant mon propre domaine.
Je vérifie également que mon SPF reste valide, sans multiplier inutilement les mécanismes include. Il ne faut pas oublier que la limite de dix mécanismes et modificateurs provoquant des recherches DNS s'applique aussi aux appels imbriqués.
Un dépassement entraîne un résultat permerror, ce qui peut sérieusement perturber l'authentification.
Étape 3 : observer avec p=none
Je laisse fonctionner DMARC en mode surveillance suffisamment longtemps pour couvrir les différents cycles d'envoi. Une à plusieurs semaines sont généralement utiles, notamment lorsque certaines applications n'envoient leurs messages qu'une fois par mois.
Je regarde les rapports, je corrige les anomalies et je vérifie que les expéditeurs légitimes sont correctement authentifiés.
Étape 4 : activer la quarantaine
Une fois les sources d'envoi maîtrisées, je passe en p=quarantine. Il est possible de demander un déploiement progressif avec le paramètre pct :
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@votredomaine.com
Cette politique demande d'appliquer la quarantaine à une partie des messages qui échouent à DMARC. Cela peut permettre une transition progressive, même si les fournisseurs ne sont pas tous tenus d'appliquer exactement le même comportement opérationnel.
Étape 5 : passer en p=reject
Quand les rapports sont rassurants et que les flux légitimes ont été validés, je peux enfin activer le rejet.
v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.com
À partir de là, les destinataires appliquant la politique disposent d'une instruction claire : les messages qui prétendent provenir de mon domaine, mais qui ne passent pas les contrôles d'alignement DMARC, doivent être rejetés.
Cela ne signifie pas que mon domaine est devenu impossible à usurper, mais c'est une protection très importante contre les tentatives d'usurpation directe de son identité.
Vérifier sa configuration depuis Linux
Une fois tous ces enregistrements en place, encore faut-il vérifier qu'ils sont correctement publiés. Et pour ça, pas besoin d'une usine à gaz : dig fait parfaitement le travail.
Pour vérifier SPF :
dig TXT votredomaine.com +short
Pour consulter la clé publique DKIM :
dig TXT default._domainkey.votredomaine.com +short
Et pour vérifier la politique DMARC :
dig TXT _dmarc.votredomaine.com +short
Si les réponses correspondent aux enregistrements publiés, c'est un bon début. Mais attention, cela ne prouve pas que les emails sortants passent réellement les contrôles.
Le test le plus intéressant consiste à envoyer un email vers une boîte Gmail ou un autre fournisseur capable d'afficher les résultats d'authentification, puis à examiner les en-têtes du message reçu.
On recherche notamment une ligne Authentication-Results ressemblant à ceci :
Authentication-Results: mx.example.net;
spf=pass;
dkim=pass;
dmarc=pass
Ces trois résultats sont évidemment ce qu'on espère obtenir. Mais vérifiez également les domaines associés aux vérifications SPF et DKIM pour confirmer leur alignement avec l'adresse visible.
Des outils en ligne comme MXToolbox ou mail-tester.com peuvent compléter ces vérifications en détectant des erreurs de configuration ou des problèmes de délivrabilité.
Et pourtant, mes emails arrivent encore en spam !
C'est ici qu'il faut casser une idée reçue : SPF, DKIM et DMARC ne garantissent absolument pas qu'un email arrivera dans la boîte de réception.
Ces mécanismes prouvent que l'expéditeur est autorisé à utiliser un domaine et permettent de limiter certaines usurpations d'identité. Mais ils ne disent rien de la qualité réelle du message ni de la réputation du serveur qui l'envoie.
Un serveur parfaitement configuré peut encore se faire bloquer pour de nombreuses raisons :
- La réputation de l'adresse IP : une IP précédemment utilisée pour envoyer du spam peut conserver une mauvaise réputation.
- Le reverse DNS (PTR) : l'absence d'un nom d'hôte cohérent associé à l'adresse IP du serveur peut être pénalisante.
- La cohérence SMTP : un nom HELO/EHLO fantaisiste ou incohérent avec l'infrastructure peut éveiller les soupçons.
- La réputation du domaine : un domaine récent ou ayant déjà servi à des campagnes douteuses peut rencontrer davantage de difficultés.
- Le contenu des emails : les liens suspects, certaines pièces jointes et les messages trop agressivement commerciaux peuvent déclencher des filtres.
- Le comportement d'envoi : envoyer brutalement plusieurs milliers de messages depuis un serveur jusque-là silencieux est rarement une bonne idée.
- Les plaintes et les rebonds : les destinataires qui signalent vos messages comme indésirables et les nombreuses adresses invalides dégradent progressivement votre réputation.
Il faut également surveiller les listes de blocage DNSBL, respecter les exigences des grands fournisseurs de messagerie et, dans certains environnements, vérifier la réputation directement auprès de leurs outils dédiés.
Google propose notamment Postmaster Tools pour suivre certaines informations relatives à la réputation et à l'authentification. Du côté de Microsoft, les mécanismes de filtrage et de réputation peuvent être particulièrement exigeants avec les serveurs auto-hébergés.
Et c'est parfois frustrant : on peut avoir un Postfix impeccable, un certificat TLS valide, un SPF propre, une signature DKIM parfaite et une politique DMARC stricte, tout en voyant Outlook refuser certains messages à cause d'une adresse IP mal réputée.
La configuration technique est nécessaire, mais elle ne remplace pas une bonne réputation d'expéditeur.
Quelques erreurs que je ne referai plus
Avec le recul, il y a plusieurs erreurs classiques que j'essaie désormais d'éviter lorsque je configure un nouveau domaine.
La première, c'est de publier un SPF beaucoup trop permissif, simplement parce que c'est plus facile. Un +all revient pratiquement à autoriser n'importe quel serveur à utiliser le domaine pour SPF. Autant dire qu'on perd l'essentiel de l'intérêt du mécanisme.
La deuxième, c'est de déclarer plusieurs enregistrements SPF distincts sur le même domaine. SPF attend un seul enregistrement contenant la politique complète. Publier plusieurs enregistrements v=spf1 conduit à une erreur permanente, pas à une fusion automatique des autorisations.
La troisième, c'est d'oublier la rotation des clés DKIM. Une clé privée utilisée pendant des années sans aucune procédure de renouvellement n'est pas une bonne pratique. Les sélecteurs permettent justement de préparer une nouvelle clé, de l'activer progressivement et de retirer l'ancienne après la période de transition.
Enfin, la dernière erreur, et probablement la plus dangereuse, c'est de considérer DMARC comme une configuration qu'on n'a plus besoin de surveiller une fois passée en p=reject.
Une nouvelle application, un changement de prestataire SMTP, une migration de serveur ou une modification DNS peuvent suffire à introduire de nouveaux échecs d'authentification. Les rapports DMARC restent donc utiles même lorsque tout semble fonctionner.
Conclusion : trois acronymes, mais une vraie stratégie
SPF, DKIM et DMARC peuvent sembler complexes au premier abord. Entre les enregistrements TXT, les signatures cryptographiques, les sélecteurs, les politiques d'alignement et les rapports XML, il y a de quoi décourager plus d'un administrateur système.
Pourtant, une fois qu'on a compris leur complémentarité, les choses deviennent beaucoup plus logiques. SPF indique quels serveurs peuvent envoyer des emails pour un domaine d'enveloppe. DKIM permet de vérifier qu'un domaine a signé un message et que les éléments protégés n'ont pas été altérés. DMARC relie ces mécanismes à l'identité réellement affichée à l'utilisateur, tout en permettant de définir une politique et de recevoir des rapports.
Ce que j'apprécie particulièrement avec DMARC, c'est qu'il transforme un sujet longtemps assez opaque en quelque chose de mesurable. On ne se contente plus d'espérer que les emails arrivent : on commence à comprendre quels serveurs les envoient, comment ils sont authentifiés et où se trouvent les problèmes.
Évidemment, cela ne résout pas tous les problèmes de délivrabilité. La réputation IP, les pratiques d'envoi et les politiques parfois obscures des grands fournisseurs continueront à nous donner quelques cheveux blancs.
Mais au moins, avec SPF, DKIM et DMARC correctement configurés, on dispose de fondations solides. Et lorsqu'on administre ses propres serveurs de messagerie, c'est déjà une sacrée victoire.
Mon conseil pour terminer ? Si vous gérez encore un domaine sans DMARC, commencez simplement par publier une politique p=none avec une adresse de réception des rapports. Laissez tourner, observez et corrigez progressivement. Vous pourriez être surpris de découvrir combien de systèmes envoient encore des emails en votre nom sans que vous le sachiez.
Et surtout, souvenez-vous d'une chose : un email qui passe SPF, DKIM et DMARC n'est pas nécessairement un bon email. Mais un domaine correctement protégé est déjà beaucoup plus difficile à usurper. Et sur Internet, c'est loin d'être un détail !