Pourquoi l'authentification est devenue obligatoire

Jusqu'au milieu des années 2000, n'importe quel serveur pouvait envoyer un email en se réclamant de n'importe quel domaine. L'usurpation d'identité (spoofing) était triviale : une ligne From: [email protected] dans l'en-tête suffisait. Les protocoles SPF, DKIM et DMARC ont été conçus pour rendre ce type d'usurpation vérifiable et sanctionnable.

Depuis février 2024, Google et Yahoo ont rendu ces protocoles obligatoires pour les expéditeurs en volume. En pratique, un domaine sans SPF ou DKIM valide voit ses emails rejetés ou systématiquement placés en spam chez les deux principaux opérateurs mondiaux. Ce n'est plus une recommandation — c'est un prérequis technique.

SPF — Sender Policy Framework

SPF répond à une question simple : quelles adresses IP sont autorisées à envoyer des emails au nom de votre domaine ? La réponse est publiée dans un enregistrement DNS de type TXT sur votre domaine racine. Quand un serveur de réception reçoit un email de [email protected], il consulte les enregistrements DNS de exemple.fr et vérifie si l'IP expéditrice figure dans la liste autorisée.

Structure d'un enregistrement SPF

Un enregistrement SPF commence toujours par v=spf1 et se termine par une politique de résultat. Entre les deux figurent les mécanismes qui définissent les sources autorisées.

v=spf1 ip4:203.0.113.1 include:_spf.google.com include:sendgrid.net ~all

Dans cet exemple, l'IP 203.0.113.1 est explicitement autorisée. Les domaines Google et SendGrid sont inclus via le mécanisme include: qui importe leurs propres listes d'IP. Le ~all final indique que tout email provenant d'une source non listée doit être traité avec suspicion (softfail) plutôt que rejeté définitivement (-all).

La limite des 10 lookups DNS

SPF impose une contrainte peu documentée : le mécanisme de validation ne peut pas déclencher plus de 10 requêtes DNS lors de l'évaluation d'un enregistrement. Chaque include:, a:, mx: ou redirect: consomme un lookup. Si votre domaine utilise plusieurs ESPs (Mailchimp, SendGrid, HubSpot, un serveur propre…), la limite est atteinte rapidement.

Attention

Un enregistrement SPF qui dépasse 10 lookups DNS produit un résultat permerror, équivalent à un échec SPF. Gmail et Outlook traitent ce cas comme une absence de SPF valide.

Pour rester sous la limite, plusieurs approches existent : consolider les IP dans un seul bloc ip4:, utiliser des outils de "flattening" SPF qui résolvent les include: en adresses IP statiques, ou supprimer les includes d'ESPs que vous n'utilisez plus.

Softfail vs. hardfail

Le qualificatif final de l'enregistrement détermine le comportement en cas d'échec. ~all (softfail) indique que les emails de sources non autorisées doivent être acceptés avec méfiance — ils arriveront probablement en spam mais ne seront pas rejetés. -all (hardfail) ordonne le rejet. En pratique, commencer par ~all pendant la phase de déploiement est prudent : une erreur de configuration avec -all peut faire disparaître des emails légitimes.

DKIM — DomainKeys Identified Mail

SPF vérifie l'IP d'envoi. DKIM vérifie l'intégrité du message lui-même. Le protocole fonctionne par signature cryptographique : votre serveur d'envoi signe chaque email sortant avec une clé privée. La clé publique correspondante est publiée en DNS sous un sélecteur spécifique. Le serveur de réception récupère cette clé publique et vérifie que la signature est valide — ce qui prouve que le message n'a pas été altéré en transit.

Structure de l'enregistrement DNS DKIM

La clé publique est publiée sur un sous-domaine de la forme sélecteur._domainkey.votredomaine.fr. Le sélecteur est un identifiant arbitraire que vous choisissez — il permet d'avoir plusieurs clés actives simultanément, ce qui facilite la rotation.

mail._domainkey.exemple.fr  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

RSA 2048 ou Ed25519 ?

RSA 2048 bits est le standard historique, supporté par la totalité des serveurs de réception. Ed25519 est plus récent, produit des signatures plus courtes et offre une sécurité équivalente avec une clé plus petite. Le support d'Ed25519 pour DKIM est incomplet chez certains opérateurs anciens. La recommandation pratique : utiliser RSA 2048 en production, tester Ed25519 sur un sélecteur secondaire.

Rotation des clés DKIM

