← RFC Reference

L'authentification par email expliquée

Comment SPF, DKIM, DMARC et ARC travaillent ensemble en tant que système — et ce qui se passe étape par étape quand un message arrive sur un serveur destinataire.

Pourquoi l'email a besoin d'authentification

SMTP a été conçu au début des années 1980 sans vérification intégrée de l'expéditeur. N'importe quel serveur peut se connecter à n'importe quel autre serveur et prétendre envoyer du courrier depuis n'importe quelle adresse. Ce n'est pas un bug — c'est ainsi que le protocole a été construit.

L'authentification des emails est un ensemble de normes ajoutées au-dessus de SMTP pour répondre à trois questions :

1. SPF : Ce serveur est-il autorisé à envoyer du courrier pour ce domaine ?
2. DKIM : Ce message a-t-il vraiment été envoyé par le domaine prétendu, et est-il inmodifié ?
3. DMARC : Que dois-je faire si SPF et DKIM échouent tous les deux — et l'un des résultats s'aligne-t-il avec l'en-tête From: ?

Chaque mécanisme aborde une surface d'attaque différente. Ensemble, ils forment un système de défense en profondeur.

SPF : Qui est autorisé à envoyer

SPF (Sender Policy Framework, RFC 7208) permet à un domaine de publier une liste de serveurs autorisés à envoyer du courrier en son nom. C'est un enregistrement DNS TXT :

