SPF, DKIM, DMARC — Mémo pratique pour l’authentification des e-mails

1. Introduction

Le courrier électronique reste la première voie d’attaque en entreprise. L’authentification des messages via SPF (origine autorisée), DKIM (intégrité & signature) et DMARC (politique & reporting) permet de réduire drastiquement l’usurpation de domaine et d’améliorer la délivrabilité. Utilisés ensemble, ces mécanismes fournissent un cadre cohérent de confiance.

2. SPF — Sender Policy Framework

Objectif. Déclarer publiquement (DNS) quelles adresses IP/serveurs sont autorisés à envoyer des e-mails pour un domaine. Les serveurs destinataires comparent l’IP émettrice à cette politique.

2.1. Principe et évaluation

• Enregistrement TXT au nom du domaine expéditeur (ex. example.com).
• Mécanismes clés : ip4, ip6, a, mx, include.
• Qualificatifs : + (pass, implicite), ~ (softfail), - (fail), ? (neutral).

2.2. Exemple

example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.12 include:_spf.mailprovider.com -all"

Interprétation : une IP interne autorisée, plus l’opérateur SaaS d’envoi. Tout le reste est explicitement refusé (-all).

2.3. Bonnes pratiques

• Limiter les include: pour éviter les dépassements de “10 DNS lookups”.
• Documenter l’inventaire des expéditeurs (M365/Google, CRM, outil marketing, factureur, etc.).
• Terminer par -all après période d’observation (éviter ~all en cible).

3. DKIM — DomainKeys Identified Mail

Objectif. Signer cryptographiquement les messages sortants avec une clé privée. Le serveur destinataire vérifie la signature en récupérant la clé publique (TXT) dans le DNS du domaine expéditeur.

3.1. Éléments essentiels

• Sélecteur (selector) : identifiant libre (ex. m365, news) publié sous selector._domainkey.example.com.
• Paramètres courants : v=DKIM1; k=rsa; p=... (clé publique), t=s (test), h= (entêtes signés), c= (canonicalisation).
• Tailles de clés : 2048 bits recommandé.

3.2. Exemple d’enregistrement DNS

m365._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA..."

3.3. Bonnes pratiques

• Un sélecteur par plateforme d’envoi (M365, outil marketing, ERP). Rotation de clés planifiée.
• Signer au minimum From, Subject, Date et les parties MIME principales.
• Éviter la réécriture en route (passerelles altérant les entêtes).

4. DMARC — Domain-based Message Authentication, Reporting & Conformance

Objectif. Définir une politique d’acceptation/rejet basée sur les résultats SPF/DKIM et leur alignement avec le domaine visible dans l’entête From:. Fournit des rapports d’observation aux propriétaires du domaine.

4.1. Alignement

Un message “passe” DMARC si SPF aligné ou DKIM aligné est valide. L’alignement signifie que le domaine évalué par SPF/DKIM correspond (relaxé : même domaine racine ; strict : domaine exact) au domaine de l’entête From:.

4.2. Exemple d’enregistrement DMARC (phase observation)

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1; sp=none; adkim=r; aspf=r"

4.3. Passage progressif vers l’application

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Augmenter pct jusqu’à 100, puis p=reject lorsque tous les expéditeurs légitimes sont couverts.

4.4. Paramètres utiles

• p=none|quarantine|reject : politique globale.
• sp=... : politique pour les sous-domaines.
• rua/ruf : adresses de rapports agrégés/forensic (prévoir une boîte dédiée).
• fo : granularité des rapports d’échec (ex. fo=1 pour chaque fail).
• adkim/aspf : alignement strict (s) ou relaxé (r).

5. Feuille de route de déploiement (PME)

1. Inventorier tous les émetteurs (suite bureautique, CRM, marketing, ERP, copieurs, helpdesk).
2. Activer DKIM sur chaque plateforme (prioritaire : signature + intégrité visible).
3. Établir SPF minimal, tester et converger vers -all (après validation).
4. Publier DMARC en p=none avec rua ; analyser 2–4 semaines.
5. Corriger les envois non alignés (alias, sous-domaines, routage via passerelles).
6. Monter progressivement vers quarantine puis reject, adkim/aspf=s si possible.
7. Industrialiser la rotation DKIM (sélecteurs datés) et la revue trimestrielle de SPF.

6. Contrôle & dépannage

6.1. Symptômes courants

• SPF “permerror” : trop de lookups (>10) ou syntaxe incorrecte.
• DKIM “fail (body hash)” : modification du contenu par une passerelle (bannières, disclaimers).
• DMARC “fail (unaligned)” : le domaine signé/évalué ne correspond pas au From:.

6.2. Conseils

• Signer côté dernier saut sortant ; éviter les altérations post-signature.
• Normaliser les adresses From: (pas d’expédition via domaines tiers sans sous-domaine dédié).
• Créer un sous-domaine d’envoi marketing (ex. news.example.com) avec ses propres SPF/DKIM/DMARC.

7. Extensions utiles

• BIMI : affichage du logo de marque chez certains fournisseurs, nécessite DMARC à quarantine/reject.
• ARC : préserve l’authentification à travers les réexpéditions/listes (utile mais distinct de DMARC).

8. Conclusion

SPF, DKIM et DMARC fournissent un triptyque cohérent : origine autorisée, signature vérifiable et politique d’application avec visibilité. Pour les PME, une approche par étapes — inventaire, DKIM, SPF, DMARC en observation puis application — maximise la sécurité tout en limitant les faux positifs. La supervision continue des rapports DMARC assure la pérennité du dispositif.