DMARC, SPF et DKIM : empêcher l’usurpation de votre nom de domaine par e-mail

Le protocole d’envoi des e-mails date d’une époque où tout le monde se faisait confiance : rien n’empêche un inconnu d’écrire comptabilite@votre-entreprise.fr dans le champ « De ». C’est la base de nombreuses campagnes d’hameçonnageHameçonnage (phishing)Escroquerie qui imite un expéditeur de confiance (banque, fournisseur, collègue) par e-mail, SMS, appel ou QR code pour pousser la victime à cliquer, à livrer ses identifiants ou à payer. (phishing) et des fraudes au faux fournisseur ou au faux dirigeantFraude au président (FOVI)Escroquerie où un fraudeur se fait passer pour un dirigeant, un fournisseur ou un avocat afin d’obtenir d’un salarié un virement urgent et confidentiel vers un compte qu’il contrôle. : vos clients reçoivent un message qui semble venir de chez vous, avec un nouveau RIB ou un lien piégé.

Trois enregistrements DNS, SPF, DKIM et DMARC, permettent aux messageries de vérifier qu’un e-mail vient bien de vous et de rejeter les autres. Ils sont gratuits, mais encore mal appliqués.

66 %

Source : Baromètre KrakenShield 2026

Ce chiffre, issu de notre baromètre des 100 plus grandes villes, montre que même des organisations importantes laissent leur nom utilisable par n’importe quel fraudeur.

Pourquoi votre nom de domaine intéresse les fraudeurs

Un e-mail usurpé est efficace parce qu’il emprunte la confiance que vos clients, vos fournisseurs et vos salariés vous accordent. Le fraudeur n’a pas besoin de pirater votre messagerie : il lui suffit que personne, de l’autre côté, ne puisse vérifier l’expéditeur.

Les conséquences dépassent la fraude elle-même : clients escroqués qui se retournent contre vous, réputation abîmée, et vos vrais e-mails qui finissent en indésirables parce que votre domaine a servi à du spam.

SPF, DKIM, DMARC : trois mécanismes, un seul objectif

SPF : la liste des expéditeurs autorisés

SPF (Sender Policy Framework, RFC 7208) est un enregistrement TXT publié sur votre domaine. Il liste les serveurs autorisés à envoyer des e-mails pour vous : votre messagerie, votre outil de newsletter, votre logiciel de facturation. Le serveur destinataire compare l’adresse IP de l’expéditeur à cette liste.

Limite importante : SPF vérifie l’adresse technique de retour (l’enveloppe, « MAIL FROM »), pas l’adresse visible par le lecteur. Seul, il n’empêche donc pas l’usurpation de l’adresse affichée.

DKIM : la signature de chaque message

DKIM (DomainKeys Identified Mail, RFC 6376) ajoute à chaque e-mail une signature numériqueSignature numériqueMécanisme cryptographique qui prouve qui a signé un document ou un logiciel et garantit qu’il n’a pas été modifié depuis.. Votre serveur signe avec une clé privée ; la clé publique correspondante est publiée dans votre DNS, sous un nom appelé sélecteur. Le destinataire vérifie que le message n’a pas été modifié et qu’il a bien été signé par le domaine annoncé. Google recommande des clés de 2 048 bits (1 024 bits au minimum).

Avantage de DKIM : la signature survit au transfert d’un message par un intermédiaire (liste de diffusion, redirection), là où SPF échoue souvent.

DMARC : la règle du jeu et les rapports

DMARC, dont la norme a été mise à jour en mai 2026 (RFC 9989, qui remplace la RFC 7489), fait trois choses :

1. il exige que SPF ou DKIM réussisse avec un domaine aligné sur l’adresse visible « De » ;
2. il indique au destinataire quoi faire des messages qui échouent : none (ne rien faire de particulier), quarantine (indésirables) ou reject (rejet) ;
3. il vous fait envoyer des rapports par les messageries qui reçoivent des e-mails à votre nom.

L’alignement, la notion qui change tout

Un fraudeur peut très bien faire réussir SPF avec son propre domaine technique, tout en affichant le vôtre dans le champ « De ». L’alignement ferme cette porte : DMARC ne réussit que si le domaine validé par SPF ou par DKIM correspond à celui de l’adresse visible.

En mode souple (par défaut), facturation.example.com est aligné avec example.com. En mode strict (adkim=s, aspf=s), il faut une correspondance exacte.

Ce qu’exigent Gmail, Yahoo et Outlook.com

Les grandes messageries ont transformé ces bonnes pratiques en conditions de remise :

Messagerie	Depuis	Qui est concerné	Exigences principales
Gmail	1er février 2024	Tous les expéditeurs	SPF ou DKIM, taux de spam sous 0,3 %
Gmail	1er février 2024	Plus de 5 000 messages par jour vers Gmail	SPF, DKIM et DMARC (p=none accepté), alignement, désabonnement en un clic
Yahoo	Février 2024	Expéditeurs en volume	SPF et DKIM, DMARC au moins p=none, alignement, désabonnement en un clic
Outlook.com, Hotmail, Live	5 mai 2025	5 000 messages ou plus vers ces messageries grand public	SPF et DKIM, DMARC au moins p=none et aligné ; sinon rejet (erreur 550 5.7.515)

Ces règles visent surtout les gros expéditeurs, et elles acceptent p=none. Elles améliorent votre délivrabilité, mais ne suffisent pas à protéger votre domaine : pour cela, il faut aller jusqu’à quarantine ou reject.