Les bonnes pratiques de sécurité recommandent de changer les clés DKIM régulièrement — au minimum une fois par an, idéalement tous les six mois. La procédure consiste à générer une nouvelle paire de clés, publier la nouvelle clé publique sous un nouveau sélecteur, mettre à jour la configuration du serveur d'envoi, puis supprimer l'ancien sélecteur après une période de transition (les emails en transit peuvent encore porter l'ancienne signature).

Note technique

DKIM signe un sous-ensemble d'en-têtes et le corps du message, pas la totalité. Le champ h= de la signature liste les en-têtes inclus. Les en-têtes non signés peuvent être modifiés sans invalider la signature — à prendre en compte lors de l'analyse des résultats.

DMARC — Domain-based Message Authentication, Reporting and Conformance

SPF et DKIM fonctionnent indépendamment. DMARC les coordonne et définit ce que les opérateurs doivent faire quand l'un ou l'autre échoue. Il ajoute également un mécanisme de reporting : les opérateurs envoient des rapports quotidiens sur les résultats d'authentification pour votre domaine.

Le principe d'alignement

DMARC introduit la notion d'alignement : pour qu'un email passe DMARC, il ne suffit pas que SPF ou DKIM réussissent — il faut aussi que le domaine utilisé dans ces protocoles corresponde au domaine visible dans le champ From: de l'email. Sans alignement, un expéditeur malveillant pourrait utiliser un domaine tiers avec SPF valide tout en usurpant votre domaine en From:.

Les trois politiques DMARC

Politique Comportement Usage recommandé
p=none Aucune action — collecte de rapports seulement Phase initiale obligatoire
p=quarantine Les emails qui échouent DMARC sont placés en spam Transition après analyse des rapports
p=reject Les emails qui échouent DMARC sont rejetés Politique cible pour domaines stables

Lire les rapports RUA

L'adresse spécifiée dans le tag rua= reçoit des rapports agrégés quotidiens en XML. Ces rapports indiquent, pour chaque source d'envoi, le nombre de messages traités et les résultats SPF/DKIM/DMARC. Ils permettent de détecter des sources légitimes non encore configurées, des tentatives d'usurpation, ou des problèmes de configuration silencieux. Des outils comme DMARC Analyzer, Postmark ou MXToolbox disposent d'interfaces pour lire ces rapports sans manipuler le XML brut.

Ordre de déploiement recommandé

Déployer SPF et DKIM en premier, vérifier leur bon fonctionnement sur plusieurs semaines d'envoi réel, puis activer DMARC en p=none. Analyser les rapports pendant quatre à six semaines minimum. Identifier et corriger toutes les sources d'envoi légitimes qui échouent. Passer à p=quarantine avec un pct= progressif (25%, 50%, 100%), puis à p=reject une fois la configuration stabilisée.

Erreur fréquente

Passer directement à p=reject sans phase d'observation est l'erreur la plus commune. Les services tiers (CRM, outils de support, plateformes d'automatisation) envoient souvent des emails au nom de votre domaine sans être référencés dans votre SPF — ils disparaîtront silencieusement jusqu'à correction.

MTA-STS et TLS-RPT — la couche complémentaire

MTA-STS (Mail Transfer Agent Strict Transport Security) est un protocole plus récent qui impose le chiffrement TLS lors du transit SMTP entre serveurs. Sans lui, un attaquant en position de man-in-the-middle peut théoriquement intercepter un email en transit en forçant une connexion non chiffrée. MTA-STS publie une politique via un fichier HTTPS et un enregistrement DNS qui indique aux serveurs expéditeurs que votre domaine exige TLS.

TLS-RPT accompagne MTA-STS : il fournit un mécanisme de reporting pour les échecs de connexion TLS, similaire aux rapports DMARC. Ces deux protocoles ne remplacent pas SPF/DKIM/DMARC — ils opèrent sur la couche de transport plutôt que sur l'authentification de l'expéditeur.

Vérifier sa configuration

Plusieurs outils permettent de valider une configuration sans envoyer d'email de test. MXToolbox propose des vérificateurs pour SPF, DKIM et DMARC séparément. Mail-tester.com évalue l'ensemble de la configuration en envoyant un email à une adresse de test dédiée. Google Postmaster Tools donne un retour sur la réputation de votre domaine vu depuis Gmail, une fois le domaine vérifié dans l'interface. Ces outils ne remplacent pas la lecture des rapports DMARC — ils donnent un état à un instant T, pas une vue sur la durée.