Defaults.Exposed › Corrections › Guides
Quelqu'un envoie des e-mails depuis votre domaine : le guide de réponse d'urgence (2026)
Publié 2026-07-08
Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.
Vérifiez d’abord si les faux e-mails utilisent votre domaine exact ou un domaine sosie, car les correctifs sont complètement différents. L’usurpation du domaine exact peut être coupée dans le DNS — et la plupart des domaines ne l’ont pas fait : 89,41 % n’ont aucune politique DMARC appliquée, et 46,4 % ne publient aucun SPF, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines évalués.
Ceci est une checklist d’incident : première heure — confirmer ce qui se passe sans aggraver la situation ; premier jour — fermer la porte ouverte, ou lancer le retrait si la porte n’est pas la vôtre ; première semaine — surveiller, prévenir les personnes qui risquent de se faire piéger, appliquer la politique. Vous vous demandez seulement si cela pourrait arriver ? Commencez par quelqu’un peut-il usurper mon domaine ? — cette page est pour le cas où c’est déjà en cours.
D’abord : est-ce vraiment votre domaine, ou une imitation ?
Procurez-vous l’un des faux e-mails et lisez l’adresse de l’expéditeur caractère par caractère. Tout ce qui suit en dépend :
| Ce que montre l’adresse From | Ce qui se passe | Votre piste |
|---|---|---|
[email protected] — votre domaine, orthographié exactement | Usurpation : le serveur d’un inconnu forge votre domaine dans la ligne From. Vos systèmes ne sont PAS piratés. | Correctif DNS — SPF, DKIM, DMARC appliqué. Piste 1. |
[email protected], yourcompany-billing.com, yourcompany.co — proche, mais pas le vôtre | Un domaine sosie enregistré par quelqu’un d’autre. Votre DNS n’est jamais consulté. | Retrait + avertissements. Piste 2. |
| Votre adresse exacte, et les messages figurent dans votre propre dossier Envoyés ou répondent à de vrais fils | Compromission de compte — quelqu’un est à l’intérieur d’une vraie boîte aux lettres. Un incident différent. | Changez le mot de passe, révoquez les sessions, activez la double authentification, vérifiez les règles de transfert — avant toute autre chose. |
Données au 2026-06-29.
La ligne en gras est le cas le plus fréquent et le plus corrigeable. Le protocole de base de l’e-mail n’a jamais vérifié la ligne From — n’importe qui peut y taper votre domaine — le correctif consiste donc à publier des enregistrements DNS qui permettent aux serveurs de réception de vérifier par eux-mêmes. Les chiffres inconfortables du recensement : 121 145 609 des 261 086 232 domaines évalués (46,4 %) ne publient aucun enregistrement SPF, et 36 014 des 138 927 207 domaines qui en publient un le terminent par +all — autorisant littéralement Internet entier à envoyer en leur nom (données au 2026-06-29).
La première heure : confirmez, ne réagissez pas
- Lancez le scan gratuit sur defaults.exposed. Trente secondes, sans inscription. Il vous dit si votre domaine est actuellement usurpable — SPF présent et strict ou non, DMARC appliqué ou non — avant de toucher au DNS.
- Ne répondez pas au faux, ne cliquez sur rien dedans, et n’envoyez pas encore de message en masse à vos contacts. Un e-mail paniqué « ignorez les e-mails venant de chez nous ! » envoyé depuis le même domaine ressemble exactement à l’arnaque. Les avertissements viennent plus tard, ciblés et par un autre canal.
- Récupérez un échantillon complet avec ses en-têtes intégraux. Demandez à un destinataire de transférer le faux en pièce jointe (Gmail : « Show original » → télécharger ; Outlook : « View message source »). Une capture d’écran de la ligne From ne suffit pas — les en-têtes sont la preuve pour tout ce qui suit.
- Lisez le verdict que le serveur de réception a déjà rendu. Dans les en-têtes, trouvez
Authentication-Results:—dmarc=failsur votre domaine exact confirme l’usurpation de votre domaine ; un sosie dansheader.from=confirme la piste 2. Une subtilité : les serveurs de réception évaluent SPF sur le domaine du Return-Path (le RFC5321.MailFrom, l’adresse de rebond), pas sur l’en-tête From que voit votre destinataire — un e-mail usurpé peut même afficherspf=passpour le domaine du spammeur tout en forgeant le vôtre dans From. Le contrôle d’alignement de DMARC comble exactement cette faille.
Piste 1 — c’est votre domaine exact : le premier jour
Usurper votre domaine exact ne fonctionne que tant que votre DNS ne dit rien qui permette aux serveurs de réception de rejeter les faux. Aujourd’hui, vous publiez (ou resserrez) les trois enregistrements ; l’application suit au fil de la semaine.
- SPF : publiez un seul enregistrement listant vos vrais expéditeurs, terminé par
-all(« tous les autres : échec »). Si le vôtre se termine par+allou?all, corrigez cela en premier — c’est une porte ouverte que vous avez publiée vous-même. Pas à pas : comment corriger SPF, les clics par prestataire dans SPF chez GoDaddy. - DKIM : activez la signature de domaine chez votre prestataire de messagerie et dans tout outil de newsletter ou de facturation (généralement quelques enregistrements CNAME chacun).
- DMARC : publiez
v=DMARC1; p=none; rua=mailto:...dès aujourd’hui pour que les rapports commencent à arriver ;p=rejectest le projet de la semaine, pas de l’heure — référence complète dans comment corriger DMARC. Si le domaine n’envoie aucun e-mail légitime — une ancienne marque, un domaine en attente — sautez les précautions et verrouillez-le aujourd’hui : ce vieux domaine de votre changement de marque est une porte laissée ouverte.
La réserve honnête, avant de vous détendre : une politique DMARC appliquée dit aux serveurs de réception de mettre en indésirable ou de rejeter les faux au domaine exact — et les grands prestataires la respectent. Mais elle n’engage que les serveurs de réception qui la vérifient, et elle ne fait strictement rien contre les domaines sosies : dès que les escrocs ne peuvent plus envoyer en tant que yourcompany.com, enregistrer yourcompany-billing.com coûte quelques euros. DMARC réduit l’attaque ; il ne clôt pas l’histoire — les étapes de la première semaine comptent pour vous aussi.
Piste 2 — c’est un domaine sosie : ce n’est pas un correctif DNS
Aucun enregistrement publié sur votre domaine n’affecte le courrier d’un domaine que vous ne possédez pas — rien dans votre DNS n’est même consulté. Le plan d’action, c’est retrait plus avertissements :
- Trouvez qui est derrière le sosie. Cherchez-le dans RDAP/WHOIS (par ex.
lookup.icann.org) pour obtenir son registrar, et vérifiez s’il héberge un site web. - Signalez-le au contact abuse du registrar avec votre échantillon à en-têtes complets en pièce jointe — les registrars suspendent des domaines d’hameçonnage tous les jours ; des preuves claires accélèrent tout. Un site d’hameçonnage ? Signalez-le aussi à l’hébergeur, à Google Safe Browsing et à Microsoft SmartScreen.
- Signalez les e-mails comme hameçonnage dans les boîtes de réception (Gmail/Outlook « Report phishing ») — cela entraîne les grands filtres contre le sosie plus vite que n’importe quel courrier.
- Prévenez les cibles probables par un autre canal — l’étape qui empêche réellement l’argent de partir. Appelez ou envoyez un message (pas seulement un e-mail) à vos clients, fournisseurs et à votre comptable : nommez le faux domaine, et rendez tout changement de coordonnées bancaires « de votre part » vérifiable par téléphone. Cette habitude est la meilleure défense contre l’histoire de fraude à la facture qu’on vous a racontée.
- Si le sosie abuse de votre marque, une plainte UDRP peut faire transférer le domaine — plus lent qu’un retrait, mais définitif.
Et suivez quand même la piste 1 : les attaquants s’embarrassent rarement d’un sosie tant que le vrai domaine reste ouvert, et 89,41 % des domaines n’ont aucun DMARC appliqué (seuls 27 640 987 sur 261 086 232 — 10,59 % — l’ont, au 2026-06-29). Fermez votre propre porte dans tous les cas.
La première semaine : surveillez, prévenez, appliquez
- Lisez vos rapports DMARC. Un jour ou deux après la mise en ligne du tag
rua=, les rapports agrégés montrent chaque serveur qui envoie en tant que votre domaine — vos vrais serveurs et l’usurpateur, avec volumes et verdicts. C’est ainsi que vous regardez l’attaque mourir. - Confirmez que vos expéditeurs légitimes passent. Chaque vraie source (prestataire de messagerie, outil de newsletter, application de facturation, formulaire de contact du site) doit passer SPF ou DKIM aligné sur votre domaine avant l’application — sinon le rejet bloque aussi votre propre courrier.
- Passez DMARC à
p=quarantine, puisp=reject. Sous usurpation active, vous compressez les mois habituels en une semaine ou deux — mais vous compressez les étapes, vous ne les sautez pas. Le déploiement par paliers, la montée enpctet la politique de sous-domaines : de p=none à p=reject sans perdre d’e-mails légitimes. - Envoyez un avis calme et ciblé aux interlocuteurs qui ont pu recevoir des faux : ce qui s’est passé, ce que le faux demandait, la règle de vérification par téléphone pour tout changement de paiement, et (piste 2) le domaine sosie exact à bloquer.
- Relancez le scan et conservez le rapport. Assureurs et clients demandent de plus en plus ce que vous avez fait pour la sécurité de votre e-mail ; un rapport daté et noté répond par écrit.
Questions fréquentes
J’ai reçu un e-mail frauduleux venant de ma propre adresse. Ai-je été piraté ? Presque toujours non — le courrier d’extorsion « de vous, vers vous » est le même tour de passe-passe, exploitant le fait que votre domaine ne rejette pas les faux. Vérifiez votre dossier Envoyés et vos connexions récentes ; si tout est propre, c’est de l’usurpation, et une politique DMARC appliquée arrête cette variante chez les serveurs de réception qui la respectent. Au 2026-06-29, 89,41 % des 261 086 232 domaines évalués ne l’ont pas fait.
DMARC arrêtera-t-il les e-mails venant du domaine sosie ? Non. Votre politique DMARC ne gouverne que votre domaine exact (et ses sous-domaines) — un sosie est le domaine de quelqu’un d’autre avec son propre DNS, jamais confronté à vos enregistrements. Les sosies se combattent avec des signalements abuse au registrar, des signalements d’hameçonnage et des avertissements à vos interlocuteurs, pas avec le DNS.
En combien de temps p=reject arrêtera-t-il vraiment l’usurpation ? Les changements DNS atteignent les serveurs de réception en quelques heures, et Gmail, Outlook et la plupart des grands prestataires appliquent les verdicts DMARC — les faux au domaine exact commencent à mourir le jour où la politique est en place. Deux limites honnêtes : les petits serveurs de réception qui ne vérifient jamais DMARC peuvent encore livrer des faux, et appliquer la politique avant que vos propres expéditeurs soient alignés bloque votre courrier légitime — accélérez les étapes, ne les sautez pas.
Envoyez le rapport au propriétaire
Si vous êtes le prestataire informatique qui gère l’incident : une fois les enregistrements en ligne, relancez le scan et transmettez le rapport noté au chef d’entreprise. Il montre, en langage clair, ce qui a permis l’usurpation, ce que vous avez changé et où en est le domaine désormais — la réponse écrite à « sommes-nous en sécurité maintenant ? », et la preuve pour le renouvellement d’assurance ou le questionnaire client. Si vous êtes le propriétaire : demandez exactement ce rapport, et conservez l’avant et l’après.
Vérifiez gratuitement si votre domaine est usurpable
Voyez si le serveur d’un inconnu peut actuellement se faire passer pour vous — et exactement quoi corriger — en privé, visible du propriétaire uniquement.
Vérifiez votre domaine → · De p=none à p=reject → · Corriger DMARC → · Quelqu’un peut-il usurper mon domaine ? → · Données agrégées uniquement. Données stockées et traitées dans l’UE.