SPF, DKIM et DMARC : protéger votre domaine contre l'usurpation d'e-mails
Un fournisseur reçoit un e-mail qui semble venir de votre service comptable et lui demande de modifier un RIB. Votre client reçoit une fausse facture à en-tête de votre société. Dans les deux cas, l'expéditeur affiché utilise votre nom de domaine, et rien ne l'en empêche si votre domaine n'est pas protégé. Trois mécanismes, configurés dans votre zone DNS, permettent aux messageries de vos correspondants de détecter et de rejeter ces faux messages : SPF, DKIM et DMARC.
SPF : qui a le droit d'envoyer pour votre domaine
SPF (Sender Policy Framework) publie la liste des serveurs autorisés à envoyer des e-mails pour votre domaine. Il prend la forme d'un enregistrement TXT. Pour un domaine qui envoie uniquement via Microsoft 365 :
exemple.fr. TXT "v=spf1 include:spf.protection.outlook.com -all"include: ajoute les serveurs d'un prestataire (Microsoft 365, outil d'e-mailing, logiciel de facturation…) ;
-all demande de rejeter les messages venant de tout autre serveur, ~all de les marquer comme suspects.
Deux règles à respecter : un seul enregistrement SPF par domaine, et pas plus de 10 recherches DNS dans l'enregistrement (chaque include en compte au moins une). Au-delà, l'évaluation SPF renvoie une erreur permanente (permerror), que DMARC traite comme un échec.
DKIM : une signature sur chaque message
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque e-mail envoyé. Le serveur destinataire la vérifie avec une clé publique publiée dans votre DNS. Il sait ainsi que le message vient bien de votre domaine et qu'il n'a pas été modifié en chemin.
Avec Microsoft 365, l'activation se fait dans le portail Microsoft Defender, qui vous indique deux enregistrements CNAME à publier (de la forme selector1._domainkey et selector2._domainkey). Chaque prestataire qui envoie des e-mails en votre nom doit, lui aussi, signer avec DKIM pour votre domaine.
DMARC : la politique et les rapports
DMARC (Domain-based Message Authentication, Reporting and Conformance) s'appuie sur SPF et DKIM et ajoute deux éléments essentiels :
L'alignement : le domaine validé par SPF (adresse de retour, ou Return-Path) ou par DKIM (domaine signataire) doit correspondre au domaine affiché dans le champ « De » vu par le destinataire. C'est ce qui bloque réellement l'usurpation.
Une politique indiquant quoi faire des messages qui échouent, et une adresse où recevoir des rapports sur tous les e-mails envoyés au nom de votre domaine.
_dmarc.exemple.fr. TXT "v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr"La politique p prend trois valeurs : none (observer sans bloquer), quarantine (envoyer en courrier indésirable) et reject (rejeter).
Une mise en place progressive, en trois étapes
Passer directement à p=reject risque de bloquer des e-mails légitimes envoyés par un outil oublié : logiciel de paie, plateforme de recrutement, CRM. La bonne démarche :
Observation (p=none) pendant quelques semaines. Les rapports DMARC révèlent tous les services qui envoient des e-mails en votre nom.
Correction : chaque service légitime est ajouté au SPF et configuré avec DKIM pour votre domaine.
Durcissement : passage à p=quarantine, puis à p=reject une fois que les rapports ne montrent plus d'échec légitime.
Les rapports DMARC sont des fichiers XML difficiles à lire tels quels. Un outil d'analyse, ou un prestataire, les transforme en tableau de bord exploitable.
Pourquoi c'est devenu urgent
Les grands fournisseurs de messagerie durcissent leurs exigences. Depuis février 2024, Google et Yahoo exigent de tous les expéditeurs au moins SPF ou DKIM, et des expéditeurs en volume (plus de 5 000 messages par jour vers Gmail) SPF et DKIM, une politique DMARC alignée (au minimum p=none) ainsi qu'un désabonnement en un clic. Microsoft a appliqué des exigences comparables à Outlook.com en mai 2025. Un domaine mal configuré voit ses e-mails légitimes classés en indésirables, voire refusés. La protection contre l'usurpation et la délivrabilité de vos e-mails vont désormais de pair.
N'oubliez pas les domaines qui n'envoient pas d'e-mails
Les domaines secondaires ou parkés, qui ne servent jamais à envoyer d'e-mails, sont aussi des cibles. Protégez-les avec un SPF v=spf1 -all, une politique DMARC p=reject et, idéalement, un enregistrement MX nul (exemple.fr. MX 0 .), qui signale qu'ils ne reçoivent pas d'e-mails.
Gazeltech audite la configuration de vos domaines, analyse vos rapports DMARC et pilote le passage progressif à une politique de rejet, sans perturber vos envois légitimes. Contactez nos équipes pour un état des lieux de vos domaines.
Commentaires