Le courrier électronique est né dans un réseau de confiance. Il a ensuite dû survivre au spam, aux relais ouverts, aux vers diffusés par pièce jointe, au phishing, aux botnets et, aujourd'hui, au détournement de comptes parfaitement légitimes. Chaque génération d'attaque a ajouté une nouvelle couche de défense : filtrage, antivirus, réputation, chiffrement du transport, SPF, DKIM, DMARC, contrôle des flux sortants et validation humaine.

SPF, DKIM et DMARC ne répondent pas à la question « ce message est-il sans danger ? ». Ils répondent surtout à la question « ce domaine a-t-il autorisé cette utilisation de son nom ? ».

Ce billet prolonge l'architecture d'une boîte mail : après les protocoles et le stockage, nous entrons dans la partie dure, celle qui protège le domaine, le serveur et sa réputation.

Il constitue le volet « authentification et protections » du dossier Emailing professionnel en 2026. Les sujets liste, volume, tracking, droit et mesure restent volontairement dans leurs billets spécialisés.

Au sommaire

  1. Du réseau de confiance à l'industrie de la fraude.
  2. Les attaques que chaque protection peut — ou ne peut pas — arrêter.
  3. L'hôte intelligent et le contrôle central des messages sortants.
  4. L'antivirus, la quarantaine, la DLP et les limites du filtrage.
  5. SPF : autoriser les serveurs d'envoi.
  6. De DomainKeys à DKIM et au fameux k=rsa.
  7. DMARC et son enregistrement _dmarc.
  8. TLS, MTA-STS, DANE et DNSSEC.
  9. La différence entre un domaine authentifié et un mail certifié.
  10. Une méthode de déploiement sans casser les envois légitimes.

1978-2026 : l'attaque évolue, la défense s'empile

Le 3 mai 1978, un commercial de Digital Equipment Corporation envoie sur ARPANET un même message promotionnel à plusieurs centaines de destinataires. Il est généralement présenté comme le premier spam connu. Le réseau est encore petit, les participants sont identifiés et l'abus provoque immédiatement une réaction très négative.

SMTP est normalisé en 1982 pour faire circuler le courrier entre machines. Son objectif initial est l'interopérabilité, pas la preuve cryptographique de l'identité. Le protocole accepte ce que lui annonce l'émetteur : un nom de machine, une adresse d'enveloppe, puis des en-têtes dont le champ visible From:. L'authentification, le chiffrement et les politiques de domaine arriveront plus tard.

Période Attaque dominante Réponse construite progressivement
Années 1980 Abus encore limités dans un réseau de confiance Règles locales, journaux et administration humaine
Années 1990 Spam industriel et relais SMTP ouverts Fermeture du relais, listes de blocage, réputation d'IP et filtrage de contenu
1999-2000 Vers et macros diffusés par le carnet d'adresses Antivirus de passerelle, blocage de pièces jointes et mises à jour plus rapides
Années 2000 Phishing, usurpation de domaine et botnets SPF, DomainKeys puis DKIM, filtres bayésiens et réputation de domaine
Années 2010 Fraude au président, comptes cloud compromis, rançongiciels DMARC, MFA, sandbox, contrôle des paiements et détection d'anomalies
Années 2020 Vol de jetons, fournisseurs détournés, attaques très ciblées Défense en profondeur, contrôle sortant, moindre privilège et réponse à incident

Le changement essentiel est là : l'attaquant ne se contente plus de falsifier une adresse. Il peut enregistrer un domaine presque identique, voler une session, compromettre la boîte d'un fournisseur ou utiliser une plateforme d'envoi légitime. Dans ces situations, le message peut passer SPF, DKIM et DMARC tout en restant frauduleux.

Une protection par type d'attaque

Attaque Exemple Contrôles utiles Ce qui reste à faire
Usurpation exacte du domaine From: direction@example.com envoyé sans autorisation SPF, DKIM et DMARC alignés Surveiller les rapports et appliquer progressivement quarantine ou reject
Domaine ressemblant examp1e.com à la place de example.com Filtrage, veille de marque, sensibilisation DMARC de example.com ne contrôle pas le domaine ressemblant
Pièce jointe ou lien malveillant Archive, document macro, faux portail de connexion Antivirus, sandbox, réputation d'URL, blocage de formats Aucun moteur ne détecte toutes les menaces, surtout un contenu chiffré ou inédit
Compte légitime compromis Un salarié envoie depuis sa vraie boîte MFA, contrôle de session, limitation de débit, détection d'anomalies, filtrage sortant SPF, DKIM et DMARC peuvent tous réussir
Interception ou retrait de STARTTLS Un relais force le transport en clair MTA-STS ou DANE, supervision TLS Le chiffrement du transport ne prouve pas la bonne foi de l'expéditeur
Fraude au paiement Changement d'IBAN demandé dans un fil réel Procédure de confirmation hors e-mail La technique ne remplace pas un contrôle métier indépendant

