SPF, DKIM, DMARC et permutations de domaine : les fondamentaux de

Ce billet explique les risques et la théorie derrière SPF, DKIM et DMARC, et pourquoi les permutations de domaine (domaines ressemblants) sont le multiplicateur silencieux qui transforme « un seul e-mail usurpé » en désastre pour la marque, les finances et le vol d’identifiants.

Le cœur du problème : l’e-mail a été conçu pour la livraison, pas pour l’identité

SMTP (le protocole qui fait circuler les e-mails) a été imaginé à une époque où la confiance allait de soi. Par défaut :

L’en-tête “From:” n’est qu’un texte.
N’importe qui peut tenter d’envoyer un message en prétendant être ceo@yourcompany.com.
Historiquement, de nombreux systèmes de messagerie acceptaient les messages tant qu’ils pouvaient être remis.

Les défenses modernes ajoutent une authentification au niveau du domaine par-dessus SMTP. C’est précisément le rôle de SPF, DKIM et DMARC.

SPF : « Quels serveurs sont autorisés à envoyer du courrier pour mon domaine ? »

SPF (Sender Policy Framework) est un enregistrement DNS qui liste les serveurs de messagerie (ou services d’envoi) autorisés à envoyer des e-mails en utilisant votre domaine dans l’envelope-from / return-path.

Comment SPF fonctionne (théorie)

Lorsqu’un serveur de messagerie reçoit un message, il vérifie :

Quel domaine est utilisé dans l’expéditeur de l’enveloppe (Return-Path).
Ce domaine publie-t-il un enregistrement SPF dans le DNS ?
L’IP de connexion est-elle autorisée par cet enregistrement SPF ?

Si oui → SPF passe. Sinon → SPF échoue (ou softfail/neutral selon la politique).

Exemple d’enregistrement SPF

example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Modes d’échec courants de SPF (là où les attaquants gagnent)

Trop permissif : v=spf1 +all (en gros, « n’importe qui peut envoyer »).
Softfail à perpétuité : ~all sans application DMARC, ce qui aboutit à un traitement en mode « bof ».
Includes manquants : votre CRM, votre système de tickets, votre outil de newsletter ne sont pas listés → les e-mails légitimes échouent.
Limite de requêtes DNS : SPF a une limite de 10 recherches DNS ; des chaînes include: complexes peuvent casser la remise.
SPF ne protège que le domaine de l’enveloppe : les attaquants peuvent toujours faire ressembler le champ From visible à votre adresse à moins que DMARC n’impose l’alignement.

En bref : SPF est nécessaire, mais pas suffisant pour stopper l’usurpation.

DKIM : « Cet e-mail a-t-il vraiment été envoyé par quelqu’un qui possède la clé privée du domaine ? »

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique aux messages sortants. L’expéditeur signe certains en-têtes (et parfois le corps) avec une clé privée. Le destinataire récupère la clé publique dans le DNS et vérifie la signature.

Comment DKIM fonctionne (théorie)

Le serveur de messagerie sortant ajoute un en-tête comme :
- DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Le destinataire interroge le DNS :
- selector1._domainkey.example.com → clé publique
Si la signature correspond → DKIM passe.

Exemple d’enregistrement DNS DKIM

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Modes d’échec de DKIM (là où les attaquants gagnent)

Aucun DKIM du tout : beaucoup de domaines ne signent toujours pas leurs messages de façon cohérente.
Signature sélective : seuls certains systèmes signent (par exemple Microsoft 365 le fait, mais pas votre outil marketing).
Signatures cassées : les relais ou listes de diffusion peuvent modifier le contenu/les en-têtes et casser DKIM.
Clés faibles/anciennes : des clés courtes ou conservées trop longtemps augmentent le risque (si elles sont compromises, l’usurpation devient triviale).
Domaine mal aligné : DKIM réussit pour un domaine différent de celui que les utilisateurs voient dans “From”.

En bref : DKIM est puissant parce qu’il est cryptographique, mais il a besoin d’alignement et de politique — c’est le travail de DMARC.

