Saisissez un domaine et un sélecteur DKIM pour interroger l’enregistrement TXT de clé publique publié à <selector>._domainkey.<domain> et lire ses balises. L’outil est gratuit, s’exécute instantanément dans votre navigateur via DNS-over-HTTPS, sans inscription et sans rien conserver.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
DKIM (DomainKeys Identified Mail) permet à un serveur d’envoi de joindre une signature cryptographique à chaque message. La clé publique correspondante est publiée dans le DNS sous forme d’enregistrement TXT à <selector>._domainkey.<domain>, où le sélecteur est une étiquette choisie par l’expéditeur afin de pouvoir exploiter plusieurs clés à la fois. Le serveur de réception lit le sélecteur dans l’en-tête DKIM-Signature du message, récupère cette clé publique et vérifie la signature pour confirmer que le message n’a pas été altéré en route et provient bien du domaine signataire. Une signature DKIM valide est aussi l’un des moyens pour un message de s’aligner sur DMARC et de le valider. Les fournisseurs de messagerie comme Gmail et Yahoo attendent des gros expéditeurs qu’ils s’authentifient avec DKIM : un enregistrement publié et correct fait donc partie du chemin vers la boîte de réception.
DKIM se publie par sélecteur, non par domaine : vous devez donc en fournir un. Trouvez-le dans un message reçu du domaine : ouvrez les en-têtes bruts et lisez la balise s= dans la ligne DKIM-Signature. Si aucun en-tête n’est consultable, essayez les sélecteurs courants comme google (Google Workspace), selector1 et selector2 (Microsoft 365), k1 (Mailgun), s1 et s2 (SendGrid), k1, k2 et k3 (Mailchimp), default, ou dkim.
La balise de version. Elle doit indiquer v=DKIM1 et, lorsqu’elle est présente, être la première balise de l’enregistrement. Toute autre valeur signifie que l’enregistrement n’est pas une clé DKIM valide.
Le type de clé. La plupart des enregistrements utilisent k=rsa ; certaines configurations modernes utilisent k=ed25519. Si k= est absent, la valeur par défaut est rsa : une balise k manquante est donc normale.
La clé publique encodée en base64. C’est le cœur de l’enregistrement. Les espaces à l’intérieur sont légaux, car la RFC 6376 autorise le pliage du base64 et un vérificateur les retire avant de décoder ; un caractère qui n’est pas du base64, lui, ne l’est pas. La RFC 8301 fixe un minimum de 1024 bits pour RSA, et 2048 bits est la recommandation actuelle.
Si l’enregistrement existe mais que p= est vide (p=), la clé a été délibérément révoquée conformément à la RFC 6376. C’est différent d’une absence d’enregistrement : un p= vide indique aux vérificateurs de considérer comme invalide toute signature utilisant ce sélecteur.
La requête ne renvoie rien parce que le sélecteur est erroné ou que la clé n’a jamais été publiée. Confirmez le sélecteur exact à partir de la balise s= d’un véritable en-tête DKIM-Signature, puis relancez le contrôle. Chaque sélecteur est indépendant : la bonne clé peut se trouver sous un autre sélecteur.
L’enregistrement est présent mais la valeur p= est vide, ce que la RFC 6376 définit comme une clé révoquée. Les serveurs de réception feront échouer toute signature établie avec ce sélecteur. Republiez l’enregistrement avec la clé publique en cours, ou faites pointer votre plateforme d’envoi vers un sélecteur dont la valeur p= est encore valide.
La valeur p= a été collée sur plusieurs chaînes, ou comporte des espaces et des retours à la ligne parasites. C’est légal : la section 3.6.1 du RFC 6376 autorise le pliage du base64, et un vérificateur retire les espaces avant de le décoder. Ce qui casse vraiment une clé, c’est un caractère qui n’est pas du base64, ou une valeur que votre hébergeur DNS a tronquée sans le dire, et les deux se lisent ici comme une clé corrompue et non comme une clé absente. Découper un long enregistrement TXT en morceaux entre guillemets ne pose pas de problème non plus.
Si l’enregistrement ne commence pas par v=DKIM1, les analyseurs peuvent le rejeter. Vérifiez que la balise de version est présente et placée en premier, les balises étant séparées par des points-virgules.
Une clé RSA de 1024 bits respecte le minimum de la RFC 8301, mais 2048 bits est la recommandation actuelle ; par ailleurs, une balise t=y demande aux serveurs de réception de traiter le courrier signé avec cette clé comme non signé, et pas seulement d’être indulgents en cas d’échec, si bien que DKIM ne peut pas s’aligner pour DMARC tant qu’elle est là. Pour vos envois en production, utilisez une clé de 2048 bits et retirez t=y une fois la signature confirmée.
Lors d’une rotation de clés, le courrier déjà en transit reste signé avec le sélecteur précédent. Supprimer cet enregistrement tout de suite fait échouer la vérification de ces messages. Gardez l’ancien sélecteur publié jusqu’à ce que la file soit vidée.
Toutes les dates et tous les chiffres qu’Unspam publie sur les exigences applicables aux expéditeurs sont regroupés ici et vérifiés dans la documentation de chaque fournisseur. Dernière lecture : 16 août 2026.
| Fournisseur | Quoi | Valeur | S’applique à |
|---|---|---|---|
| Règles pour expéditeurs en masse en vigueur depuis source | février 2024 obligatoire | e-mails vers des adresses Gmail personnelles | |
| Durcissement de l’application depuis source | novembre 2025 observé Google parle d’un processus graduel et progressif, pas d’un interrupteur basculé à une date donnée. | e-mails vers des adresses Gmail personnelles | |
| Considéré comme expéditeur en masse à partir de source | 5 000 obligatoire C’est le chiffre de Google. Yahoo refuse d’en publier un. | e-mails vers des adresses Gmail personnelles | |
| Plafond du taux de plaintes pour spam source | 0,3 % obligatoire Google décrit l’effet comme progressif et non comme un seuil couperet : au-dessus du chiffre recommandé le placement en boîte de réception souffre déjà, et au plafond il souffre davantage. | tous les expéditeurs vers Gmail, pas seulement en masse | |
| Taux de plaintes pour spam à viser source | 0,1 % recommandé Postmaster Tools ne divise pas les plaintes par tout ce que vous avez envoyé. Il les rapporte aux messages signés DKIM parvenus dans la boîte de réception d’un destinataire actif, un expéditeur déjà filtré peut donc voir un taux artificiellement bas. | tous les expéditeurs vers Gmail, pas seulement en masse | |
| Yahoo | Règles pour expéditeurs en masse en vigueur depuis source | février 2024 obligatoire | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo |
| Considéré comme expéditeur en masse à partir de source | non publié Yahoo déclare qu’il ne précisera pas de seuil de volume, aucun chiffre ne peut donc lui être attribué. | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo | |
| Plafond du taux de plaintes pour spam source | 0,3 % obligatoire | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo | |
| Outlook.com | Règles pour expéditeurs en masse en vigueur depuis source | mai 2025 obligatoire | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 |
| Considéré comme expéditeur en masse à partir de source | 5 000 obligatoire La règle s’applique à tout domaine ayant déjà franchi le seuil, elle continue donc de s’appliquer les jours plus calmes. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| Ce qu’il advient des e-mails en échec source | 550 5.7.515 observé Le courrier non conforme est refusé pendant la conversation SMTP au lieu d’être classé dans le dossier indésirables. La page de politiques pour postmasters de Microsoft décrit encore le dossier indésirables comme première étape, un expéditeur peut donc voir l’un ou l’autre, mais c’est le rejet qu’il faut anticiper. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| SPF et DKIM doivent tous deux réussir, pas seulement DMARC source | obligatoire Plus strict que DMARC seul. DMARC est validé dès que SPF ou DKIM est aligné, et Outlook.com demande en plus que les deux contrôles réussissent. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| Apple | Règles pour expéditeurs en masse en vigueur depuis source | février 2025 obligatoire | e-mails vers iCloud Mail, me.com et mac.com |
| En-têtes ARC sur les e-mails transférés source | obligatoire Apple est le seul des quatre à le demander, ce qui est la vraie raison de s’intéresser à ARC. | e-mails vers iCloud Mail, me.com et mac.com |
Unspam lit tout cela à partir de votre seul nom de domaine.
Aucune requête DNS n’y accède. Il faut un vrai message ou un vrai historique d’envoi, et c’est précisément à cela que sert un test de placement en boîte de réception.