Quand un message arrive, le serveur destinataire extrait le domaine du MAIL FROM (expéditeur de l'enveloppe) et interroge DNS pour l'enregistrement SPF. Il vérifie si l'adresse IP du serveur de connexion correspond à l'un des mécanismes autorisés.

Résultats de l'évaluation SPF :

• pass — L'adresse IP est explicitement autorisée
• fail — L'adresse IP est explicitement non autorisée (-all)
• softfail — L'adresse IP n'est probablement pas autorisée (~all) — accepter mais marquer
• neutral — Le domaine ne fait aucune affirmation sur cette adresse IP (?all)
• temperror / permerror — La requête DNS a échoué ou l'enregistrement est malformé

Limitations de SPF

SPF valide l'expéditeur de l'enveloppe, pas l'en-tête From: que les utilisateurs voient. Un phisheur peut réussir le SPF en utilisant son propre domaine dans l'enveloppe tout en usurpant votre domaine dans l'en-tête From:. SPF s'arrête également quand le courrier est transféré, car l'adresse IP du serveur de transfert ne figure pas dans l'enregistrement SPF du domaine d'origine. Ces limitations sont pourquoi SPF seul ne suffit pas.

DKIM : Signature numérique des messages

DKIM (DomainKeys Identified Mail, RFC 6376) ajoute une signature numérique au message. Le serveur d'envoi signe les en-têtes sélectionnés et le corps à l'aide d'une clé privée. La clé publique correspondante est publiée dans DNS :

La signature est ajoutée en tant qu'en-tête DKIM-Signature :

Champs clés de DKIM-Signature :

• d= — Le domaine de signature (c'est ce que DMARC vérifie pour l'alignement)
• s= — Le sélecteur, utilisé pour rechercher la clé publique dans DNS
• h= — Les en-têtes inclus dans la signature
• bh= — Hash du corps du message
• b= — La signature réelle
• c= — Algorithme de canonicalisation (relaxed/relaxed est standard — tolère les petits changements d'espaces)

Le serveur destinataire récupère la clé publique à partir de DNS, recalcule le hash sur les en-têtes signés et le corps, et vérifie la signature. Si elle correspond, le message a été signé par quelqu'un ayant accès à la clé privée de ce domaine, et le contenu signé n'a pas été modifié.

Limitations de DKIM

DKIM survit au transfert (contrairement à SPF) car la signature voyage avec le message. Cependant, les listes de diffusion qui modifient le sujet ou le corps vont casser la signature. DKIM ne dit pas au destinataire quoi faire avec une signature échouée — c'est le travail de DMARC.

DMARC : La couche de politique

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) lie SPF et DKIM ensemble et ajoute une politique. Il est publié en tant qu'enregistrement DNS TXT sur _dmarc.example.com :

DMARC introduit le concept crucial d'alignement — le domaine dans le résultat d'authentification doit correspondre au domaine dans l'en-tête From: que l'utilisateur voit :

• Alignement SPF : Le domaine dans MAIL FROM doit correspondre (ou être un sous-domaine de) le domaine de l'en-tête From:, ET SPF doit réussir.
• Alignement DKIM : Le domaine d= dans une signature DKIM valide doit correspondre (ou être un sous-domaine de) le domaine de l'en-tête From:.

Un message réussit DMARC si soit SPF soit DKIM réussit avec alignement. Les deux peuvent échouer individuellement tant que l'un réussit avec alignement.

Politiques DMARC

• p=none — Surveillance uniquement. Ne pas agir sur les échecs. Utilisez ceci lors du déploiement.
• p=quarantine — Traiter les échecs comme suspects (généralement router vers le dossier spam).
• p=reject — Rejeter les messages qui échouent DMARC. C'est l'objectif.

La balise rua= spécifie où les rapports agrégés sont envoyés — des rapports XML affichant les résultats d'authentification pour tous les messages prétendant provenir de votre domaine. Ces rapports sont essentiels pour comprendre votre écosystème de courrier avant de renforcer la politique.

Ce qui se passe quand un message arrive

Voici la séquence d'authentification complète, étape par étape, quand mx.receiver.com reçoit un message prétendant provenir de alice@example.com :

1. Connexion : Le serveur d'envoi se connecte à partir de l'adresse IP 198.51.100.42 et envoie MAIL FROM:<bounce-123@sender.example.com>.
2. Vérification SPF : Le destinataire interroge sender.example.com pour son enregistrement SPF. L'adresse IP 198.51.100.42 est listée → SPF pass. Mais le domaine de l'enveloppe est sender.example.com, et l'en-tête From: dit example.com — ces derniers ne correspondent pas, donc il n'y a pas d'alignement SPF.
3. Message reçu : La phase DATA fournit les en-têtes et le corps.
4. Vérification DKIM : Le destinataire trouve un en-tête DKIM-Signature avec d=example.com; s=mtg. Il récupère la clé publique à partir de mtg._domainkey.example.com, vérifie la signature → DKIM pass. Le domaine d= correspond à l'en-tête From: → DKIM aligné.
5. Vérification DMARC : Le destinataire récupère _dmarc.example.com. La politique est p=reject. SPF a réussi mais n'est pas aligné. DKIM a réussi et EST aligné. Au moins un mécanisme réussit avec alignement → DMARC pass.
6. Authentication-Results : Le destinataire enregistre le résultat dans un en-tête :

Cet en-tête (RFC 8601) est ajouté par le serveur destinataire et est l'enregistrement faisant autorité des résultats d'authentification pour ce tronçon.

ARC : Préserver l'authentification lors du transfert

ARC (Authenticated Received Chain, RFC 8617) résout le problème du transfert. Quand un message passe par un intermédiaire (comme une liste de diffusion ou un service de transfert), SPF s'arrête (l'adresse IP du forwarder n'est pas dans l'enregistrement SPF original) et DKIM peut s'arrêter (si la liste modifie le message).

ARC fonctionne en faisant en sorte que chaque intermédiaire enregistre les résultats d'authentification qu'il a observés avant de modifier le message, puis signe ces résultats. Il ajoute trois en-têtes par tronçon :

• ARC-Authentication-Results (AAR) : Les résultats d'authentification à ce tronçon
• ARC-Message-Signature (AMS) : Une signature semblable à DKIM du message tel qu'il était à ce tronçon
• ARC-Seal (AS) : Une signature sur tous les en-têtes ARC précédents, les enchaînant ensemble

