SPF, DKIM, DMARC : les trois couches anti-usurpation de votre domaine

Quelqu'un peut envoyer un email qui semble venir de [email protected] sans avoir accès à votre serveur. C'est le phishing par usurpation de domaine (spoofing), et c'est ce que SPF, DKIM et DMARC sont conçus pour bloquer. Ces trois enregistrements DNS fonctionnent ensemble. On ne peut pas se contenter d'un seul. Voici ce que chacun fait, comment on les audite, et les pièges à éviter surtout avec DMARC p=reject.

Définition en une phrase

SPF, DKIM et DMARC sont trois enregistrements DNS qui permettent aux serveurs de messagerie destinataires de vérifier qu'un email prétendant venir de votre domaine est bien légitime.

En clair, pour les non-initiés. Imaginez que n'importe qui puisse envoyer une lettre avec votre adresse dans le champ expéditeur. SPF est la liste des facteurs autorisés à livrer en votre nom. DKIM est une signature électronique sur chaque lettre. DMARC est la consigne donnée aux destinataires : "si la signature ou l'origine est fausse, mettez l'email en quarantaine ou refusez-le".

Pourquoi c'est important pour votre site

Un domaine sans SPF/DKIM/DMARC peut être usurpé en quelques minutes. Quelqu'un envoie un email depuis [email protected] vers vos clients, vos fournisseurs ou votre banque, en demandant un virement ou des identifiants. Le message arrive dans la boîte de réception, pas dans les spams, parce que votre domaine est connu et vos destinataires vous font confiance.

Conséquences directes observées lors de nos audits PK.AUD :

• Clients floués par des faux emails de confirmation de commande.
• Notifications de changement de RIB frauduleuses envoyées à des partenaires.
• Campagnes de phishing à grande échelle utilisant des domaines légitimes non protégés.

Sur les audits PK.AUD qu'on réalise, SPF est absent ou mal configuré sur environ 40 % des domaines qu'on examine. DMARC est absent sur plus de 60 %, et quand il est présent, il est souvent en p=none (observation uniquement, aucune protection réelle).

Comment ça fonctionne, concrètement

SPF (Sender Policy Framework)

SPF est un enregistrement DNS de type TXT qui liste les adresses IP ou services autorisés à envoyer des emails pour votre domaine.

v=spf1 include:_spf.google.com include:sendgrid.net ip4:185.107.80.0/24 ~all

• include:_spf.google.com : autorise Google Workspace à envoyer.
• include:sendgrid.net : autorise SendGrid (transactionnel).
• ip4:185.107.80.0/24 : autorise un bloc d'IP de votre hébergeur.
• ~all : softfail (les messages des sources non listées sont acceptés mais marqués suspects). ~all est préférable à -all en phase de déploiement.

Limite de SPF : il ne vérifie que l'IP émettrice, pas le contenu du message. Un attaquant qui utilise un serveur autorisé (ex: un compte compromis chez le même provider) peut toujours usurper.

DKIM (DomainKeys Identified Mail)

DKIM ajoute une signature cryptographique dans l'en-tête de chaque email. La clé publique correspondante est publiée dans un enregistrement DNS TXT.

mail._domainkey.votre-domaine.fr  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Votre serveur d'envoi signe chaque email avec la clé privée. Le serveur destinataire récupère la clé publique dans le DNS et vérifie la signature. Si quelqu'un modifie le message en transit, la signature devient invalide.

DKIM résiste à la falsification de contenu, mais un attaquant peut envoyer un message non signé sans que SPF seul ne le bloque.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC orchestre SPF et DKIM. Il indique aux serveurs destinataires la conduite à tenir si les deux vérifications précédentes échouent.

_dmarc.votre-domaine.fr  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s;"

• p=none : observer uniquement, ne rien faire. Utile au démarrage pour collecter des rapports.
• p=quarantine : les emails qui échouent sont mis en spam.
• p=reject : les emails qui échouent sont refusés. Protection maximale.
• rua=mailto:... : adresse de réception des rapports agrégés (format XML, quotidiens).
• pct=100 : appliquer la politique à 100 % des messages.

Comment Secushot configure SPF, DKIM et DMARC en intervention

Dans notre pack PK.AUD Audit Complet 360°, la trilogie email est auditée sans modification. Dans les interventions P.01 et P.03, on peut procéder aux corrections selon le scope commandé.

Notre séquence standard :

1. Inventaire des expéditeurs légitimes. Qui envoie des emails depuis votre domaine ? Le serveur web (notifications transactionnelles), votre ESP (Mailchimp, Brevo, Resend), votre messagerie pro (Google Workspace, Microsoft 365), votre outil CRM. On liste tout avant de toucher au SPF.

2. SPF : on pose ~all en premier, pas -all. Le softfail permet d'identifier les expéditeurs oubliés sans rejeter leurs emails. On bascule à -all une fois qu'on est certains de la liste.

3. DKIM : on vérifie que chaque expéditeur légitime a bien son enregistrement publié. Les outils d'envoi modernes (Google, Brevo, SendGrid) fournissent les enregistrements DKIM à copier dans le DNS. On contrôle la validité avec dig TXT mail._domainkey.votre-domaine.fr.