DMARC : « Que doivent faire les destinataires si SPF/DKIM échouent — et est-ce que cela correspond au From visible ? »

DMARC (Domain-based Message Authentication, Reporting & Conformance) relie tout ensemble :

Il exige que SPF et/ou DKIM réussissent, et
Ils doivent être alignés avec le domaine From: que les utilisateurs voient réellement.

Puis il indique aux destinataires quoi faire si l’authentification échoue :

p=none (surveillance uniquement)
p=quarantine (envoyer les messages suspects au spam/indésirables)
p=reject (bloquer purement et simplement)

Alignement DMARC (le concept clé)

Les attaquants adorent cette faille :

SPF passe pour random-sender.com
“From:” affiche ceo@yourcompany.com

Sans alignement DMARC, un message peut sembler venir de vous même si le domaine authentifié n’a rien à voir.

DMARC dit : l’identité authentifiée doit correspondre au From visible, pas seulement « quelque chose a réussi quelque part ».

Exemple d’enregistrement DMARC (surveillance)

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Exemple d’enregistrement DMARC (application)

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; adkim=s; aspf=s"

Modes d’échec de DMARC (là où les attaquants gagnent)

Bloqué à p=none pour toujours : vous recevez des rapports, mais l’usurpation continue d’atterrir.
Aucune adresse de reporting ou rapports ignorés : vous êtes aveugle face à ceux qui abusent de votre domaine.
Alignement mal configuré : des services légitimes échouent et vous revenez en arrière sur l’application.
Angles morts sur les sous-domaines : sans politique dédiée, les attaquants usurpent anything.yourcompany.com.
Aucune surveillance externe : DMARC n’est pas un dispositif « on l’installe et on l’oublie » quand les outils changent.

En bref : DMARC est la couche d’application qui transforme SPF/DKIM de simples « signaux » en véritable « protection ».

Ce que font réellement les attaquants quand l’authentification e-mail est faible

Voici les principales voies d’abus à fort impact que SPF/DKIM/DMARC aident à empêcher :

1) Fraude au président / détournement de facture (BEC)

Les attaquants envoient des e-mails qui semblent provenir de la direction ou du service financier pour modifier des IBAN, valider des paiements ou demander des cartes-cadeaux. Un seul faux succès peut coûter plus qu’une année d’outillage de sécurité.

2) Collecte d’identifiants

Un e-mail très crédible « de l’IT » pousse vers une fausse page de connexion Microsoft 365. Dès que les identifiants sont capturés, l’attaquant peut rebondir vers les véritables boîtes internes et envoyer un phishing légitime depuis votre tenant.

3) Usurpation de marque auprès des clients/partenaires

Même si votre équipe interne est formée, vos clients ne le sont pas. Des messages usurpés peuvent ternir votre réputation, déclencher des fraudes et créer des cauchemars de support.

Les permutations de domaine : le multiplicateur des domaines ressemblants

Même avec une application DMARC parfaite, les attaquants peuvent simplement enregistrer un autre domaine qui ressemble au vôtre et envoyer depuis celui-ci.

Exemples :

examp1e.com (1 à la place de l)
exarnple.com (rn à la place de m)
example-support.com
example.com-security.net
exämple.com (astuces IDN / homographes)
Autre TLD : example.co, example.net, example.io

On appelle cela la permutation de domaine / typosquatting (cela inclut aussi les attaques par homographe, combo-squatting, bitsquatting, et plus encore).

Pourquoi les permutations sont dangereuses

Les utilisateurs lisent des formes, pas des chaînes : un coup d’œil rapide à une adresse d’expéditeur n’est pas fiable.
Les clients mobiles cachent les détails : beaucoup d’interfaces réduisent ou tronquent les informations d’expédition.
SPF/DKIM/DMARC n’y peuvent rien : ils protègent votre domaine, pas les ressemblants.
Les attaquants peuvent bâtir une infrastructure “plausible” : certificats TLS, pages d’atterrissage brandées, flux de réponse réalistes.

Flux d’attaque typique avec un domaine ressemblant

