SPF, DKIM et DMARC : configurer l’authentification de vos e-mails

Le courrier électronique a été conçu sans aucune vérification d’identité. N’importe qui peut, aujourd’hui encore, envoyer un message en prétendant écrire depuis votre domaine — c’est aussi simple que d’écrire un nom d’expéditeur sur une enveloppe.

Trois mécanismes ont été ajoutés par-dessus pour combler ce trou. Ils sont complémentaires et ne se remplacent pas : SPF dit qui a le droit d’envoyer, DKIM prouve que le message n’a pas été modifié, DMARC dit quoi faire quand ça ne colle pas et fait remonter l’information.

Sans les trois, une part de vos e-mails finira en spam. Et sans DMARC, vous ne saurez jamais que quelqu’un usurpe votre domaine.

SPF : la liste des expéditeurs autorisés

SPF (Sender Policy Framework) est un enregistrement TXT publié à la racine de votre domaine, qui énumère les serveurs autorisés à envoyer du courrier en son nom.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

Chaque élément est un mécanisme :

include: — délègue l’autorisation à un autre domaine. C’est ce que vous utiliserez pour votre hébergeur de messagerie, votre outil de newsletter, votre CRM.
ip4: / ip6: — autorise une adresse IP précise. Utile pour un serveur d’application qui envoie ses propres notifications.
a et mx — autorisent les serveurs pointés par les enregistrements A ou MX du domaine.

Le mécanisme final, celui qui compte

Le dernier élément décide du sort des messages venant d’un serveur non listé :

Mécanisme	Sens	Effet réel
`-all`	Échec strict	Le message doit être rejeté. C’est la bonne valeur.
`~all`	Échec souple	Le message est accepté mais marqué suspect. Étape de transition.
`?all`	Neutre	Aucune opinion — autant ne rien publier.
`+all`	Tout autorisé	À ne jamais utiliser. Autorise le monde entier à écrire en votre nom.

Commencez en ~all le temps de vérifier que rien de légitime n’est bloqué, puis passez en -all. Rester en ~all indéfiniment est une configuration inachevée : elle protège beaucoup moins que ce que les gens imaginent.

Les deux pièges de SPF

Un seul enregistrement SPF par domaine. Deux enregistrements v=spf1 sur le même nom rendent l’évaluation invalide — et donc inopérante. C’est l’erreur la plus fréquente : on ajoute un prestataire en créant un nouveau TXT au lieu de compléter celui qui existe. Il faut fusionner les include: dans une seule ligne.

Dix requêtes DNS maximum. Chaque include:, a, mx ou redirect déclenche une résolution DNS, et la norme plafonne à dix. Au-delà, le résultat est permerror et SPF ne protège plus rien. Trois ou quatre prestataires suffisent à s’en approcher, car un include: peut lui-même en contenir d’autres. C’est un compteur qu’il faut surveiller, pas une limite théorique.

DKIM : la signature cryptographique

DKIM (DomainKeys Identified Mail) ne dit pas qui a le droit d’envoyer : il prouve qu’un message provient bien de votre infrastructure et qu’il n’a pas été altéré en route.

Le serveur d’envoi signe chaque message avec une clé privée. La clé publique correspondante est publiée dans votre DNS, à une adresse de la forme :

<sélecteur>._domainkey.votre-domaine.ma

Le sélecteur est un identifiant choisi par le prestataire — google, selector1, k1, default, mxvault… Il permet d’avoir plusieurs clés simultanément, ce qui est indispensable : chaque service qui envoie en votre nom a la sienne, et une rotation de clé se fait en publiant la nouvelle avant de retirer l’ancienne.

Le principal écueil de DKIM n’est pas la mise en place, c’est l’oubli d’un émetteur. Vous signez le courrier de votre messagerie, mais pas les factures envoyées par votre outil de comptabilité, ni les notifications de votre boutique. Ces messages-là passeront moins bien — et casseront DMARC si vous le passez en mode strict.

DMARC : la politique, et surtout les rapports

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la pièce qui rend les deux autres utiles. C’est un TXT publié sur _dmarc.votre-domaine.ma :

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Il fait deux choses.

