Un site peut fonctionner parfaitement avec une messagerie propice à l’usurpation ou incapable de livrer les réinitialisations de mot de passe. Le problème est dans les enregistrements et services d’envoi, invisible dans une inspection visuelle. Protégez le domaine sans rejeter les messages légitimes.
Le module DNS e-mail interroge MX, TXT, DMARC, CAA et découverte MTA-STS du nom ciblé. Il consigne observations et erreurs. Vérifiez le domaine qui envoie réellement : www.example.com n’est pas automatiquement un audit complet du courrier de example.com.
Périmètre de cet audit
Ce qui peut être mesuré
- MX, SPF TXT, _dmarc TXT, CAA et découverte _mta-sts observés sur le nom interrogé.
- Terminaisons SPF permissives ou neutres, comptage direct des mécanismes sollicitant DNS et politique DMARC d’observation.
- Contrôles réussis pris en charge et erreurs DNS conservées comme preuves.
Ce qu’il ne prouve pas
- Le module natif n’envoie pas de messages, n’examine pas le placement en boîte et ne vérifie pas tous les sélecteurs DKIM.
- Le comptage SPF ne développe pas récursivement les includes ; une valeur basse ne garantit pas le respect de la limite.
- Un TXT MTA-STS ne prouve pas le bon fonctionnement du fichier HTTPS ni du TLS des serveurs de courrier.
Analysez une cible autorisée et vérifiée avec les modules effectifs de votre offre et profil. Ces contrôles portent sur la configuration publique ; connexion fournisseur et preuve de livraison restent séparées.
Inventoriez les expéditeurs avant de changer DNS
Listez messagerie interne, assistance, transactionnel, facturation, marketing et anciens services encore actifs. Notez domaine From visible, expéditeur d’enveloppe, domaine de signature DKIM et responsable. Demandez les exigences DNS actuelles à chaque fournisseur ; ne devinez pas un include à partir d’une autre entreprise.
Gardez nom, résultat et heure de requête. Un délai DNS dépassé n’est pas une réponse faisant autorité sur l’absence d’enregistrement. Vérifiez les surprises avec le fournisseur DNS et tenez compte des caches. MX décrit la réception ; on peut envoyer sans MX. L’absence d’alerte dans ce cas ne prouve pas un envoi sécurisé.
Interprétez les politiques avec proportion
| Observation | Priorité habituelle | Importance |
|---|---|---|
| SPF finit par +all | Élevée | Tout expéditeur est autorisé |
| SPF ou DMARC non observé sur domaine de courrier | Souvent moyenne ; vérifier domaine et requête | Politique anti-usurpation manquante |
| Alerte de limite SPF | Moyenne | Évaluation susceptible d’échouer |
| DMARC p=none | Faible ; étape éventuellement volontaire | Observation sans demande de quarantaine ou rejet |
| CAA ou découverte MTA-STS absent | Généralement faible | Renforcement supplémentaire à étudier |
Une faiblesse ne prouve pas qu’un message falsifié est arrivé. Un contrôle de présence réussi ne garantit pas la livraison. Priorisez liens de connexion, factures et support, dont l’abus affecte directement la confiance.
Corrigez SPF sans perdre les bons expéditeurs
SPF évalue l’expéditeur connecté selon le domaine d’enveloppe, pas directement le From visible. Publiez une seule politique cohérente avec les prestataires réellement utilisés. Évitez +all ; choisissez la règle finale après test des sources légitimes.
Le protocole limite à dix les termes sollicitant DNS pendant l’évaluation, y compris les includes imbriqués et redirections. Le comptage textuel de Sitelemetry est un avertissement précoce, pas une évaluation récursive. Vérifiez la chaîne entière avec les fournisseurs. Retirez d’abord expéditeurs abandonnés et mécanismes inutiles. Remplacer aveuglément les includes par des IP fixes crée un risque de maintenance lorsque l’infrastructure change.
Faites évoluer DMARC progressivement
DMARC lie le From visible à une authentification SPF ou DKIM alignée. L’un des deux mécanismes alignés peut suffire ; les deux ne sont pas toujours requis. Les sélecteurs DKIM sont propres au fournisseur : une analyse publique ne peut deviner toutes les clés.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comExemple de politique d’observation : remplacez la boîte par une adresse contrôlée dont vous pouvez traiter les rapports. Une destination externe peut demander une autorisation DNS. Analysez les rapports et tous les flux, y compris les effets des transferts. Corrigez l’alignement avant quarantine ou reject. Un déploiement progressif évite de perdre factures et réinitialisations en imposant un rejet avec un inventaire incomplet.
CAA et MTA-STS répondent à des questions différentes
CAA définit les autorités autorisées à émettre des certificats. Adaptez-le aux fournisseurs réels, certificats CDN et besoins génériques. Une restriction imprudente peut bloquer le renouvellement. Son absence permet un renforcement ; elle ne prouve pas qu’un attaquant détient un certificat.
MTA-STS permet aux expéditeurs participants d’appliquer une politique TLS au courrier entrant. Le TXT n’est qu’un élément : fichier HTTPS, motifs MX et certificats des serveurs doivent concorder. Testez l’ensemble avant application. Ce n’est pas HTTPS du site, et l’absence de TXT ne prouve pas que tout courrier circule sans chiffrement.
Validez DNS et livraison réelle
- Sauvegardez valeurs DNS et responsables des services.
- Publiez le changement validé chez le fournisseur faisant autorité et confirmez le nom interrogé.
- Vérifiez après les durées de cache et reprenez le même périmètre.
- Envoyez des messages contrôlés depuis chaque service vers vos propres comptes de test.
- Examinez authentification côté destinataire et rapports DMARC ; confirmez mots de passe, factures et réponses de support.
Séparez politique et suivi de livraison. Réputation, filtres et contenu comptent encore lorsque l’authentification réussit. Documentez erreurs DNS, sélecteurs non évalués et services non testés pour qu’un résumé vert ne masque pas les limites.
Questions fréquentes
Sitelemetry vérifie-t-il que tous les messages arrivent en boîte ?
Non. Le DNS public fournit des signaux de configuration. La livraison exige messages contrôlés, résultats d’authentification du destinataire et données de fournisseur ou de boîte.
DMARC p=none est-il une mauvaise configuration ?
Cela peut être une étape d’observation volontaire. Elle ne demande pas d’application ; analysez les rapports et finalisez l’alignement avant de durcir.
SPF peut-il dépasser la limite malgré un contrôle réussi ?
Oui. Le contrôle compte les mécanismes visibles sans évaluer tous les includes récursivement. Vérifiez les politiques imbriquées avant de déclarer la conformité complète.
Sources et lectures
- RFC 7208 : Sender Policy Frameworkwww.rfc-editor.org
- RFC 9989 : DMARCwww.rfc-editor.org
- RFC 8659 : autorisation DNS des autorités de certificationwww.rfc-editor.org
- RFC 8461 : sécurité stricte SMTP MTAwww.rfc-editor.org
- RFC 9990 : rapports agrégés DMARCwww.rfc-editor.org
Rédigé par l’équipe Sitelemetry et vérifié par rapport au périmètre du produit et aux sources primaires citées. Les exemples sont illustratifs, sauf mention explicite d’un cas observé.