Enregistrer un domaine proche du vôtre.
Mettre en place SPF/DKIM/DMARC correctement (oui, les attaquants le font).
Envoyer des messages “urgents” au service financier, aux RH, aux clients ou aux fournisseurs.
Récupérer des identifiants ou détourner des paiements.
Si une réponse arrive, entretenir la conversation (style détournement de fil).

À retenir : il vous faut à la fois une surveillance de l’authentification et une détection des domaines ressemblants.

À quoi ressemble une bonne configuration : un socle pratique

Si vous voulez une posture propre et moderne :

SPF

Un seul enregistrement TXT SPF par domaine.
N’inclure que les expéditeurs que vous utilisez réellement.
Terminer par -all une fois toutes les sources validées.

DKIM

S’assurer que chaque plateforme d’envoi signe les messages.
Faire tourner les clés régulièrement.
Utiliser des clés suffisamment robustes (et ne pas les réutiliser indéfiniment).

DMARC

Commencer brièvement par p=none pour observer les expéditeurs légitimes.
Passer à p=quarantine, puis à p=reject.
Utiliser un alignement strict lorsque c’est possible (aspf=s; adkim=s).
Envisager une politique pour les sous-domaines (sp=) afin d’éviter les failles de contournement.

Permutations de domaine

Surveiller les ressemblances sur les TLD courants et les fautes de frappe évidentes.
Prioriser celles qui :
- ont des enregistrements MX (peuvent envoyer/recevoir des e-mails),
- hébergent des pages de phishing,
- sont nouvellement enregistrées,
- ressemblent à la marque + “billing / login / support”.

Pourquoi la surveillance continue compte, même si vous avez “tout configuré une fois”

Les changements DNS surviennent pour des raisons banales — migrations, changement de fournisseur, “petites corrections”, domaines expirés — et ces changements anodins peuvent casser l’authentification en silence.

La surveillance continue détecte :

les explosions de requêtes SPF après l’ajout d’un nouvel outil
les sélecteurs DKIM supprimés ou mal tournés
le DMARC rétrogradé à p=none
un domaine ressemblant qui apparaît soudainement et commence à écrire à vos employés

C’est pourquoi AutoPhish inclut désormais un Email Security / DNS Scanner pour des vérifications rapides, ainsi qu’une surveillance continue avec alertes pour les organisations connectées.

Liste de contrôle rapide à copier dans votre runbook interne

SPF existe, est unique et se termine par -all (après validation)
Toutes les sources d’envoi sont prises en compte (M365/Google + marketing + support + transactionnel)
DKIM activé sur toutes les sources, clés non périmées
DMARC existe avec reporting activé
DMARC appliqué (quarantine ou reject) avec alignement configuré
Sous-domaines couverts (sp= ou DMARC explicite sur les sous-domaines)
Surveillance des domaines ressemblants activée (typos + changements de TLD + combos)
Alerting relié à un vrai canal (e-mail/Slack/Teams/ticketing)

Vérifiez votre domaine en quelques secondes (gratuitement)

Vous voulez un contrôle rapide tout de suite ? Utilisez le AutoPhish DNS Checker pour analyser instantanément vos enregistrements SPF, DKIM et DMARC :

AutoPhish DNS Checker: https://autophish.io/dns-check

Si vous voulez une protection continue, vous pouvez aussi mettre en place une surveillance continue avec un abonnement AutoPhish — ainsi, vous recevrez des alertes lorsque les enregistrements DNS changent ou lorsqu’un domaine ressemblant est détecté.

Dernières réflexions

L’authentification e-mail (SPF/DKIM/DMARC) est l’une des rares mesures de sécurité qui améliore à la fois la protection et la délivrabilité. Ajoutez la surveillance des domaines ressemblants, et vous couvrez les deux plus grands vecteurs d’usurpation : faire passer votre domaine pour un autre et faire passer votre marque pour une autre.

SPF, DKIM, DMARC et permutations de domaine : les fondamentaux de la sécurité des e-mails que les attaquants exploitent