mlab Academy
EN
Sécuriser son domaine

SPF, DKIM et DMARC pour votre domaine

Empêcher un attaquant d'envoyer des emails en votre nom : le rôle de SPF, DKIM et DMARC, lire un résultat de scan et atteindre p=reject sans casse.

1 Introduction

L'email a été conçu dans les années 1980 sur la confiance : l'adresse From d'un message n'est que du texte, et n'importe qui peut y écrire [email protected], exactement comme on peut écrire n'importe quel expéditeur au dos d'une enveloppe. C'est le ressort de la plupart des usurpations d'email et des fraudes au faux fournisseur.

Trois enregistrements DNS vous permettent, en tant que propriétaire du domaine, d'indiquer à tous les serveurs de réception comment reconnaître vos vrais emails : SPF liste les serveurs autorisés à envoyer pour vous, DKIM signe vos messages, et DMARC relie les deux à l'adresse From visible et dit quoi faire des messages qui échouent. Quand un scan de domaine signale votre authentification email, c'est de cette protection qu'il parle.

3

Enregistrements DNS (SPF, DKIM, DMARC) qui décident si votre domaine peut être usurpé

2024

Gmail et Yahoo exigent SPF, DKIM et DMARC des expéditeurs en masse

10

Requêtes DNS maximum qu'un SPF peut déclencher avant de casser (RFC 7208)

2 Comment ça marche