Chaque ensemble d'en-têtes est numéroté (i=1, i=2, etc.), formant une chaîne. Le destinataire final peut inspecter la chaîne pour voir que le message a initialement réussi DMARC au tronçon 1, même s'il échoue maintenant parce qu'un forwarder l'a modifié au tronçon 2.

ARC n'annule pas DMARC. Il fournit une preuve que le destinataire final peut choisir de faire confiance. Que d'honorer les résultats d'ARC dépend du destinataire.

Configuration commune : Envoyer via un tiers

Quand vous utilisez un service de courrier transactionnel comme Mailer To Go pour envoyer du courrier en tant que your-domain.com, vous devez configurer les trois couches :

Le service de courrier envoie avec votre domaine dans le champ d= DKIM, assurant l'alignement DKIM. La directive SPF include: autorise leurs serveurs. DMARC lie tout ensemble.

Ce qui peut mal tourner

SPF trop de requêtes DNS

SPF a une limite stricte de 10 requêtes DNS. Chaque mécanisme include:, a:, mx: et redirect= compte pour une requête. Les includes imbriquées comptent vers le total. Si vous dépassez 10, l'évaluation SPF retourne permerror et DMARC le traite comme un échec. Auditez votre enregistrement SPF avec un outil de validation.

Échecs de rotation de clé DKIM

Si vous faites pivoter votre clé DKIM (publiez une nouvelle clé publique) avant que votre infrastructure d'envoi ne commence à utiliser la nouvelle clé privée, tous les messages en vol échoueront la vérification DKIM. Publiez toujours la nouvelle clé en premier, attendez la propagation DNS, passez à la nouvelle clé privée, puis supprimez l'ancienne clé publique après une période de grâce.

Décalage d'alignement DMARC

Votre SPF réussit et votre DKIM réussit, mais DMARC échoue toujours. Cela se produit quand aucun résultat ne s'aligne avec l'en-tête From:. Par exemple, SPF valide bounces.esp.com (l'expéditeur de l'enveloppe) mais l'en-tête From: dit your-domain.com. La correction : assurez-vous que DKIM signe avec d=your-domain.com.

Courrier transféré rejeté

Un utilisateur transfère son courrier old@example.com vers new@gmail.com. Votre message réussit DMARC au serveur original, mais Gmail voit l'adresse IP du serveur de transfert (SPF échoue) et le message peut être modifié (DKIM échoue). Avec p=reject, la copie transférée est rejetée. ARC peut aider, mais l'adoption varie.

Lacunes de politique de sous-domaine

Vous publiez p=reject sur _dmarc.example.com, mais un phisheur envoie depuis billing.example.com, qui n'a pas d'enregistrement DMARC. Sans sp=reject (politique de sous-domaine) dans votre enregistrement DMARC, le sous-domaine hérite de la politique organisationnelle — mais seulement s'il n'y a pas d'enregistrement séparé. Définissez explicitement sp=reject ou publiez des enregistrements DMARC pour tous les sous-domaines.

Points clés à retenir

• SPF vérifie l'adresse IP du serveur d'envoi par rapport à DNS. Il valide l'expéditeur de l'enveloppe, pas l'en-tête From:.
• DKIM signe cryptographiquement le message. Il survit au transfert (sauf si le message est modifié) et valide le domaine de signature.
• DMARC exige que SPF ou DKIM réussisse avec alignement à l'en-tête From:. Il publie une politique pour ce qu'il faut faire en cas d'échec.
• ARC préserve la preuve d'authentification à travers les tronçons de transfert.
• Vous devez avoir les trois (SPF, DKIM, DMARC) configurés correctement. N'importe lequel seul a des lacunes exploitables.
• Commencez avec p=none, lisez vos rapports agrégés DMARC, puis progressez vers p=reject.

Lectures supplémentaires

Related RFCs