La sécurité d'un système de messagerie est donc une chaîne. Une couche peut authentifier le domaine, une autre inspecter le contenu, une autre protéger le transport et une dernière vérifier l'action demandée.

L'hôte intelligent : un passage obligé pour le courrier sortant

Un hôte intelligent, ou smart host, est un relais SMTP central auquel les postes, applications et serveurs remettent leurs messages. Il peut être exploité en interne ou fourni par un prestataire. Son intérêt n'est pas seulement de « faire partir » le courrier : il impose un point de contrôle commun avant Internet.

flowchart LR
    A["Utilisateurs, ERP,<br>site web, scanners"] -->|"SMTP authentifié<br>ou flux interne autorisé"| B["Soumission"]
    B --> C["Identité, expéditeur autorisé,<br>quotas et règles métier"]
    C --> D["Antivirus, sandbox,<br>DLP et quarantaine"]
    D --> E["Signature DKIM"]
    E --> F["Smart host / MTA<br>file et réputation"]
    F -->|"SMTP vers les MX"| G["Internet"]
    H["Rapports DMARC,<br>rebonds et alertes"] --> C

L'ordre est important. Tout composant qui réécrit le corps ou un en-tête signé doit intervenir avant la signature DKIM. Si un antivirus ajoute ensuite un avertissement au pied du message, il peut invalider la signature que le domaine vient de produire.

Un serveur Postfix peut assurer ce relais. Dans une installation qui confie la sortie à un prestataire, le paramètre relayhost force la remise au smart host au lieu de contacter directement chaque MX :

relayhost = [smtp-relay.example.net]:587
smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

Les crochets demandent ici à Postfix de joindre précisément cet hôte sans rechercher son MX. Cet extrait ne met en place ni antivirus, ni DKIM, ni limitation de débit : il ne fait que centraliser le prochain saut. Les secrets doivent être protégés et les droits du compte de relais limités au strict nécessaire.

Ce que le relais doit contrôler

  • L'identité technique : utilisateur, application, certificat client, adresse IP interne ou jeton selon le mode de soumission.
  • L'adresse autorisée : une application de facturation ne doit pas pouvoir envoyer arbitrairement au nom de la direction.
  • Le volume : seuils par compte, application, domaine destinataire et fenêtre de temps.
  • Le contenu : malware connu, type de pièce jointe, URL, données sensibles ou secret accidentel.
  • La destination : domaines interdits, règles de souveraineté, doublons et envois massifs inattendus.
  • La traçabilité : identifiant de file, résultat des filtres, identité soumettrice, signature appliquée et réponse du serveur distant.
  • La séparation des flux : transactionnel, humain et newsletter ne doivent pas forcément partager les mêmes identifiants, limites ou domaines de rebond.

Si une application peut contourner le relais et contacter directement Internet sur le port 25, le contrôle central n'est qu'une intention. Le pare-feu doit normalement réserver cette sortie aux MTA autorisés.

Pourquoi analyser aussi les mails sortants ?

Le filtrage entrant protège les utilisateurs. Le filtrage sortant protège aussi les destinataires, le domaine et la réputation de l'organisation. Un compte compromis qui expédie un virus ou dix mille spams peut faire inscrire l'adresse IP et le domaine sur des listes de blocage avant même que l'équipe ne voie l'incident.

Un moteur tel que ClamAV sait analyser de nombreux formats de courrier et de fichiers, mais un antivirus n'est pas un oracle. Une archive chiffrée, une URL qui devient malveillante après livraison, un document sans charge connue ou une fraude purement textuelle peuvent lui échapper. Il faut compléter l'analyse par une politique de pièces jointes, une sandbox lorsque le risque le justifie, des limites de volume et des alertes comportementales.

La décision de rejeter, mettre en quarantaine ou laisser passer avec une alerte doit être explicite. Renvoyer automatiquement un « virus détecté » à l'adresse affichée de l'expéditeur peut créer de la rétrodiffusion, car cette adresse est souvent falsifiée.

SPF : quelles machines ont le droit d'envoyer ?

SPF publie dans le DNS la liste des systèmes autorisés à utiliser un domaine comme identité d'enveloppe SMTP. Le contrôle porte principalement sur l'adresse MAIL FROM, souvent visible ensuite comme Return-Path, et sur l'adresse IP du serveur émetteur. Il ne vérifie pas le contenu et ne protège pas, à lui seul, le champ From: que voit l'utilisateur.