Quand un message qui prétend venir de votre domaine arrive, le serveur de réception (Gmail, Outlook, une passerelle d'entreprise) fait trois vérifications, toutes en lisant des enregistrements DNS publics que vous publiez. Rien à installer côté destinataire : publier les enregistrements suffit.

1

SPF

L'IP qui a livré ce message fait-elle partie des expéditeurs publiés par le domaine ?

2

DKIM

La signature cryptographique des en-têtes se vérifie-t-elle avec la clé publique du DNS, preuve que le message n'a pas été modifié ?

3

DMARC

SPF ou DKIM a-t-il réussi pour le domaine affiché dans From ? Sinon, appliquer la politique du propriétaire : livrer, mettre en quarantaine ou rejeter.

Pourquoi DMARC est le plus important

Seuls, SPF et DKIM valident un domaine, pas forcément le vôtre : SPF contrôle l'expéditeur d'enveloppe caché (Return-Path), DKIM le domaine qui a signé. Un attaquant peut réussir les deux avec son propre domaine tout en affichant le vôtre dans le From. DMARC comble ce trou avec l'alignement : le domaine validé par SPF ou DKIM doit correspondre au domaine du From. Sans politique DMARC qui agit (quarantine ou reject), chaque destinataire décide seul, et les faux emails arrivent souvent en boîte de réception.

3 Analyse détaillée

SPF : qui a le droit d'envoyer

Un seul enregistrement TXT, sur le domaine lui-même :

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

La fin : -all, ~all, ?all, +all

-all signifie « personne d'autre » (échec franc), ~all « probablement pas » (échec léger, suffisant si DMARC applique une politique). ?all ne dit rien, et +all autorise tout internet : un scan le classe à juste titre en sévérité haute.

Un seul enregistrement SPF

Deux TXT commençant par v=spf1 provoquent une erreur permanente, que les destinataires traitent comme un échec. Fusionnez-les.

La limite des 10 requêtes

Chaque include:, a, mx et redirect coûte une requête DNS, includes imbriqués compris. Au-delà de dix, SPF casse pour tout le monde. Retirez les fournisseurs que vous n'utilisez plus plutôt que d'« aplatir » votre SPF.

DKIM : la preuve que le message vient de vous

Votre fournisseur signe chaque message sortant avec une clé privée ; la clé publique est publiée sous un sélecteur : 

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

« Aucun DKIM trouvé » ne veut pas toujours dire pas de DKIM

Le DNS ne permet pas de lister les sélecteurs : un scanner essaie les plus courants (google, selector1, selector2, k1, default...). Un sélecteur personnalisé est invisible de l'extérieur. Pour en avoir le cœur net, ouvrez un email que vous avez envoyé et cherchez DKIM-Signature: ... d=example.com; s=<sélecteur> dans ses en-têtes.

Longueur de clé

Utilisez des clés RSA de 2048 bits. Les clés de 1024 bits passent encore mais sont jugées faibles : faites la rotation depuis la console de votre fournisseur.

À activer pour chaque expéditeur

Votre CRM, votre outil de newsletter et votre helpdesk envoient aussi en votre nom. Chacun doit signer avec votre domaine (d=example.com), en général via un CNAME ou un TXT qu'il vous fournit.

DMARC : la politique

Un enregistrement TXT sur _dmarc. devant votre domaine :

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

p=none : de la surveillance, pas de la protection

Les destinataires vous envoient des rapports mais livrent les faux emails comme d'habitude. C'est la bonne première étape, et le mauvais endroit où rester : un scan le signale parce que le domaine reste usurpable.

p=quarantine et p=reject

Quarantine envoie les messages en échec dans les spams, reject les refuse. Les deux comptent comme une politique appliquée. sp= fixe la politique des sous-domaines (elle hérite de p= si absente), et pct= n'applique la politique qu'à une partie du trafic pendant la montée en charge.

rua= : votre visibilité

Les rapports agrégés (XML, quotidiens) listent chaque IP qui envoie en votre nom et si elle a réussi. Sans eux, vous appliquez une politique à l'aveugle. Envoyez-les vers une boîte dédiée ou un outil d'analyse DMARC gratuit.

Passer à p=reject sans perdre d'emails

1

Publiez SPF et activez DKIM chez votre fournisseur principal. Publiez p=none avec une adresse rua=.

2

Lisez deux à quatre semaines de rapports. Chaque source légitime en échec (newsletter, facturation, ticketing) voit son SPF ou son DKIM corrigé. Les sources inconnues sont des outils oubliés, ou de l'usurpation.

3

Passez en p=quarantine (éventuellement avec pct=25, puis 100), surveillez les rapports, puis p=reject.

Les domaines qui n'envoient jamais d'email

Domaines parqués, anciennes marques et enregistrements défensifs sont des cibles de choix, justement parce que personne ne les surveille. Si un domaine ou un sous-domaine n'envoie aucun email, dites-le explicitement avec trois enregistrements : 

ancienne-marque.fr.         MX   0 .                      ; null MX (RFC 7505) : n'accepte aucun email
ancienne-marque.fr.         TXT  "v=spf1 -all"            ; aucun serveur ne peut envoyer
_dmarc.ancienne-marque.fr.  TXT  "v=DMARC1; p=reject"

La vérification « protection contre l'usurpation » d'un scan regarde exactement cela : les domaines et sous-domaines sans activité email qui se laissent encore usurper.

Microsoft 365 et Direct Send

Si votre MX pointe vers *.mail.protection.outlook.com, Exchange Online accepte du SMTP non authentifié sur cet hôte pour vos propres domaines. Cette fonction « Direct Send » existe pour les imprimantes et les scanners, et les attaquants s'en servent pour déposer du phishing d'apparence interne dans les boîtes de vos utilisateurs. Deux choses l'arrêtent : une politique DMARC appliquée, et la désactivation de la fonction si rien ne l'utilise (Set-OrganizationConfig -RejectDirectSend $true dans Exchange Online PowerShell).

Vérifiez votre domaine sur mlab.sh

Un scan de domaine lit vos enregistrements SPF, DKIM et DMARC, signale ce qui manque ou est faible, et vérifie la protection anti-usurpation de vos sous-domaines.

Scanner votre domaine sur mlab.sh

4 Red Flags

Pas de DMARC, ou p=none depuis des mois

N'importe qui peut mettre votre domaine dans un From, et les destinataires n'ont aucune consigne pour l'en empêcher. C'est la correction qui a le plus d'impact.

SPF terminé par +all ou ?all

+all autorise tous les serveurs de la planète. ?all est neutre et ne protège rien. Terminez par -all ou ~all.

Deux SPF, ou plus de 10 requêtes

Les deux font échouer SPF en erreur permanente : vos propres emails légitimes ne passent plus. Cela arrive souvent après l'ajout d'un nouveau fournisseur.

Des includes pour des fournisseurs abandonnés

Chaque include élargit la liste de ceux qui peuvent envoyer en votre nom et consomme le budget de requêtes. Retirez l'include d'un fournisseur le jour où vous le quittez.

Domaines parqués sans SPF -all ni DMARC reject

Un domaine que vous possédez sans l'utiliser pour l'email reste le vôtre aux yeux du destinataire. Verrouillez-le avec un null MX, v=spf1 -all et p=reject.

Propulsé par mlab.sh

Modules connexes

Les techniques de spoofing

Usurpation d'identité numérique : email spoofing, caller ID spoofing et domain spoofing.

Analyser un email suspect

Décortiquer les en-têtes d'email pour identifier les tentatives de phishing et de spoofing.

C'est quoi le DNS ?

L'annuaire d'Internet : comprendre comment le DNS traduit les noms de domaine en adresses IP.