Les enregistrements DNS types

Voici des exemples pour le domaine fictif example.com, à adapter à vos services :

Mécanisme	Nom DNS (TXT)	Valeur d’exemple	Rôle
SPF	example.com	v=spf1 include:_spf.messagerie.example ip4:203.0.113.10 -all	Autorise votre messagerie et un serveur, refuse le reste
DKIM	s1._domainkey.example.com	v=DKIM1; k=rsa; p=MIIBIjANBg…	Clé publique fournie par votre service d’envoi
DMARC (observation)	_dmarc.example.com	v=DMARC1; p=none; rua=mailto:dmarc@example.com	Ne bloque rien, envoie les rapports
DMARC (protection)	_dmarc.example.com	v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com	Rejette les faux, sous-domaines compris

Pour un domaine qui n’envoie jamais d’e-mail (ancien nom, domaine de marque), verrouillez-le complètement :

example.net.          TXT  "v=spf1 -all"
_dmarc.example.net.   TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

Déployer DMARC sans bloquer vos propres e-mails

Passer directement à p=reject est le meilleur moyen de faire disparaître vos factures ou votre newsletter. La bonne méthode est progressive.

Étape 1 : inventaire. Listez tout ce qui envoie des e-mails à votre nom : messagerie, site web (formulaires), newsletter, CRM, logiciel de facturation ou de paie, outil de support, imprimantes et copieurs qui envoient des scans.

Étape 2 : SPF et DKIM partout. Pour chaque service, ajoutez-le à votre SPF et activez DKIM avec votre domaine (chaque prestataire sérieux fournit les enregistrements à publier).

Étape 3 : DMARC en observation. Publiez p=none avec une adresse rua. Les messageries vous enverront des rapports agrégés, en général quotidiens, au format XML : quelles adresses IP ont envoyé des e-mails à votre nom, en quelle quantité, et avec quel résultat SPF, DKIM et DMARC. Ces fichiers sont illisibles à l’œil nu : utilisez un outil d’analyse de rapports DMARC. Si l’adresse rua appartient à un autre domaine que le vôtre (celui d’un prestataire), ce domaine doit l’autoriser dans son DNS : votre prestataire s’en charge en général.

Étape 4 : corriger. Pour chaque source légitime qui échoue, corrigez SPF ou DKIM. Ce qui reste en échec et que vous ne reconnaissez pas, ce sont des usurpations : la preuve que la protection est utile.

Étape 5 : quarantine, puis reject. Quand les rapports ne montrent plus d’envoi légitime en échec pendant plusieurs semaines, passez à p=quarantine, observez encore, puis à p=reject.

Les pièges classiques

• Deux enregistrements SPF. En ajoutant un service, on crée souvent un second TXT v=spf1. La norme impose alors une erreur permanente : SPF échoue pour tous vos messages. Fusionnez tout dans un seul enregistrement.
• Plus de 10 requêtes DNS. SPF limite à 10 les mécanismes qui déclenchent une requête DNS (include, a, mx, ptr, exists, redirect), y compris ceux des include imbriqués. Au-delà : erreur permanente. Supprimez les services abandonnés, remplacez ce qui peut l’être par des ip4 ou ip6, ou confiez un sous-domaine dédié à la newsletter.
• Les sous-domaines oubliés. Sans sp=, vos sous-domaines suivent la politique p. Un sous-domaine qui envoie (par exemple news.example.com) doit avoir son propre SPF et sa propre signature DKIM. La norme de 2026 ajoute aussi np= pour les sous-domaines qui n’existent pas, souvent utilisés par les fraudeurs.
• Les prestataires d’envoi oubliés. Newsletter, CRM, facturation, recrutement, billetterie : un outil qui envoie avec votre adresse sans DKIM aligné sera bloqué dès quarantine. Les rapports DMARC servent précisément à les débusquer.
• Un SPF trop permissif. +all autorise toute la planète à envoyer pour vous : à proscrire.

Vérifier votre configuration

Checklist à dérouler une fois par trimestre, et à chaque nouveau service d’envoi :

• Un seul enregistrement TXT v=spf1 sur le domaine, qui se termine par -all ou ~all.
• Moins de 10 requêtes DNS dans SPF, include imbriqués compris.
• DKIM actif pour chaque service d’envoi, signé avec votre domaine, clé de 2 048 bits si possible.
• Un enregistrement _dmarc avec une adresse rua qui reçoit réellement des rapports.
• Une politique quarantine ou reject, avec une date cible si vous êtes encore en p=none.
• Les domaines dormants verrouillés (v=spf1 -all et p=reject).
• Un test réel : envoyez un e-mail vers une boîte Gmail ou Outlook.com et affichez l’original ; les lignes spf=pass, dkim=pass et dmarc=pass doivent apparaître.

Pour un regard extérieur, l’audit de confidentialité de KrakenShield contrôle notamment la présence et la politique de vos enregistrements SPF et DMARC, avec les corrections à appliquer.

Votre surface d’attaqueSurface d’attaqueEnsemble des points par lesquels un attaquant peut tenter d’entrer dans votre système d’information ou d’en extraire des données : services exposés sur Internet, applications, comptes, équipements, prestataires et personnes. ne se limite pas à vos serveurs : votre nom de domaine en fait partie. Quelques lignes DNS bien posées suffisent à empêcher qu’il serve d’arme contre vos propres clients.