example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.prestataire.example -all"
  • v=spf1 annonce la version du mécanisme ;
  • ip4:192.0.2.10 autorise cette adresse de documentation ;
  • include: délègue une partie de la politique à un prestataire ;
  • -all indique qu'après cet inventaire, les autres sources ne sont pas autorisées.

SPF impose une limite de dix mécanismes ou modificateurs provoquant des recherches DNS pendant l'évaluation. Empiler des include sans regarder ce qu'ils contiennent peut produire un permerror. Il faut aussi prévoir les redirections : un serveur qui transfère un message change l'adresse IP émettrice, ce qui peut faire échouer SPF alors que DKIM reste valide.

Un domaine ne doit publier qu'un seul enregistrement SPF cohérent. Deux enregistrements v=spf1 séparés ne s'additionnent pas : ils rendent le résultat invalide.

De DomainKeys à DKIM : signer au nom d'un domaine

DomainKeys, proposé à l'origine par Yahoo, est l'un des principaux ancêtres dont DKIM a été dérivé. DKIM ajoute au message une signature calculée avec la clé privée du domaine. Le destinataire récupère la clé publique dans le DNS et vérifie que les parties signées n'ont pas changé.

Un en-tête simplifié ressemble à ceci :

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
 h=from:to:subject:date; bh=...; b=...
  • d=example.com est le domaine qui assume la signature ;
  • s=mail2026 est le sélecteur, utile pour choisir et renouveler les clés ;
  • a=rsa-sha256 est l'algorithme de signature ;
  • h= énumère les en-têtes couverts ;
  • bh= contient l'empreinte canonisée du corps et b= la signature.

La clé publique correspondante se trouve sous _domainkey :

mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIB..."

Le fameux k=rsa signifie simplement que la clé publique est une clé RSA. p= contient cette clé publique encodée ; la clé privée ne doit jamais être publiée dans le DNS. Elle reste sur le service de signature, idéalement avec des permissions strictes, une sauvegarde protégée et une procédure de rotation.

DKIM n'est ni un chiffrement ni un certificat de bonne conduite. Il associe cryptographiquement un message à un domaine signataire. Une liste de diffusion qui réécrit l'objet ou le corps peut casser la signature ; un domaine compromis peut, lui, produire une signature parfaitement valide sur un message malveillant.

DMARC : aligner le domaine visible avec SPF ou DKIM

DMARC relie enfin l'authentification au domaine du champ From: visible. Un message passe DMARC si au moins l'un des deux chemins suivants réussit avec un domaine aligné :

  1. SPF réussit et son domaine d'enveloppe est aligné avec le domaine visible ;
  2. DKIM réussit et le domaine d= de la signature est aligné avec le domaine visible.

L'alignement relâché accepte le même domaine organisationnel ; l'alignement strict exige le même nom exact. La politique est publiée dans un enregistrement TXT sous _dmarc :

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"
  • p=none demande de surveiller sans réclamer de mise en quarantaine ou de rejet ;
  • rua= indique où recevoir les rapports agrégés ;
  • adkim=r et aspf=r choisissent l'alignement relâché.

La bonne progression consiste à publier p=none, analyser les rapports, recenser tous les services légitimes, corriger SPF et DKIM, puis passer à p=quarantine et enfin à p=reject lorsque le domaine est maîtrisé. Passer directement au rejet peut bloquer un ERP, un outil de support ou un prestataire oublié.

Ce qui vient de changer en 2026

Depuis mai 2026, la RFC 9989 est la spécification DMARC de référence et remplace les RFC 7489 et 9091. Les formats de rapports sont désormais décrits séparément par les RFC 9990 et 9991. Autre différence visible dans les anciens tutoriels : le tag pct, utilisé pour demander l'application de la politique à un pourcentage de messages, a été retiré de la nouvelle spécification.

La RFC 9989 insiste aussi sur une limite fondamentale : un résultat DMARC pass confirme l'utilisation autorisée du domaine d'auteur, pas la sûreté ni la désirabilité du message. Un compte volé, une application compromise ou une campagne autorisée mais abusive peuvent passer DMARC.

DMARC ne bloque pas non plus l'usurpation du nom affiché — « Direction générale » — ni l'emploi d'un domaine ressemblant. Ces attaques demandent des filtres, de la sensibilisation et des procédures métier.

Protéger le transport : TLS, MTA-STS et DANE

STARTTLS chiffre souvent la liaison SMTP entre deux serveurs, mais le SMTP historique reste opportuniste : sans politique supplémentaire, un attaquant placé sur le chemin peut tenter de faire disparaître l'annonce STARTTLS.

  • MTA-STS permet au domaine destinataire de publier, via DNS et HTTPS, une politique exigeant TLS vers certains MX.
  • DANE pour SMTP publie des enregistrements TLSA protégés par DNSSEC et permet au serveur expéditeur de vérifier la destination tout en résistant au retrait de STARTTLS.

