DMARC / DKIM / SPF

general

Définition

DMARC, DKIM, et SPF forment les trois piliers de l'authentification email qui protègent contre le phishing, le spoofing, et l'usurpation de domaine. Ensemble, ils permettent aux serveurs de messagerie destinataires de vérifier que les emails prétendant provenir d'un domaine ont bien été envoyés par des serveurs autorisés par ce domaine, et que le contenu n'a pas été modifié en transit. SPF (Sender Policy Framework, RFC 7208) est le plus simple des trois. Il définit dans un enregistrement DNS TXT quels serveurs sont autorisés à envoyer des emails au nom du domaine : `example.com IN TXT "v=spf1 include:_spf.google.com ip4:192.0.2.1 -all"`. Le `-all` à la fin signifie que tout serveur non listé doit échouer la vérification SPF. Le serveur destinataire vérifie l'IP de l'expéditeur contre la liste SPF du domaine dans l'en-tête MAIL FROM. Limitation : SPF vérifie l'enveloppe SMTP, pas le header "From:" visible par l'utilisateur — un attaquant peut contourner SPF avec un domaine d'enveloppe différent tout en affichant le domaine légitime dans le "From:". DKIM (DomainKeys Identified Mail, RFC 6376) ajoute une signature cryptographique à chaque email. Le serveur expéditeur signe certains en-têtes et le corps du message avec une clé privée. Le destinataire récupère la clé publique correspondante dans le DNS (enregistrement TXT pour `selector._domainkey.example.com`) et vérifie la signature. DKIM garantit l'intégrité (le message n'a pas été modifié) et l'authenticité (il a été signé par le serveur autorisé). DKIM survit aux relais email (contrairement à SPF). DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) coordonne SPF et DKIM et définit que faire des emails qui échouent : `v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100`. La politique `p=` peut être `none` (monitoring), `quarantine` (spam), ou `reject` (rejeter). DMARC ajoute l'alignement : l'en-tête "From:" visible doit être aligné avec le domaine qui passe SPF ou DKIM — empêchant l'attaque du header "From:" spoofé.

Déploiement progressif DMARC — none → quarantine → reject

Le déploiement de DMARC doit être progressif pour éviter de bloquer des emails légitimes. Étape 1 — p=none (monitoring) : déployer DMARC en mode observation avec `p=none` et configurer les rapports RUA (agrégats quotidiens en XML) et RUF (forensics par email). Analyser les rapports pendant 2-4 semaines pour identifier tous les flux d'emails légitimes (services d'envoi marketing, CRM, ERP, alertes systèmes) et vérifier qu'ils passent SPF ou DKIM. Outils de visualisation DMARC : DMARC Analyzer, Postmark DMARC, Google Postmaster Tools. Étape 2 — p=quarantine (50%) : commencer avec `pct=50; p=quarantine` pour envoyer 50% des emails non conformes en spam, surveiller les résultats et corriger les flux légitimes non conformes. Étape 3 — p=reject (100%) : quand tous les flux légitimes sont conformes, passer à `p=reject; pct=100` pour le niveau de protection maximum.

MTA-STS et SMTP TLS Reporting

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) est une extension complémentaire qui force les serveurs MTA expéditeurs à utiliser TLS pour livrer les emails à votre domaine. Sans MTA-STS, un attaquant réseau peut faire du downgrade de STARTTLS (stripping) pour intercepter les emails en transit. MTA-STS publie une politique HTTPS (`https://mta-sts.example.com/.well-known/mta-sts.txt`) qui stipule que les connexions SMTP entrantes doivent utiliser TLS avec validation du certificat. SMTP TLS Reporting (RFC 8460, enregistrement DNS `_smtp._tls.example.com`) permet de recevoir des rapports sur les problèmes de livraison TLS. La combinaison DMARC + DKIM + SPF + MTA-STS + DNSSEC pour la zone DNS de messagerie constitue l'arsenal complet de sécurité email.

Business Email Compromise et DMARC

Le BEC (Business Email Compromise — Arnaque au Faux Président) est l'une des cyber-fraudes les plus coûteuses (plus de 2,7 milliards de dollars de pertes en 2022 selon le FBI). Les attaquants usurpent l'identité de dirigeants pour demander des virements frauduleux. DMARC avec p=reject protège contre l'usurpation du domaine exact de l'entreprise (finance@example.com spoofé). Cependant, les attaquants utilisent des domains cousins (example-corp.com, examp1e.com) qui ne sont pas couverts par DMARC. La protection complète contre le BEC nécessite : DMARC p=reject pour le domaine principal ET tous les domaines cousins enregistrés défensivement, formation des employés pour vérifier les demandes inhabituelles par un autre canal (appel téléphonique), et contrôles procéduraux (double validation pour les virements supérieurs à un seuil).

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis