Commencez par l'identité que le destinataire vérifiera
Une modification d'authentification de courrier électronique commence par un nom, un enregistrement type et un opérateur responsable. « Ajouter une authentification à notre domaine » est trop large pour identifier le bon éditeur DNS ou la réponse dont un destinataire a besoin. Un service marketing peut signer avec un domaine, en utiliser un autre pour son enveloppe SMTP et en afficher un troisième dans le champ De. Un inventaire doit préserver ces différences avant que quiconque ne modifie une zone.
Pour SPF, obtenez le domaine utilisé par le SMTP COURRIER DE identité; le Identité HELO a sa propre vérification, y compris le cas de chemin inverse nul. Recherchez le domaine applicable pour TXT . Ne sélectionnez pas le propriétaire SPF simplement en lisant l’adresse De visible. RFC 7208 , sections 2.3 à 2.4 et 3.1.
Pour DKIM, prends le sélecteur depuis s= et le domaine de signature de d= dans la signature. Le nom de la recherche de clé est sélecteur, puis _domainkey, puis le domaine de signature. Pour DMARC, la découverte de règles commence par une requête TXT en dessous _dmarc au domaine de l'auteur et peut continuer à utiliser le domaine spécifié Parcours de l'arborescence DNS. L’absence d’un dossier initial n’établit pas en soi qu’aucune politique ne s’applique. RFC 6376 , section 3.6.2; RFC 9989 , sections 4.5 et 4.10.
Séparez le nom du propriétaire des personnes qui possèdent le changement
Dans DNS , le propriétaire de l'enregistrement est un nom de domaine. Dans un ticket de change, son propriétaire est souvent une personne ou une équipe. Enregistrez les deux. Le registraire de domaine, l'hôte DNS faisant autorité, l'administrateur de la plateforme d'envoi et le propriétaire de domaine approbateur peuvent être des parties différentes. L'accès à l'enregistrement ne constitue pas une preuve qu'une console DNS particulière contrôle la réponse publique actuelle.
Identifiez les serveurs faisant autorité délégués pour la zone contenant le nom demandé. Un sous-domaine peut avoir sa propre délégation, donc l'éditeur correct peut différer de l'éditeur du domaine parent. Conservez ensemble la zone, le nom complet du propriétaire, le type demandé, les données proposées et l'opérateur responsable. La délégation DNS définit où l'autorité change ; il ne suit pas les limites de l'équipe de support d'une organisation. RFC 1034 , sections 4.2 et 4.2.1.
Demandez à l'administrateur de l'expéditeur de fournir les valeurs émises par le compte et d'expliquer les alias éventuels. Un fournisseur CNAME l'instruction pointe un nom vers un autre nom ; ce n'est pas la même opération que de déléguer une zone enfant avec des enregistrements NS. Identifiez qui gère l’alias cible ainsi que qui peut modifier l’enregistrement côté client.
Lire l'ensemble des records publiés plutôt que l'apparence de l'éditeur
Les consoles DNS acceptent souvent une étiquette d'hôte relative et ajoutent le nom de la zone. Un nom pleinement qualifié copié et saisi dans le mauvais mode peut donc atterrir chez un propriétaire involontaire. Vérifiez le nom absolu final, y compris chaque sous-domaine et chaque étiquette de trait de soulignement. La valeur sauvegardée par un éditeur est une preuve de préparation ; une réponse DNS faisant autorité est une preuve de publication.
La présentation TXT nécessite également du soin. Un seul enregistrement de ressource TXT peut contenir plusieurs chaînes de caractères. Pour SPF , ces chaînes sont concaténées sans insérer d'espaces. Cela diffère de la publication de deux Enregistrements SPF chez le même propriétaire, ce qui est interdit. Préservez les limites des enregistrements lors de la révision d’une exportation ou d’une capture d’écran plutôt que de compter les guillemets. RFC 1035 , section 3.3.14; RFC 7208 , sections 3.2 à 3.3.
Enregistrements MX identifier les échangeurs de courrier pour recevoir le courrier. Ils ne prouvent pas de manière indépendante quel service sortant est autorisé ni quelle clé signe un message. An SPF policy can refer to MX through a mechanism, but that relationship must come from the actual policy, not from an assumption that all mail-related DNS records authenticate sending. RFC 1035 , section 3.3.9; RFC 7208 , section 5.4.
Travailler sur un inventaire de propriété fictif
Supposons qu'un service fictif envoie du courrier avec From news@example.com, MAIL DE bounce@mail.example.com, et un Signature DKIM contenant d=example.com; s=nov26. L'inventaire initial comporte trois questions TXT distinctes : mail.example.com, nov26._domainkey.example.com, et _dmarc.example.com. Ce sont des noms et des identités illustratifs, et non des messages observés ou des valeurs de production recommandées.
L'administrateur de messagerie confirme l'itinéraire et le sélecteur prévus. L'administrateur DNS vérifie quelle zone contient chaque nom et si un alias requis par le fournisseur modifie le chemin de recherche. Le propriétaire du domaine approuve la portée. Si le sélecteur est émis par un fournisseur, celui-ci doit conserver la clé privée correspondante ; seul le matériel à clé publique appartient au DNS . Une clé privée ne doit jamais être copiée dans le ticket ou dans un enregistrement TXT public.
Une ligne d'inventaire doit distinguer « fourni par le service », « présent dans DNS faisant autorité » et « observé sur le courrier reçu ». Laisser une de ces colonnes inconnue est plus utile que de cocher prématurément une seule case « authentifié ».
Recueillir des preuves avant de clôturer le changement
Les contrôles proposés sont creusez @AUTH_IP nov26._domainkey.example.com . TXT +norécurse et creusez @RESOLVER_IP nov26._domainkey.example.com . TXT. Remplacez les espaces réservés en majuscules par des points de terminaison approuvés. Répétez l’opération pour chaque propriétaire réel et serveur faisant autorité concerné. Conservez l'heure UTC, l'adresse du serveur, la question, le code de réponse, les indicateurs, les sections de réponse et d'autorité, les TTL et toute chaîne d'alias. Ces commandes n'ont pas été exécutées pour cet article.
Si l'autorité et la récursion ne sont pas d'accord, étudiez la cohérence de la publication, la mise en cache et le chemin du résolveur avant d'ajouter des enregistrements en double. Une réponse DNS ne peut toujours pas prouver qu'une signature est vérifiée, que SPF autorise l'adresse IP d'envoi réelle ou DMARC s'aligne. Clôturez ces questions avec un message reçu contrôlé et des résultats de récepteur de confiance. Les transcriptions horodatées faisant autorité et récursives restent une porte ouverte de preuves originales pour ce projet documentaire.