4. DMARC : on commence en p=none avec rua=mailto: pour 2 semaines minimum. On analyse les rapports XML (on utilise des parsers comme dmarcian ou mail-tester pour les rendre lisibles). Puis on bascule à p=quarantine, puis p=reject une fois certains que les expéditeurs légitimes passent.

Vérification rapide en ligne de commande :

dig TXT votre-domaine.fr | grep spf
dig TXT _dmarc.votre-domaine.fr
dig TXT mail._domainkey.votre-domaine.fr

Les erreurs qu'on rencontre le plus souvent

1. DMARC p=reject activé trop tôt

C'est l'erreur la plus coûteuse. Un client bascule sur p=reject sans avoir audité tous ses expéditeurs. Résultat : les emails de son outil e-commerce (PrestaShop, WooCommerce), de son CRM ou de son prestataire facturation sont rejetés par les serveurs destinataires. Les clients ne reçoivent plus rien. On a vu des entreprises perdre des commandes pendant plusieurs jours à cause de ce bug. La règle : p=none pendant au moins deux semaines avec analyse des rapports rua avant tout passage en reject.

2. Plus de dix lookups DNS dans le SPF

Le protocole SPF limite à 10 les inclusions DNS récursives. Un enregistrement qui dépasse cette limite est invalide, et certains serveurs destinataires rejettent tous les emails du domaine. C'est un problème fréquent quand on accumule plusieurs services (Google Workspace + SendGrid + HubSpot + Mailchimp). On doit aplatir le SPF ou utiliser des macros pour rester sous la limite.

3. DKIM avec une clé de 1024 bits

Les bonnes pratiques actuelles recommandent des clés DKIM de 2048 bits minimum. Les clés 1024 bits sont considérées comme faibles. Certains fournisseurs d'emails (Brevo, SendGrid, Google) génèrent des clés de 2048 bits par défaut, mais les configurations héritées des années 2015-2018 tournent encore en 1024. On vérifie la taille de clé dans chaque audit.

4. SPF configuré sans couvrir le serveur web

Le site envoie des emails de notification (commandes, mots de passe oubliés) depuis l'IP de l'hébergeur, mais cette IP n'est pas dans le SPF. Les notifications arrivent en spam chez Gmail et Outlook. On vérifie systématiquement que l'IP du serveur web figure dans le SPF ou est couverte par un include: du provider d'hébergement.

5. Sous-domaines non couverts

Un enregistrement DMARC sur le domaine racine (@) protège aussi les sous-domaines, mais SPF et DKIM doivent être configurés séparément pour chaque sous-domaine expéditeur. Un sous-domaine comme newsletter.votre-domaine.fr qui envoie des emails sans son propre SPF/DKIM n'est pas couvert.

Questions fréquentes

SPF, DKIM et DMARC sont-ils obligatoires ? Non, mais ils sont fortement recommandés depuis 2024 par Google et Yahoo (qui les exigent pour les envois en volume vers leurs utilisateurs). Sans ces enregistrements, vos emails transactionnels risquent d'atterrir en spam ou d'être rejetés.

Faut-il les trois ou suffit-il d'en avoir un ? Il faut les trois pour une protection complète. SPF seul ne protège pas contre la falsification de l'en-tête From:. DKIM seul ne bloque pas les emails envoyés depuis des IPs non autorisées. DMARC sans SPF ni DKIM ne peut pas prendre de décision fiable.

Mon hébergeur gère-t-il SPF et DKIM automatiquement ? Certains hébergeurs (OVH, PlanetHoster, o2switch) publient des SPF par défaut pour leurs serveurs, mais ne configurent pas forcément DKIM ni DMARC. On vérifie cela dans chaque audit PK.AUD. La configuration reste souvent partielle ou incomplète.

Combien de temps faut-il pour déployer les trois ? Pour un domaine simple avec un seul expéditeur (Google Workspace ou similaire), 30 à 60 minutes d'une personne avec accès au DNS. Pour un domaine avec plusieurs services d'envoi et un historique de configuration épars, comptez une demi-journée d'audit et de tests.

DMARC p=reject, c'est dangereux à activer ? Non si on a bien suivi les deux étapes précédentes (p=none puis p=quarantine). Le danger vient de brûler les étapes. Notre recommandation : au moins 2 semaines en p=none avec des rapports rua actifs, puis 2 semaines en p=quarantine, puis p=reject.

Ces enregistrements améliorent-ils la délivrabilité des emails ? Oui, directement. Les serveurs de messagerie modernes scorent positivement les domaines avec SPF, DKIM et DMARC configurés. Les emails légitimes arrivent mieux en boîte principale. C'est un bénéfice secondaire, mais mesurable.

Pour aller plus loin

• Connexe : HSTS, Cloudflare WAF, CSP (Content Security Policy).
• Protocoles concernés : SPF, DKIM et DMARC sont audités dans le pack Audit Complet 360° PK.AUD (990 € TTC, livré en 5 jours). Ils sont aussi vérifiés dans l'audit préventif P.01, sans modification.

Domaine non protégé contre l'usurpation d'email ? Notre audit complet 360° (PK.AUD, 990 € TTC, livré en 5 jours) inclut l'audit DNS, SPF, DKIM et DMARC, plus l'ensemble de la configuration sécurité de votre site. Aucun accès serveur requis. Rapport PDF priorisé. Briefer un audit complet PK.AUD