DNSSEC ne chiffre pas le message et ne remplace aucun des contrôles précédents. Il protège l'authenticité des réponses DNS lorsqu'elles sont validées. C'est un sujet complet : voir DNSSEC, KSK, ZSK et la chaîne de confiance.

Un mail signé est-il un mail certifié ?

Le mot « certifié » mélange plusieurs niveaux de preuve.

Mécanisme Ce qu'il établit Ce qu'il n'établit pas
SPF Une machine est autorisée pour un domaine d'enveloppe L'identité humaine, le contenu ou la réception
DKIM Un domaine a signé des en-têtes et un corps restés conformes à la signature La bonne foi de l'auteur, la lecture ou une valeur juridique automatique
DMARC Le domaine visible est aligné avec un SPF ou DKIM valide et publie une politique L'absence de virus, l'identité d'une personne ou la preuve de remise
S/MIME signé Un certificat et sa clé privée ont servi à signer le contenu MIME La preuve que le destinataire a reçu ou lu le message
Service d'envoi recommandé électronique qualifié Un service répondant au cadre eIDAS apporte des présomptions sur l'intégrité, l'expéditeur, le destinataire et les dates d'envoi et de réception Il ne se résume pas à ajouter une signature DKIM

S/MIME peut fournir l'authentification de l'origine et l'intégrité du message ; la portée de l'identité dépend toutefois du certificat, de son émetteur et de la vérification effectuée. Le chiffrement S/MIME est une fonction distincte de la signature.

Dans l'Union européenne, la preuve renforcée d'un envoi recommandé électronique qualifié relève d'un service de confiance conforme au règlement eIDAS. Une signature DKIM ou un accusé de lecture ordinaire ne suffit donc pas à transformer un e-mail classique en recommandé électronique qualifié.

Ordre de déploiement conseillé

  1. Inventorier les flux : utilisateurs, ERP, site web, supervision, copieurs, support, marketing et prestataires.
  2. Centraliser la sortie : imposer un smart host et empêcher les applications de livrer directement sur Internet.
  3. Identifier chaque source : compte ou certificat distinct, expéditeur autorisé, quotas et journaux exploitables.
  4. Filtrer avant de signer : antivirus, règles de pièces jointes, DLP et quarantaine avant DKIM.
  5. Publier SPF : uniquement après avoir recensé les vraies adresses IP et délégations.
  6. Activer DKIM : sélecteur nommé, clé privée protégée, test réel puis rotation documentée.
  7. Observer DMARC : commencer par p=none et lire les rapports agrégés.
  8. Corriger puis renforcer : éliminer les flux non alignés avant quarantine et reject.
  9. Sécuriser le transport : TLS imposé sur la soumission, puis MTA-STS ou DANE selon l'architecture.
  10. Tester l'incident : compte compromis, clé DKIM à renouveler, relais indisponible, file bloquée et restauration de configuration.

La délivrabilité n'est pas un réglage posé une fois pour toutes. Les nouvelles applications, les changements de prestataire et les campagnes de newsletter modifient le périmètre. Les rapports DMARC, les rebonds, la file SMTP et les volumes sortants doivent donc être surveillés en continu.

Pour relier ces contrôles aux limitations SMTP, aux spam traps et à la montée en charge, poursuivez avec Pourquoi les campagnes de masse finissent en spam.

FAQ

SPF, DKIM et DMARC remplacent-ils un antivirus ?

Non. Ils authentifient l'usage d'un domaine et expriment une politique. Un message malveillant envoyé depuis un compte ou un service autorisé peut réussir les trois contrôles.

Qu'est-ce qu'un hôte intelligent ou smart host ?

C'est un relais SMTP central par lequel passent les messages sortants. Il peut authentifier la source, appliquer quotas et filtres, signer en DKIM, mettre en file puis relayer vers Internet.

Que signifie k=rsa dans un enregistrement DKIM ?

Le tag indique que la clé publique publiée sous selector._domainkey est de type RSA. La valeur p= contient la clé publique ; la clé privée reste sur le serveur de signature.

Peut-on publier directement DMARC avec p=reject ?

C'est risqué sans inventaire préalable. Il vaut mieux commencer par p=none, analyser les rapports, corriger tous les flux légitimes, puis renforcer progressivement la politique.

Une signature DKIM rend-elle le mail juridiquement certifié ?

Non. DKIM authentifie un domaine signataire. La signature personnelle S/MIME et le service d'envoi recommandé électronique qualifié répondent à d'autres objectifs et à d'autres niveaux de preuve.