Pourquoi l'authentification email est essentielle
Trois briques qui se complètent
SPF dit quels serveurs ont le droit d'envoyer pour votre domaine. La règle est publiée dans un enregistrement TXT à l'apex. Bien réglé, il limite l'usurpation. Trop permissif, il laisse passer des abus.
DKIM signe vos messages. La clé publique vit dans un TXT sous selector._domainkey. Une signature valide prouve que le message n'a pas été modifié et indique quel domaine l'a signé.
DMARC relie l'adresse visible à SPF et DKIM. Si SPF ou DKIM passe et qu'il est aligné avec le domaine de l'expéditeur, le message est considéré conforme. La politique décide ensuite du traitement en cas d'échec : observation, quarantaine ou rejet.
Ce que voit un serveur destinataire
À la réception, le serveur lit vos enregistrements DNS puis ajoute un en-tête Authentication-Results. On y retrouve spf=pass ou fail, dkim=pass ou fail, dmarc=pass ou fail, avec le domaine évalué. Cet en-tête est votre vérité terrain. Il confirme l'effet réel de vos réglages, au-delà de la théorie.
Ce que change BIMI
BIMI n'est pas un filtre antispam. Il affiche un logo validé quand DMARC est en place avec une politique appliquée. Le logo est réclamé via un enregistrement DNS dédié et parfois un certificat VMC. Résultat : le destinataire identifie mieux votre marque et repère plus vite un faux.
Les erreurs les plus courantes
- Deux SPF au même nom → Fusionnez en une seule valeur
- SPF qui dépasse 10 lookups → Simplifiez les include ou utilisez le SPF Flattener
- Sélecteur DKIM mal orthographié → La clé devient introuvable
- Clé publique tronquée → La vérification échoue silencieusement
- DMARC sans alignement → Le message passe mais ne protège pas l'identité
- Rapports DMARC vers boîte non surveillée → Vous perdez l'observabilité. Utilisez le Monitoring DMARC pour collecter et visualiser les rapports automatiquement
TTL et propagation DNS
Le réseau ne "propage" pas au sens strict. Il met en cache selon le TTL. Un TTL court aide pendant une mise à jour. Un TTL trop court sur la durée surcharge inutilement. Un TTL moyen (3600-86400s) stabilise un réglage validé. Réduisez avant un changement, restaurez ensuite.
Comment utiliser la boîte à outils CaptainDNS
Validateurs de syntaxe SPF, DKIM, DMARC
Les validateurs lisent vos enregistrements bruts et expliquent chaque élément :
SPF : ordre des mécanismes, include, redirect, présence de all, comptage des requêtes DNS, IP et domaines inexistants. L'objectif est de rester sous 10 lookups et d'éviter les boucles.
DKIM : lecture des tags v, k, p, t, s. Vérification de la longueur de clé, détection des coupures, des caractères invalides et rappel des bonnes pratiques de rotation.
DMARC : lecture des tags v, p, sp, adkim, aspf, pct, rua, ruf. Vérification de l'alignement choisi et de la validité des adresses de rapport.
Inspecteurs d'enregistrements en direct
Les inspecteurs résolvent le DNS et affichent la réponse telle qu'elle est vue depuis Internet :
- Inspecteur SPF : déroule la chaîne include, montre les domaines appelés et où la limite serait dépassée
- Inspecteur DKIM : résout le sélecteur, extrait la clé publique et contrôle la cohérence du format
- Inspecteur DMARC : lit _dmarc.domaine, affiche la politique active, les adresses rua/ruf et le pourcentage d'application
Ces outils servent à vérifier le présent, pas la théorie. Idéal pour un ticket ou une mise en production.
Audit de délivrabilité email
Ce contrôle analyse MX, SPF, DKIM et DMARC simultanément pour répondre à une question simple : le domaine est-il prêt à envoyer ? Il pointe aussi la cause la plus probable d'un échec : SPF trop permissif, clé DKIM manquante, politique DMARC non appliquée, alignement strict qui casse sur un sous-domaine, MX qui pointe vers un CNAME.
Générateur d'enregistrement DMARC
Le générateur vous aide à créer des enregistrements DMARC complets et conformes aux RFC :
- Configuration du domaine : saisie simple avec génération automatique de l'hostname _dmarc
- Politiques flexibles : choix entre none, quarantine et reject avec gestion des sous-domaines
- Rapports intégrés : adresses rua/ruf avec validation et conseils d'implémentation
- Options avancées : alignements DKIM/SPF, pourcentages, intervalles et options d'échec
L'outil génère l'enregistrement complet prêt à publier et guide vers l'inspecteur pour vérification post-déploiement.
DMARCbis : préparer la transition vers DMARC v2
DMARCbis succède à la RFC 7489 et élève DMARC au rang de Proposed Standard IETF. Le changement principal : la Public Suffix List est remplacée par un algorithme DNS Tree Walk pour identifier le domaine organisationnel.
Trois tags sont ajoutés (psd, np, t), trois sont supprimés (pct, ri, rf). Le reporting est séparé en trois documents normatifs distincts.
DMARCbis Checker analyse la compatibilité de vos enregistrements DMARC avec le nouveau standard. Il détecte les tags obsolètes, vérifie la découverte via Tree Walk et recommande les ajustements nécessaires.
Migration DMARCbis génère automatiquement un enregistrement conforme au nouveau standard à partir de votre record DMARC actuel, avec un comparatif avant/après.
BIMI opérationnel
Le validateur BIMI contrôle la structure de l'enregistrement, teste l'URL HTTPS du logo, vérifie les contraintes Tiny-PS et télécharge le VMC lorsqu'il est fourni. Associé à un DMARC appliqué en quarantine ou reject, il sécurise l'affichage de votre logo dans les webmails compatibles.
MTA-STS pour la sécurité du transport
MTA-STS (RFC 8461) ajoute une couche de protection critique en imposant le chiffrement TLS pour les emails entrants. Sans MTA-STS, le TLS opportuniste peut être contourné par des attaquants. Avec MTA-STS, les serveurs émetteurs doivent utiliser TLS ou rejeter la livraison.
Outils MTA-STS
Validateur de syntaxe : Collez votre enregistrement DNS TXT et le contenu du fichier de politique. Le validateur vérifie version, mode, patterns MX et directives max_age avant publication.
Inspecteur d'enregistrement : Entrez un domaine pour récupérer l'enregistrement MTA-STS et le fichier de politique en direct. Vérifie les certificats TLS et croise les patterns MX avec les serveurs de messagerie réels.
Générateur : Créez des enregistrements et fichiers de politique MTA-STS conformes. Configurez le mode testing ou enforce, ajoutez les patterns MX, définissez la durée de cache. Sortie prête à copier avec instructions de déploiement.
Hébergement MTA-STS : Laissez CaptainDNS héberger votre fichier de politique MTA-STS. Aucun serveur web à configurer : créez votre politique, vérifiez la propriété du domaine, pointez un CNAME et c'est fait. HTTPS automatique, certificats gérés et mises à jour instantanées quand vous modifiez votre politique.
Déploiement MTA-STS recommandé
- Générez l'enregistrement DNS TXT et le fichier de politique
- Hébergez le fichier de politique : utilisez l'hébergement MTA-STS pour un hébergement sans maintenance, ou hébergez vous-même à
https://mta-sts.votredomaine.com/.well-known/mta-sts.txt - Publiez l'enregistrement DNS TXT à
_mta-sts.votredomaine.com - Commencez en mode testing pour identifier les problèmes sans casser la livraison
- Passez en mode enforce une fois que vous avez vérifié que tous les serveurs MX supportent TLS
- Surveillez avec TLS-RPT pour recevoir les rapports d'échecs
TLS-RPT pour les rapports de transport
TLS-RPT (RFC 8460) complète MTA-STS en recevant des rapports sur les échecs de négociation TLS. Sans ces rapports, vous ne sauriez pas si des emails entrants échouent silencieusement à cause d'un certificat expiré ou d'un problème de configuration.
Validateur de syntaxe : Collez votre enregistrement DNS TXT TLS-RPT et validez la conformité RFC avant publication. Vérification des URIs de rapport mailto et HTTPS.
Inspecteur d'enregistrement : Résolvez le TLS-RPT d'un domaine en direct. Vérifiez les adresses de rapport, y compris les autorisations de réception externe.
Générateur : Créez un enregistrement TLS-RPT valide avec des URIs de rapport mailto et/ou HTTPS. Sortie prête à copier dans votre zone DNS.
Monitoring TLS-RPT : Suivez les rapports TLS-RPT de vos domaines sans quitter CaptainDNS. Visualisez les échecs de négociation TLS, identifiez les certificats problématiques et recevez des alertes en cas d'anomalie.
DANE/TLSA pour l'authentification des certificats
DANE (RFC 6698/7672) lie les certificats TLS aux noms de domaine via des enregistrements DNS TLSA signés par DNSSEC. Contrairement au modèle classique basé sur les autorités de certification, DANE permet au propriétaire du domaine de spécifier exactement quel certificat un serveur doit présenter.
Validateur de syntaxe : Collez un enregistrement TLSA brut et vérifiez les champs usage, selector, matching type et données de certificat avant publication. Détecte les combinaisons non recommandées et les erreurs de format hexadécimal.
Inspecteur d'enregistrement : Entrez un domaine pour vérifier la configuration DANE complète : résolution MX, recherche TLSA, validation DNSSEC, et correspondance avec le certificat TLS du serveur.
Générateur : Créez un enregistrement TLSA à partir de votre certificat PEM ou directement depuis le serveur via STARTTLS. Supports DANE-EE, DANE-TA, SHA-256, SHA-512 et sélecteur SPKI.
Déploiement DANE recommandé
- Activez DNSSEC sur votre domaine (prérequis absolu)
- Générez l'enregistrement TLSA avec le générateur DANE
- Publiez l'enregistrement à
_25._tcp.votremailhost - Vérifiez avec l'inspecteur DANE après propagation
- Activez TLS-RPT pour recevoir les rapports d'échecs DANE
- Planifiez la rotation : mettez à jour le TLSA avant chaque renouvellement de certificat
Générateurs d'enregistrements
Au-delà du générateur DMARC, la boîte à outils couvre la création d'enregistrements pour chaque protocole :
Générateur SPF : Construisez un enregistrement SPF valide en sélectionnant vos fournisseurs email préconfigurés (Google Workspace, Microsoft 365, etc.). Le générateur assemble les mécanismes, vérifie la limite de 10 lookups et produit un enregistrement prêt à publier.
SPF Flattener : Aplatissez vos enregistrements SPF pour éliminer les includes imbriqués. L'outil résout chaque include en adresses IP directes, ce qui réduit le nombre de lookups DNS et évite les erreurs permerror en production.
Générateur DKIM : Générez une paire de clés DKIM (RSA 1024/2048 bits ou Ed25519) et l'enregistrement DNS TXT associé. L'outil produit la clé privée à configurer sur votre serveur et la clé publique à publier dans le DNS.
Générateur BIMI : Créez un enregistrement BIMI DNS avec l'URL de votre logo SVG et le certificat VMC optionnel. L'outil vérifie les prérequis DMARC et guide la publication.
DKIM Selector Finder
Retrouver un sélecteur DKIM peut être fastidieux quand on ne connaît pas son nom. Le DKIM Selector Finder interroge automatiquement une base de sélecteurs connus (Google, Microsoft, Amazon SES, etc.) et teste chacun contre votre domaine. Résultat : la liste des sélecteurs actifs avec leurs clés publiques, sans avoir à deviner.
Vérification de réputation et connectivité
Blacklists IP et domaine
Un SPF et DKIM parfaits ne servent à rien si votre IP ou votre domaine figure sur une blacklist. Le vérificateur blacklist IP interroge les principales DNSBL (Spamhaus, Barracuda, SORBS, etc.) et le vérificateur blacklist domaine contrôle les listes URI (SURBL, URIBL, etc.). Un domaine blacklisté voit ses emails rejetés ou classés en spam, indépendamment de l'authentification.
SMTP/MX Tester
Le testeur SMTP vérifie la connectivité de vos serveurs MX : résolution DNS, connexion SMTP, banner, support STARTTLS, validité du certificat TLS et détection d'open relay. C'est le dernier maillon : l'authentification DNS est correcte, mais le serveur est-il réellement joignable et sécurisé ?
Méthode conseillée pour une mise en production
- Documenter l'état initial : captures DNS et exemples d'Authentication-Results
- Réduire le TTL avant modification (300-600s)
- Déployer SPF propre et unique, vérifier avec l'inspecteur
- Publier la clé DKIM sur un nouveau sélecteur, tester la signature
- Activer DMARC en p=none, analyser les rapports, corriger puis appliquer
- Ajouter BIMI quand DMARC est appliqué et que le logo/VMC passent la validation
- Restaurer un TTL confortable (3600-86400s) quand tout est stable
Suivi et vie courante
Les configurations évoluent avec les prestataires, sous-domaines, microservices et campagnes ponctuelles. Gardez un cycle simple : contrôle régulier, lecture des rapports, rotation de clés, nettoyage des include et sélecteurs obsolètes. Un changement doit toujours laisser une trace : date, auteur, valeur précédente, valeur nouvelle, raison. Cela raccourcit chaque diagnostic.
Outils complémentaires
| Outil | Utilité |
|---|---|
| Vérificateur de propagation DNS | Confirmer que vos modifications DNS sont visibles mondialement |
| Recherche DNS | Interroger n'importe quel type d'enregistrement DNS |
| Whois IP | Identifier le propriétaire d'une adresse IP |
| Vérificateur blacklist IP | Vérifier si votre IP est sur une liste noire |
| Vérificateur blacklist domaine | Vérifier si votre domaine est blacklisté |
| Monitoring DMARC | Collecter et visualiser les rapports DMARC agrégés de vos domaines |
| SMTP/MX Tester | Tester la connectivité SMTP, STARTTLS et certificats TLS |
Ressources utiles
- RFC 7208 - Sender Policy Framework (SPF) (spécification officielle)
- RFC 6376 - DomainKeys Identified Mail (DKIM) (spécification officielle)
- RFC 7489 - Domain-based Message Authentication (DMARC) (spécification officielle)
- RFC 8461 - MTA Strict Transport Security (MTA-STS) (spécification officielle)
- RFC 8460 - SMTP TLS Reporting (TLS-RPT) (spécification officielle)
- RFC 6698 - DNS-Based Authentication of Named Entities (DANE) (spécification officielle)
- RFC 7672 - SMTP Security via Opportunistic DANE TLS (DANE pour SMTP)
- Google - Directives pour expéditeurs d'emails (exigences Gmail)
- Microsoft - Authentification email dans Microsoft 365 (guide Outlook/M365)