Recenser tous les services d’envoi
Avant de modifier DNS, listez les systèmes envoyant avec votre domaine : boîtes mail, formulaire du site, service transactionnel, lettres d’information, facturation et assistance. Le site et les boîtes peuvent dépendre de fournisseurs différents. Déplacer le site ne déplace pas nécessairement le service qui signe ou transmet les messages.
Pour chaque émetteur, notez domaine visible dans From, domaine d’enveloppe utilisé pour les retours, domaine de signature DKIM et instructions actuelles. Cet inventaire vaut mieux qu’ajouter chaque valeur proposée. Retirer un ancien include ou remplacer un sélecteur sans vérifier son émetteur peut interrompre des messages qui fonctionnaient auparavant.
Séparer DNS et authentification des messages
Un vérificateur de domaine récupère la configuration publiée. Il peut montrer SPF, une clé publique DKIM ou DMARC à un nom précis. C’est une étape de diagnostic, mais cela ne prouve pas qu’un message réel venait de la bonne IP, possédait une signature valide ou respectait l’alignement.
L’outil Savvy Toolkit inspecte les noms exacts saisis. Il n’envoie pas de courrier, ne lit pas de boîte, ne vérifie pas le corps d’un message, ne parcourt pas toutes les dépendances SPF et ne prétend pas découvrir les politiques DMARC héritées. Interprétez chaque réponse dans ce périmètre. Absence d’enregistrement, avertissement de syntaxe et délai DNS dépassé sont des problèmes distincts, pas trois échecs d’authentification équivalents.
Les enregistrements ne vérifient pas un message
Publier une politique SPF au bon nom
SPF déclare les systèmes autorisés à envoyer avec l’identité d’enveloppe concernée. Le TXT commence par v=spf1. Deux enregistrements SPF indépendants au même nom sont incorrects ; ne gardez pas les deux en espérant que le destinataire choisisse. Combinez seulement les mécanismes nécessaires aux émetteurs actifs selon leurs instructions.
Une interface DNS peut découper un long TXT en plusieurs chaînes entre guillemets. Leur concaténation forme un enregistrement et ne constitue pas deux politiques indépendantes. Vérifiez aussi le nom : un sous-domaine de retours peut avoir une politique différente du domaine visible. Copier la politique principale au mauvais nom ne corrige pas cette relation.
Comprendre mécanismes et limites SPF
ip4 et ip6 autorisent des plages d’adresses. include consulte une autre politique, tandis que redirect délègue l’évaluation selon ses règles. Ils ne sont pas interchangeables. Le mécanisme all et son qualificateur indiquent le résultat des émetteurs qui n’ont pas correspondu avant. Choisissez ce comportement avec l’inventaire complet.
L’évaluation est bornée. SPF limite à dix les termes provoquant des recherches DNS, dépendances imbriquées comprises. include, a, mx, ptr, exists et redirect en font partie ; ni chaque caractère ni chaque plage IP ne se compte ainsi. Compter uniquement les include visibles ne vérifie pas le parcours complet. Évitez de figer les IP d’un fournisseur sans mise à jour fiable.
Trouver le véritable sélecteur DKIM
Une signature DKIM indique son domaine par d= et son sélecteur par s=. La clé se trouve normalement à sélecteur._domainkey.domaine-de-signature. L’émetteur choisit le sélecteur et peut le changer pendant une rotation. Aucun résultat pour un nom deviné comme default ne prouve pas l’absence de signature.
Lisez un message légitime reçu ou l’écran de configuration du fournisseur. Utilisez le domaine d= de cette signature, même différent de l’expéditeur visible. Certains services publient un CNAME vers leur clé gérée. Gardez le nom demandé et l’alias retourné pour distinguer délégation et données absentes dans une demande d’assistance.
Une erreur pratique consiste à coller le nom DKIM complet dans un champ qui attend seulement le sélecteur. Pour mail2026._domainkey.example.com, le sélecteur est mail2026 et le domaine de signature est example.com. Gardez ces valeurs séparées. Comparez aussi le nom interrogé à celui prévu par le fournisseur avant toute modification. Une faute dans la requête peut expliquer une réponse absente sans nécessiter de changement dans une zone DNS qui fonctionne déjà.
Une clé publique ne vérifie pas le message
L’enregistrement DNS fournit les informations nécessaires à la vérification des signatures. L’émetteur doit encore posséder la clé privée et signer correctement les éléments concernés. Des changements en transit peuvent affecter la vérification. Lire une clé n’authentifie ni corps, ni objet, ni expéditeur précis.
Un p= vide peut révoquer une clé DKIM. Une ancienne clé peut aussi être remplacée lors d’une rotation. Gardez les sélecteurs précédents pendant le chevauchement recommandé au lieu de les supprimer aussitôt. Les clés privées restent dans le système d’envoi, jamais dans un TXT public, un formulaire web ou une capture d’assistance.
Lire DMARC avec l’alignement
DMARC relie l’authentification au domaine visible du champ From. Un SPF réussi pour un domaine de retours sans rapport ne suffit pas. Une signature DKIM valide d’un domaine étranger n’est pas automatiquement alignée. Le message peut réussir DMARC grâce à SPF réussi et aligné ou DKIM réussi et aligné.
none, quarantine et reject décrivent le traitement demandé pour les messages échouant à DMARC. p=none est un choix de surveillance, pas la preuve que les messages légitimes échouent. Une politique plus stricte peut perturber des émetteurs mal configurés. Examinez inventaire et résultats réels avant de renforcer. Le destinataire peut également appliquer son propre traitement.
Utiliser la spécification actuelle
RFC 9989 remplace l’ancienne description centrale RFC 7489. La découverte de politique décrit désormais un parcours DNS borné plutôt qu’une dépendance exclusive à une liste de suffixes publics. La spécification ajoute t pour les tests et retire pct du format central. Certains anciens outils et destinataires peuvent encore suivre le modèle précédent.
Ne copiez pas un ancien exemple de déploiement progressif sans vérifier les consignes actuelles du fournisseur. Cet outil montre le nom _dmarc exact interrogé, sans découvrir toutes les politiques héritées ni calculer l’alignement depuis un domaine seul. Les rapports agrégés sont décrits dans RFC 9990. Une destination de rapports d’un autre domaine exige aussi une autorisation adaptée.
Vérifier DNS puis envoyer de vrais messages
Gardez une copie des valeurs précédentes et changez une partie à la fois. Vérifiez compte faisant autorité, nom, type et valeur avant de sauvegarder. Un champ qui ajoute automatiquement la zone peut doubler le domaine quand vous collez un nom complet. Le tableau de bord semble correct alors que la publication est faite au mauvais nom.
Après publication, comparez les réponses publiques et tenez compte du cache selon l’ancienne durée de vie. Envoyez ensuite un message légitime de chaque service à un compte contrôlé. Lisez l’authentification du destinataire et comparez domaine d’enveloppe, DKIM d= et s=, puis From visible. Une recherche DNS ne remplace pas cette étape.
Diagnostiquer la livraison sans la promettre
SPF, DKIM et DMARC participent à la livraison mais ne forment pas une note complète de réputation. Les destinataires considèrent aussi comportement d’envoi, plaintes, format, TLS, DNS inverse et règles locales. Lisez le code de retour et les exigences actuelles avant d’attribuer chaque rejet à un TXT.
Un rapport utile contient domaine, sélecteur, noms interrogés, enregistrements observés, heures et résultat d’authentification expurgé d’un message contrôlé. Ne publiez ni boîte complète ni clé privée. Corrigez la divergence, testez chaque émetteur et limitez la conclusion aux enregistrements et messages vérifiés. Cela ne garantit pas l’arrivée de tous les futurs courriers.