Guide : authentification

Configurer DKIM

DKIM signe chaque message avec une clé privée et publie la clé publique correspondante dans votre DNS, pour qu’un destinataire puisse vérifier quel domaine a pris la responsabilité du message et que les parties signées n’ont pas été modifiées en route.

Dernière vérification : 4 novembre 2026

Ce que prouve une signature DKIM

DomainKeys Identified Mail (DKIM, RFC 6376) ajoute à chaque message un en-tête DKIM-Signature. Celui-ci nomme un domaine signataire (d=) et un sélecteur (s=), liste les en-têtes signés et contient un hachage du corps ainsi qu’une signature portant sur les deux.

Le destinataire récupère la clé publique dans le DNS, vérifie la signature et recalcule le hachage du corps. Un résultat pass montre que le domaine signataire a pris la responsabilité du message et que les parties signées n’ont pas changé depuis la signature.

Où se trouve la clé

La clé publique est un enregistrement TXT à selector._domainkey.yourdomain. Le sélecteur permet à un domaine de détenir plusieurs clés à la fois, par exemple une par service d’envoi, ou une ancienne et une nouvelle pendant un changement.

Votre service d’envoi génère la paire de clés, garde la clé privée et vous donne l’enregistrement à publier. Copiez la valeur exactement : un caractère manquant dans la valeur p= fait échouer toutes les signatures.

Les clés longues dépassent 255 caractères, la limite d’une chaîne TXT. La plupart des hébergeurs DNS les découpent pour vous ; si ce n’est pas le cas du vôtre, saisissez la valeur en plusieurs chaînes entre guillemets, que les destinataires réassemblent.
Publiez l’enregistrement comme un simple TXT, sans proxy ni réécriture par un service DNS.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Longueur de clé et algorithme

La RFC 8301 impose aux signataires des clés RSA d’au moins 1024 bits, recommande au moins 2048 bits et interdit de signer avec rsa-sha1. Une clé RSA de 2048 bits avec rsa-sha256 est aujourd’hui le choix courant et elle est acceptée par tous les grands fournisseurs de messagerie.

Ce qui casse une signature

Tout ce qui modifie les en-têtes signés ou le corps après la signature : une liste de diffusion qui ajoute un pied de page ou modifie l’objet, une passerelle de sécurité qui réécrit les liens, un serveur qui réencode le message. La canonicalisation relaxed (c=relaxed/relaxed) tolère les changements d’espaces et de casse dans les noms d’en-têtes, pas ceux du contenu.

Un simple transfert conserve en général la signature, c’est pourquoi DKIM est la moitié la plus robuste de DMARC.

Vérifier le résultat

Envoyez un message vers une boîte que vous contrôlez et lisez l’en-tête Authentication-Results : vous voulez dkim=pass avec header.d= égal à votre domaine. Si le domaine d= est celui de votre fournisseur et non le vôtre, le message est signé mais ne sera pas aligné pour DMARC.

Comment Mail.Land gère DKIM

Quand vous ajoutez un domaine, Mail.Land génère pour lui une paire de clés RSA de 2048 bits et vous donne un enregistrement TXT à publier à mlnd._domainkey.yourdomain (le sélecteur est mlnd). Chaque message de ce domaine est signé avec sa propre clé, avec votre domaine en d=, de sorte que DKIM est aligné avec votre adresse From.

DKIM est obligatoire : SPF, DKIM et DMARC doivent tous être vérifiés avant que le domaine puisse envoyer.

Configuration DNS dans la documentation Mail.Land