Il fixe une politique — que faire d’un message qui échoue SPF et DKIM :

Politique	Effet
`p=none`	Rien. Le message passe. Mode observation.
`p=quarantine`	Le message part en indésirable.
`p=reject`	Le message est refusé à la porte. L’objectif à atteindre.

Il vous fait remonter des rapports. L’adresse indiquée dans rua= reçoit quotidiennement, de la part des grands fournisseurs de messagerie, un résumé de tous les envois faits en votre nom : combien de messages, depuis quelles adresses IP, avec quel résultat d’authentification.

C’est de loin la fonction la plus utile, et la plus négligée. Sans ces rapports, vous ne savez ni qui usurpe votre domaine, ni quel service légitime vous avez oublié de configurer.

Où envoyer les rapports

Un détail pratique qui décourage beaucoup de monde : l’adresse rua= reçoit un fichier XML compressé par domaine expéditeur et par jour. Sur un domaine actif, cela fait vite plusieurs dizaines de pièces jointes hebdomadaires, illisibles à l’œil nu.

Deux conséquences. D’abord, ne mettez jamais votre adresse principale dans rua= : créez une boîte dédiée, que vous ne relèverez pas à la main. Ensuite, prévoyez un analyseur — la plupart des services DMARC proposent une offre gratuite suffisante pour un seul domaine, et transforment ces XML en un tableau lisible.

Quant à ruf=, qui demande des rapports d’échec détaillés message par message : la plupart des grands fournisseurs ne l’honorent plus, parce que ces rapports contiennent des données personnelles. Vous pouvez le publier, mais ne construisez pas votre surveillance dessus.

La progression à respecter

Passer directement en p=reject est le meilleur moyen de bloquer ses propres e-mails. La séquence éprouvée :

p=none avec rua= pendant deux à quatre semaines. Vous ne bloquez rien, vous observez.
Lisez les rapports. Identifiez tous les émetteurs légitimes qui échouent — il y en aura, et ce sont eux qu’il faut corriger d’abord.
p=quarantine, éventuellement avec pct=25 puis pct=100 pour n’appliquer la politique qu’à une fraction du trafic dans un premier temps.
p=reject une fois qu’un mois de rapports ne montre plus d’échec légitime.

Alignement : le détail qui fait échouer

DMARC ne se contente pas de vérifier que SPF ou DKIM passent : il exige que le domaine validé corresponde au domaine affiché dans le champ From: du message. C’est l’alignement.

Concrètement : si votre newsletter part avec un From: en [email protected] mais que SPF valide le domaine du prestataire, l’alignement échoue et DMARC échoue avec lui — même si SPF est techniquement « vert ». C’est la cause d’échec la plus déroutante, parce que chaque mécanisme pris isolément semble fonctionner.

Les paramètres aspf et adkim contrôlent la souplesse de cette correspondance : r (relâché, la valeur par défaut) accepte les sous-domaines, s (strict) exige une correspondance exacte.

L’ordre de mise en place

Recensez vos émetteurs. Messagerie, newsletter, CRM, facturation, boutique, notifications applicatives. C’est l’étape que tout le monde bâcle, et celle qui détermine si la suite fonctionne.
Publiez SPF avec tous les include: nécessaires, en ~all.
Activez DKIM chez chaque prestataire, un par un.
Publiez DMARC en p=none avec une adresse rua= que vous relevez vraiment.
Attendez et lisez. Deux à quatre semaines de rapports.
Durcissez : SPF en -all, DMARC en quarantine puis reject.

Vérifier une configuration existante

L’audit SPF/DKIM/DMARC du site analyse les trois mécanismes en une requête et signale les erreurs classiques : enregistrement SPF en double, dépassement des dix requêtes, politique DMARC absente ou permissive, sélecteurs DKIM introuvables.

Un point à garder en tête sur ce dernier : un sélecteur DKIM ne se devine pas. L’outil teste les sélecteurs les plus répandus, mais un prestataire qui en utilise un personnalisé apparaîtra comme « non trouvé » alors que sa configuration est correcte. Dans ce cas, interrogez directement <sélecteur>._domainkey.votre-domaine.ma en TXT avec l’outil DNS pour lever le doute.