Un pirate peut expédier un message qui semble venir de votre propre boîte : une tactique de chantage visant à obtenir de l’argent ou à installer la peur. Comprenez comment il contourne SPF, DKIM et DMARC, puis déployez les bonnes défenses pour neutraliser cette usurpation.
Vue d’ensemble : pourquoi recevez‑vous un e‑mail « de vous‑même » ?
Le protocole SMTP, mis au point en 1982, a longtemps privilégié l’ouverture et l’interopérabilité. Résultat : le champ From: n’est pas vérifié par défaut. Les contrôles modernes (SPF, DKIM, DMARC, MTA‑STS, BIMI, ARC) ajoutent des garde‑fous, mais ils reposent sur des enregistrements DNS et des politiques optionnelles. Tant qu’un domaine n’a pas explicitement demandé le rejet, les passerelles de messagerie se contentent le plus souvent de classer le message comme indésirable au lieu de le bloquer.
Comment fonctionne l’usurpation d’adresse ?
- Relais SMTP contrôlé par l’attaquant : il configure son propre serveur, définit
MAIL FROM:etFrom:sur votre adresse, puis expédie. - Script d’injection SMTP : via Telnet ou Netcat, il tape les commandes SMTP à la main, ce qui lui donne un contrôle total sur les en‑têtes.
- Services de spam en masse : certains services peu scrupuleux proposent des interfaces web où l’on peut saisir n’importe quelle adresse expéditrice.
Exemple de session SMTP falsifiée
EHLO spoofer.example MAIL FROM:<vous@example.com> RCPT TO:<vous@example.com> DATA From: vous@example.com To: vous@example.com Subject: J’ai piraté votre compte ! …corps du message… . QUIT
Mécanismes d’authentification : SPF, DKIM et DMARC en détail
| Contrôle | Objectif | Principe technique | Limites |
|---|---|---|---|
| SPF | Valider que l’IP émettrice est autorisée à envoyer pour le domaine figurant dans MAIL FROM:. | Le serveur destinataire interroge le DNS TXT « v=spf1 ». S’il ne trouve pas l’IP, il renvoie fail. Des qualificatifs comme ~all, -all, +all précisent la sévérité. | Ne protège pas le champ From:. Un attaquant peut placer une adresse différente dans MAIL FROM: (utilisé pour SPF) que dans From: (affiché à l’utilisateur). |
| DKIM | Garantir l’intégrité et l’authenticité du contenu. | Une signature cryptographique est insérée dans l’en‑tête DKIM-Signature:. La clé publique est publiée dans le DNS (selector._domainkey.domaine). | Optionnel ; si le domaine n’a pas publié de clé, aucune vérification n’est possible. |
| DMARC | Aligner From: avec SPF ou DKIM et dicter la réaction du serveur récepteur (none, quarantine, reject). | En‑tête TXT _dmarc.domaine indiquant la politique p=, la taille des sous‑domaines (sp=), et l’adresse de rapport (rua=, ruf=). | Si la politique est p=none, le message échoue mais n’est pas bloqué ; la décision finale revient toujours au serveur du destinataire. |
Diagramme de validation dans un flux réel
- L’attaquant envoie l’e‑mail via
smtp.spammer.test. - Le serveur MX du destinataire reçoit l’IP
203.0.113.55. - SPF interroge
domaine-victime.com: l’IP n’est pas listée → fail. - Pas de signature DKIM → fail.
- DMARC constate double échec + politique
p=none→ le message est livré en spam.
Pourquoi le message arrive quand même ?
Trois raisons principales :
- Politique laxiste du domaine falsifié : beaucoup de domaines institutionnels laissent encore
p=nonepour surveiller sans bloquer. - Stratégie des grandes plateformes : Gmail, Outlook.com et consorts évitent de rejeter pour limiter les faux positifs. Le courriel est mis en quarantaine, pas supprimé.
- Pondération antispam globale : SPF ou DKIM à eux seuls ne suffisent pas. Les filtres analysent aussi le contenu, les URLs, la réputation d’IP… Un score passe ou casse détermine la livraison.
Éplucher manuellement les en‑têtes pour confirmer l’usurpation
Dans Outlook : Fichier → Informations → Propriétés → En‑têtes Internet. Dans Gmail : menu ⋮ Afficher l’original.
Authentication-Results: spf=fail (domain does not designate 203.0.113.55)
dkim=none
dmarc=fail (p=none)
Received: from spoofer.example (203.0.113.55)
From: vous@example.com
Return-Path: <hacker@malware.site>
Défense côté propriété de domaine
1 • Consolider SPF
- Limiter aux IP et services réellement nécessaires (
include:ciblés). - Terminer par
-all(rejet) ou, phase transitoire,~all(softfail). - Vérifier la longueur : 255 caractères maximum par entrée DNS, 10 lookups autorisés.
2 • Activer DKIM robuste
- Deux sélecteurs minimum (rotation semestrielle).
- Clé RSA 2048 bits ou Ed25519.
- Signer
From:,Subject:,Date:,Message-ID:et le corps (bh=).
3 • Déployer DMARC en trois paliers
v=DMARC1; p=none; rua=mailto:dmarc@votre‑domaine.com- Après 30 jours d’observation, passer à
p=quarantine; pct=50 - Quand plus aucun faux positif n’apparaît →
p=reject; adkim=s; aspf=s
Les rapports RUA (agrégés) et RUF (forensic) offrent une visibilité précieuse sur les sources légitimes et malveillantes.
4 • Compléments modernes
- MTA‑STS : impose TLS durant le transport pour empêcher le downgrade attack.
- TLS‑RPT : reçoit les rapports de TLS échoués.
- ARC : conserve les signes d’authentification à travers des sauts (listes de diffusion).
- BIMI : affiche votre logo validé ; renforce la confiance visuelle.
Défense côté utilisateur / administrateur
| Geste concret | Bénéfice |
|---|---|
| Activer la MFA sur toutes les boîtes. | Empêche l’attaquant de se connecter réellement, même s’il connaît le mot de passe. |
| Signaler systématiquement comme hameçonnage. | Entraîne les filtres antispam, accélère la rétroaction. |
| Mettre à jour le client de messagerie. | Les moteurs antiphishing internes se perfectionnent à chaque version. |
| Désactiver l’affichage automatique des images distantes. | Évite les balises de suivi (tracking pixels). |
| Sensibiliser les équipes (table rase des mythes). | La composante humaine reste la faille n°1 ; une simulation de phishing trimestrielle réduit le taux de clics malveillants. |
Tutoriel rapide : vérifier vos enregistrements DNS
- Ouvrez un terminal et tapez :
nslookup -type=txt exemple.com - Cherchez la ligne SPF :
"v=spf1 include:spf.protection.outlook.com -all" - Pour DKIM :
nslookup -type=txt selector1._domainkey.exemple.com - Pour DMARC :
nslookup -type=txt _dmarc.exemple.com - Analysez le résultat avec un validateur DMARC hors‑ligne.
Cas pratique : ce qu’il se passe chez Outlook.com
Outlook.com signe ses messages avec selector1‑outlook.com. Un extorqueur ne détient pas la clé privée ; absence de DKIM + SPF fail = score antispam négatif. Vous recevez néanmoins le message (généralement en indésirable) car @outlook.com est réglé sur p=none : Microsoft préfère la quarantaine au rejet pour des centaines de millions d’utilisateurs.
Limites structurelles & avenir de la messagerie
Les proposants du protocole SMTP travaillent sur des correctifs incrémentaux plutôt qu’un remplacement complet, car des milliards de serveurs et d’appareils dépendent du fonctionnement actuel. Les initiatives comme « SMTP Strict Transport Security », « DNSSEC‑chain » ou encore « Authenticated Received Chain » visent à renforcer la confiance sans casser la compatibilité ascendente. D’ici là, la meilleure approche reste un combo :
- Authentification forte côté domaine ;
- Formation et vigilance côté humain ;
- Signalement systématique pour nourrir l’IA antispam.
Checklist récapitulative
- ✅ SPF publié avec
-all - ✅ DKIM activé, clé 2048 bits min.
- ✅ DMARC en
p=rejectaligné strict. - ✅ MTA‑STS & TLS‑RPT configurés.
- ✅ Supervision continue via rapports DMARC + journaux MX.
- ✅ Campagnes de sensibilisation trimestrielles.
Conclusion
L’affichage de votre propre adresse dans la case « Expéditeur » n’est donc pas la preuve d’un piratage de votre compte : c’est un artefact de la conception historique de l’e‑mail. En revanche, une politique DMARC rigoureuse, alliée à la signature DKIM et à un SPF strict, élimine l’immense majorité des usurpations. Complétez‑la par la surveillance TLS, l’activation de BIMI pour rassurer vos correspondants et une éducation continue des utilisateurs. Vous transformerez alors un vecteur d’attaque sournois en simple anecdote placée dans le dossier « Courrier indésirable ».