- Accueil
- Solutions
- Pourquoi Klytic
- Guides
- Tarifs
- Partenaires
- Contact
-
-
Accueil›Guides›Sécurité des e-mails
Sécurité des e-mails · Comprendre
SPF dit quels serveurs peuvent envoyer pour un domaine, DKIM signe le message, DMARC vérifie que l’un des deux correspond au domaine affiché dans « De » et dit quoi faire en cas d’échec. Ensemble, ils empêchent un inconnu d’utiliser exactement votre domaine. Ils ne lisent pas le texte : un domaine cousin, un nom d’affichage trompeur ou un compte compromis passent.
La RFC 7208 part d’un constat : rien, dans le protocole de messagerie, n’empêche un serveur d’annoncer n’importe quelle adresse d’expédition. SPF permet au propriétaire d’un domaine de publier dans le DNS la liste des serveurs autorisés à envoyer en son nom, et au serveur qui reçoit de vérifier cette autorisation.
Deux précisions changent tout :
Un domaine ne publie qu’un seul enregistrement SPF. Toutes les sources d’envoi y figurent : messagerie, logiciel de facturation, outil de newsletter, CRM, copieur qui numérise vers le mail.
Selon la RFC 6376, DKIM permet au propriétaire d’un domaine signataire de revendiquer une part de responsabilité dans un message, au moyen d’une signature cryptographique. La clé publique est dans le DNS. Vérifier la signature établit que les parties signées n’ont pas changé depuis la signature.
La signature voyage avec le message. Elle survit donc mieux qu’SPF à un relais ou à un transfert, tant que ce relais ne modifie pas le sujet ou le corps. Une liste de diffusion qui ajoute une mention en bas du message la casse.
Ce que DKIM ne fait pas, d’après la même RFC : il ne chiffre pas le message, un échec n’impose pas de le rejeter, et le domaine qui signe n’a pas à être celui qui est affiché dans « De ». C’est précisément le trou que DMARC comble.
La RFC 7489 définit DMARC comme un moyen, pour le propriétaire d’un domaine, d’exprimer une politique au niveau du domaine. Le mécanisme repose sur l’alignement : le domaine de l’adresse affichée dans « De » doit correspondre au domaine validé par SPF ou par DKIM. Si ni l’un ni l’autre n’est aligné, DMARC échoue.
Le domaine publie alors ce qu’il souhaite :
DMARC prévoit aussi des rapports : des rapports agrégés, qui résument quels serveurs ont envoyé au nom du domaine et avec quel résultat, et des rapports d’échec, message par message. Ce sont eux qui permettent de découvrir un outil oublié qui envoie pour vous, ou quelqu’un qui usurpe votre domaine.
| Mécanisme | Ce qu’il vérifie | Ce qu’il ne regarde pas |
|---|---|---|
| SPF | Le serveur qui remet le message est autorisé pour le domaine d’enveloppe | L’adresse affichée, le contenu |
| DKIM | Le message signé n’a pas été modifié ; un domaine en prend la responsabilité | L’adresse affichée, l’honnêteté du contenu |
| DMARC | Le domaine affiché est aligné avec SPF ou DKIM ; politique en cas d’échec | Les domaines ressemblants, le nom d’affichage, le texte |
Il bloque une partie de l’usurpation du domaine, pas le phishing en général. La RFC 7489 le dit explicitement : DMARC ne traite pas les noms de domaine visuellement proches, ni l’abus du nom d’affichage, et l’analyse du contenu sort de son périmètre. Il ne cherche pas à résoudre tous les problèmes du courrier frauduleux.
Concrètement, DMARC ne voit pas :
Ces cas relèvent d’autres analyses : ressemblance des domaines, réputation, contenu, comportement. Voir spam, phishing, malware et compte compromis.
Un transfert casse souvent SPF, une liste qui modifie le message casse DKIM, et DMARC échoue alors sur un message légitime. ARC, décrit dans la RFC 8617 (statut expérimental), permet à chaque intermédiaire d’attester le résultat d’authentification qu’il a constaté. Le serveur final peut choisir d’en tenir compte.
Ce sont deux sujets que l’on confond souvent.
Exemple, à titre d’illustration. Un cabinet publie DMARC en « none » et lit ses premiers rapports. Il y découvre trois sources : sa messagerie, bien alignée ; son logiciel de facturation, qui envoie les factures avec le domaine du cabinet sans signature DKIM ; et un serveur inconnu à l’étranger qui envoie des centaines de messages à son nom. Il corrige le logiciel de facturation, attend un cycle de rapports propre, puis passe en « quarantine » : les destinataires qui appliquent DMARC traitent désormais les messages du serveur inconnu comme suspects.
Le jour où l’on change de messagerie, ces enregistrements se préparent avant le changement de MX. Le guide migrer une messagerie sans interruption décrit ce moment ; il n’est pas repris ici.
Non. Elle permet d’observer grâce aux rapports. La protection commence avec « quarantine » ou « reject ».
Le plus souvent : un transfert, une liste de diffusion, ou un service qui envoie pour vous sans être déclaré dans SPF ni signer en DKIM.
Une passerelle placée sur le trajet des envois peut signer à sa place. Voir Protéger la messagerie que vous avez déjà.
Dans les en-têtes du message. Pour Klytic MTA, voir Lire et exporter une décision du filtre.
Klytic MTA traite les deux sujets, devant n’importe quelle messagerie :
DMARC n’est qu’une couche : Klytic MTA ajoute la détection des domaines sosies, du nom d’affichage et des scénarios de fraude, décrite dans usurpation et fraude au président.
Si vous utilisez Klytic Mail, SPF, DKIM et DMARC sont configurés pour votre domaine : c’est la protection du domaine qui envoie. Klytic MTA, lui, se souscrit avec ou sans Klytic Mail.
Consultées en octobre 2026.
Klytic MTA vérifie SPF, DKIM et DMARC à l’arrivée et signe vos envois.
Offre de bienvenue
Offre d'essai sans engagement. Un conseiller vous rappelle pour comprendre vos besoins et préparer votre espace Klytic.
