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é
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.
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.
Déploiement MTA-STS recommandé
- Générez l'enregistrement DNS TXT et le fichier de politique
- Hébergez le fichier de politique à
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
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é |
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)
- Google - Directives pour expéditeurs d'emails (exigences Gmail)
- Microsoft - Authentification email dans Microsoft 365 (guide Outlook/M365)