SPF, DKIM, DMARC : comprendre l'authentification email en 2025

Introduction

Chaque jour, plus de 300 milliards d'emails sont envoyés dans le monde, dont environ 45 % sont du spam selon le rapport Cisco Talos 2024. Face à ce fléau, les fournisseurs de messagerie (Gmail, Outlook, Yahoo) ont mis en place des mécanismes d'authentification de plus en plus stricts.

Depuis février 2024, Google et Yahoo exigent explicitement la mise en place de SPF, DKIM et DMARC pour tout expéditeur envoyant plus de 5 000 emails par jour. Mais même pour les petits expéditeurs, ces protocoles sont devenus indispensables pour éviter que vos emails légitimes n'atterrissent en spam.

Le problème fondamental

Le protocole SMTP (Simple Mail Transfer Protocol), conçu en 1982 (RFC 821), ne prévoyait aucun mécanisme d'authentification de l'expéditeur. N'importe qui peut techniquement envoyer un email en se faisant passer pour n'importe quelle adresse.

C'est comme envoyer une lettre postale avec l'adresse de retour de quelqu'un d'autre — rien ne l'empêche. SPF, DKIM et DMARC ont été créés pour combler cette lacune.

SPF (Sender Policy Framework)

Principe

SPF permet au propriétaire d'un domaine de déclarer quels serveurs sont autorisés à envoyer des emails en son nom.

Cette déclaration prend la forme d'un enregistrement DNS de type TXT :

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.42 -all

Décomposons :

Les qualificateurs

Limites de SPF

• Maximum de 10 lookups DNS : chaque include compte, et les chaînes d'includes se cumulent
• Ne protège pas le champ From visible : SPF vérifie l'adresse d'enveloppe (Return-Path), pas le From affiché à l'utilisateur
• Casse avec le transfert : quand un email est transféré, le serveur de transfert n'est pas dans le SPF du domaine d'origine

DKIM (DomainKeys Identified Mail)

Principe

DKIM ajoute une signature cryptographique à chaque email envoyé. Le serveur d'envoi signe le message avec une clé privée, et le serveur de réception vérifie la signature avec la clé publique publiée dans le DNS.

Fonctionnement

1. Le serveur d'envoi calcule un hash du contenu de l'email
2. Il chiffre ce hash avec sa clé privée
3. Il ajoute la signature dans un en-tête DKIM-Signature
4. Le serveur de réception récupère la clé publique via le DNS
5. Il déchiffre la signature et compare le hash

L'enregistrement DNS DKIM

La clé publique est publiée sous un sélecteur (selector) :

selector._domainkey.example.com IN TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhk..."

Le sélecteur permet de gérer plusieurs clés (une par service d'envoi, par exemple).

Avantages sur SPF

• Résiste au transfert : la signature reste valide même si l'email est transféré
• Vérifie l'intégrité : toute modification du contenu invalide la signature
• Identifie le domaine signataire : pas seulement le serveur d'envoi

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Principe

DMARC est la couche supérieure qui orchestre SPF et DKIM et dit aux serveurs de réception quoi faire quand l'authentification échoue.

L'enregistrement DNS DMARC :

_dmarc.example.com IN TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s"

Les trois politiques DMARC

L'alignement : la clé de DMARC

DMARC vérifie que le domaine visible dans le champ From correspond au domaine vérifié par SPF ou DKIM. C'est l'alignement.

Sans DMARC, un attaquant pourrait :

1. Utiliser son propre serveur (SPF valide pour son domaine)
2. Signer avec DKIM sur son domaine
3. Mais afficher votre adresse dans le champ From

DMARC empêche cette usurpation en exigeant que tout soit cohérent.

Les rapports DMARC

DMARC génère deux types de rapports :

• Rapports agrégés (RUA) : résumé quotidien des résultats d'authentification, en XML
• Rapports forensiques (RUF) : détails sur chaque échec (rarement implémenté)

Des services comme Postmark DMARC Digests ou dmarcian convertissent ces rapports XML en tableaux de bord lisibles.

Mise en place progressive

Étape 1 : Audit de l'existant

Identifiez tous les services qui envoient des emails pour votre domaine :

• Votre serveur email principal
• Votre outil de newsletter (Mailchimp, SendGrid, Brevo…)
• Votre CRM
• Votre application web (emails transactionnels)
• Les services SaaS qui envoient en votre nom

Étape 2 : Configurer SPF

Ajoutez un enregistrement TXT incluant tous vos expéditeurs légitimes. Vérifiez avec des outils comme MXToolbox ou dmarcian SPF Surveyor.

Étape 3 : Configurer DKIM

Chaque service d'envoi fournit une clé DKIM à publier dans votre DNS. Consultez la documentation de chaque outil.

Étape 4 : Déployer DMARC progressivement

1. Commencez par p=none pendant 2 à 4 semaines
2. Analysez les rapports pour identifier les envois légitimes non authentifiés
3. Corrigez les problèmes identifiés
4. Passez à p=quarantine pendant 2 semaines
5. Finalement, passez à p=reject

Vérification

Plusieurs outils permettent de vérifier votre configuration :

• mail-tester.com : envoyez un email de test et recevez un score sur 10
• MXToolbox : analyse complète de vos enregistrements DNS
• Google Postmaster Tools : tableau de bord de réputation pour les envois vers Gmail
• headers d'email : examinez les en-têtes Authentication-Results d'un email reçu

Conclusion

SPF, DKIM et DMARC forment un trio indissociable pour protéger votre domaine contre l'usurpation d'identité et garantir la délivrabilité de vos emails. La mise en place demande de la rigueur mais n'est pas techniquement complexe. En 2025, ne pas avoir ces trois protocoles configurés, c'est accepter que vos emails arrivent en spam — et que n'importe qui puisse envoyer des emails en votre nom.