Paul Mockapetris et le DNS : comment l’Internet a obtenu des noms humains

Pourquoi le DNS concerne tout le monde qui utilise Internet

Chaque fois que vous tapez une adresse web, cliquez sur un lien ou envoyez un e‑mail, vous comptez sur une idée simple : les humains doivent pouvoir utiliser des noms mémorables, tandis que les ordinateurs se chargent de trouver la bonne machine.

Le DNS résout un problème quotidien : les ordinateurs communiquent avec des adresses numériques (adresses IP) comme 203.0.113.42, mais les gens ne veulent pas mémoriser des suites de chiffres. Vous voulez retenir example.com, pas l'adresse numérique que ce site utilise aujourd'hui.

DNS, en une phrase

Le Domain Name System (DNS) est le « carnet d'adresses » d'Internet qui traduit des noms de domaine lisibles par l'humain en adresses IP que les ordinateurs utilisent pour se connecter.

Cette traduction semble mineure, mais c'est la différence entre un Internet utilisable et un annuaire téléphonique entièrement composé de chiffres.

À quoi s'attendre dans ce guide

Ceci est une visite non technique — aucun bagage réseau requis. Nous verrons :

• L'idée de base derrière le DNS et pourquoi il était nécessaire
• Les rôles clés (votre appareil, les résolveurs DNS et les serveurs autoritatifs)
• Les éléments que vous rencontrerez vraiment en gérant un site ou des e‑mails
• Les questions de sécurité et de confiance que soulève le DNS (et les outils qui aident)

En chemin, vous rencontrerez Paul Mockapetris, l'ingénieur qui a conçu le DNS au début des années 1980. Son travail importe parce qu'il n'a pas seulement créé un nouveau format de nommage : il a conçu un système capable de s'étendre quand Internet est passé d'un petit réseau de recherche à quelque chose utilisé par des milliards de personnes.

Si votre site est déjà « tombé », si vous avez déjà attendu qu'un changement de domaine « se propage » ou si vous vous êtes demandé pourquoi les réglages d'e‑mail demandent des entrées DNS mystérieuses, vous avez déjà rencontré le DNS côté utilisateur. Le reste de cet article explique ce qui se passe en coulisses — clairement et sans jargon.

Avant le DNS : quand un seul fichier partagé devait nommer tout

Bien avant que quelqu'un tape une adresse web familière, les réseaux initiaux avaient un problème plus simple : comment atteindre une machine précise ? Les ordinateurs pouvaient communiquer via des adresses IP (des nombres comme 10.0.0.5), mais les humains préféraient des noms d'hôte — des étiquettes courtes comme MIT-MC ou SRI-NIC plus faciles à retenir et partager.

Le « service de noms » originel : HOSTS.TXT

Pour l'ARPANET, la solution fut un fichier partagé unique appelé HOSTS.TXT. C'était essentiellement une table de correspondance : une liste de noms d'hôte associés à leurs adresses IP.

Chaque ordinateur conservait une copie locale de ce fichier. Si vous vouliez vous connecter à une machine par son nom, votre système vérifiait HOSTS.TXT et trouvait l'adresse IP correspondante.

Cela fonctionnait au départ parce que le réseau était petit, les changements relativement rares et il existait un endroit clair pour récupérer les mises à jour.

Pourquoi cela a cessé de fonctionner

À mesure que davantage d'organisations rejoignirent le réseau, l'approche commença à fléchir sous la croissance normale :

• Les mises à jour devinrent constantes. De nouvelles machines apparaissaient, les adresses changeaient et les noms devaient être ajustés.
• Les conflits de noms se multiplièrent. Deux groupes pouvaient choisir le même nom d'hôte sans s'en apercevoir.
• Le délai de distribution provoquait des pannes. Si votre copie de HOSTS.TXT était obsolète, un nom d'hôte pouvait pointer vers la mauvaise adresse — ou vers nulle part.

Le problème central était la coordination. HOSTS.TXT ressemblait à un carnet d'adresses partagé pour le monde entier. Si tout le monde dépend d'un même carnet, chaque correction implique une édition globale, et tout le monde doit télécharger la version la plus récente rapidement. Une fois le réseau arrivé à une certaine taille, ce modèle « un fichier pour tout » devint trop lent, trop centralisé et trop sujet aux erreurs.

Le DNS n'a pas remplacé l'idée d'associer des noms à des numéros — il a remplacé la façon fragile dont cette association était maintenue et distribuée.

Paul Mockapetris : l'ingénieur derrière une idée de nommage évolutive

Au début des années 1980, l'Internet passait d'un petit réseau de recherche à quelque chose de plus large, désordonné et partagé. De plus en plus de machines arrivaient, les organisations voulaient l'autonomie, et les gens avaient besoin d'un moyen plus simple d'atteindre des services que de mémoriser des adresses numériques.

Paul Mockapetris, travaillant dans ce contexte, est largement reconnu comme le concepteur du DNS. Sa contribution n'était pas un produit flamboyant : c'était une réponse d'ingénierie à une question très pragmatique : comment garder les noms utilisables quand le réseau continue de grandir ?

L'idée centrale : le nommage doit pouvoir évoluer

Un système de nommage paraît simple jusqu'à ce que vous vous représentiez ce que « simple » signifiait alors : une liste partagée unique de noms que tout le monde devait télécharger et tenir à jour. Cette approche casse dès que le changement devient constant. Chaque nouvel hôte, renommage ou correction se transforme en travail de coordination pour tout le monde.

L'intuition clé de Mockapetris fut que les noms ne sont pas que des données ; ce sont des accords partagés. Si le réseau s'étend, le système pour établir et distribuer ces accords doit s'étendre lui aussi — sans exiger que chaque ordinateur récupère constamment une liste maîtresse.

Un système distribué, pas un fichier plus gros

Le DNS a remplacé l'idée d'« un fichier autoritatif » par une conception distribuée :

• La responsabilité est divisée : différentes organisations gèrent leurs propres parties de l'espace de noms.
• Les réponses sont découvertes en interrogeant les serveurs appropriés, plutôt qu'en copiant le monde entier localement.
• Les résultats peuvent être mis en cache pour que la plupart des recherches soient rapides, tout en permettant aux changements de se propager avec le temps.

C'est la finesse discrète : le DNS n'a pas été conçu pour être astucieux, il a été conçu pour continuer à fonctionner sous des contraintes réelles — bande passante limitée, changements fréquents, de nombreux administrateurs indépendants et un réseau qui refusait d'arrêter de croître.

Les objectifs de conception qui ont façonné le DNS

Le DNS n'a pas été inventé comme un raccourci ingénieux — il a été conçu pour résoudre des problèmes pratiques très concrets qui apparaissaient à mesure que l'Internet grandissait. L'approche de Mockapetris fut de définir des objectifs clairs d'abord, puis de bâtir un système de nommage capable de tenir la distance pendant des décennies.

Les objectifs, en langage simple

• Évolutif : il devait fonctionner non seulement pour des centaines d'ordinateurs, mais pour des millions (et éventuellement des milliards) de noms.
• Distribué : aucun fichier maître unique ou machine centrale ne pouvait être responsable de tout.
• Fiable : le système devait continuer à répondre même si certains serveurs étaient en panne ou inaccessibles.
• Facile à gérer : les organisations devaient pouvoir mettre à jour leurs propres noms sans demander à un administrateur global d'éditer une énorme liste.

Délégation : la « sauce secrète »

Le concept clé est la délégation : différents groupes gèrent différentes parties de l'arbre des noms.

Par exemple, une organisation gère ce qui se trouve sous .com, un registrar vous aide à réserver example.com, puis vous (ou votre fournisseur DNS) contrôlez les enregistrements pour www.example.com, mail.example.com, etc. Cela répartit clairement la responsabilité, de sorte que la croissance ne crée pas de goulot d'étranglement.

Conçu pour survivre aux pannes

Le DNS part du principe que des problèmes surviendront — serveurs plantent, réseaux se partitionnent, routages changent. Il s'appuie donc sur plusieurs serveurs autoritatifs pour un domaine et sur la mise en cache dans les résolveurs, de sorte qu'une panne temporaire ne casse pas immédiatement toutes les requêtes.

Ce qu'est (et n'est pas) le DNS

Le DNS traduit des noms conviviaux en données techniques, le plus célèbre étant les adresses IP. Il n'est pas « l'Internet lui‑même » — c'est un service de nommage et de recherche qui aide vos appareils à trouver où se connecter.

Le DNS en une image : une hiérarchie de noms

Le DNS rend les noms gérables en les organisant comme un arbre. Plutôt que d'avoir une liste gigantesque où chaque nom doit être unique au niveau mondial (et quelqu'un doit la contrôler), le DNS casse le nommage en niveaux et délègue la responsabilité.

La hiérarchie : racine → TLD → domaine → sous‑domaine

Un nom DNS se lit de droite à gauche :

• Racine : le point invisible à la fin de chaque nom (souvent omis). www.example.com. se termine techniquement par un .
• TLD (Top‑Level Domain) : .com, .org, .net, codes pays comme .uk
• Domaine : example dans example.com
• Sous‑domaine / hôte : www dans www.example.com

Ainsi www.example.com se décompose en :

• com (le TLD)
• example (le domaine enregistré sous .com)
• www (un label créé et contrôlé par le propriétaire du domaine)

Pourquoi une hiérarchie aide

Cette structure réduit les conflits parce que les noms n'ont besoin d'être uniques que dans leur parent. De nombreuses organisations peuvent avoir un www parce que www.example.com et www.another-example.com ne se chevauchent pas.

Elle répartit aussi la charge de travail. Les opérateurs de .com n'ont pas à gérer les enregistrements de chaque site ; ils indiquent seulement qui est responsable de example.com, et ensuite le propriétaire de example.com gère les détails.

« Zone » en langage simple

Une zone est simplement une partie gérable de cet arbre — les données DNS qu'une entité a la responsabilité de publier. Pour beaucoup d'équipes, « notre zone » signifie « les enregistrements DNS pour example.com et les sous‑domaines que nous hébergeons », stockés chez leur fournisseur DNS autoritatif.

Qui fait quoi : résolveurs, serveurs autoritatifs et vous

Quand vous tapez le nom d'un site dans un navigateur, vous ne demandez pas « à Internet » directement. Quelques acteurs spécialisés partagent le travail pour que la réponse soit trouvée rapidement et de façon fiable.

Les acteurs principaux

Vous (votre appareil et votre navigateur) débutez avec une demande simple : « Quelle adresse IP correspond à example.com ? » Votre appareil ne connaît généralement pas encore la réponse et ne veut pas interroger une douzaine de serveurs pour l'obtenir.

Un résolveur récursif fait la recherche à votre place. Il est généralement fourni par votre FAI, votre service informatique ou un résolveur public. Le principal avantage : il peut réutiliser des réponses mises en cache d'interrogations précédentes, ce qui accélère les choses pour tous ceux qui l'utilisent.

Les serveurs DNS autoritatifs sont la source de vérité pour un domaine. Ils ne « cherchent » pas sur Internet ; ils détiennent les enregistrements officiels qui indiquent quelles IP, quels serveurs mail ou quels jetons de vérification appartiennent à ce domaine.

Une recherche, étape par étape (niveau élevé)

1. Votre appareil interroge son résolveur récursif configuré pour example.com.
2. Si le résolveur a déjà une réponse fraîche en cache, il répond immédiatement.
3. Sinon, le résolveur demande à la hiérarchie DNS où trouver les serveurs autoritatifs pour ce domaine (en partant du haut et en affinant).
4. Le résolveur atteint le serveur autoritatif du domaine, obtient la réponse finale et la retourne à votre appareil.
5. Votre navigateur utilise cette adresse IP pour se connecter au site.

« Récursif » vs « autoritatif », en une analogie

Pensez au résolveur récursif comme à un bibliothécaire qui peut chercher pour vous (et se souvient des réponses populaires), tandis qu'un serveur autoritatif est le catalogue officiel de l'éditeur : il ne consulte pas d'autres catalogues — il affirme ce qui est vrai pour ses propres livres.

Une résolution DNS, pas à pas (sans le jargon)

Quand vous tapez example.com dans votre navigateur, votre navigateur ne cherche pas un nom — il a besoin d'une adresse IP (un nombre comme 93.184.216.34) pour savoir où se connecter. Le DNS est le système « trouve‑moi le numéro pour ce nom ».

1) Le navigateur demande au système d'exploitation

Votre navigateur demande d'abord à l'ordinateur/téléphone : « Connaissons‑nous déjà l'adresse IP de example.com ? » Le système vérifie sa propre mémoire à court terme (cache). S'il trouve une réponse fraîche, la recherche s'arrête là.

2) Le système d'exploitation interroge un résolveur DNS

Si le système d'exploitation ne l'a pas, il transmet la question à un résolveur DNS — généralement fourni par votre FAI, votre entreprise ou un fournisseur public. Pensez au résolveur comme à votre « concierge DNS » : il fait le travail pour que votre appareil n'ait pas à le faire.

3) Le résolveur suit des directions : racine → TLD → autoritatif

Si le résolveur n'a pas la réponse en cache, il démarre une recherche guidée :

• Serveur racine : le résolveur demande où trouver les informations pour la terminaison du domaine (comme .com). Le serveur racine ne donne pas l'IP finale — il fournit des renvois, des directions : « Interrogez ces serveurs .com ensuite. »
• Serveur TLD (.com) : le résolveur demande aux serveurs .com où example.com est géré. Encore une fois, pas l'IP finale — plus de directions : « Interrogez ce serveur autoritatif pour example.com. »
• Serveur autoritatif : c'est la source de vérité pour ce domaine. Il répond avec l'enregistrement final (par ex. un A ou AAAA) contenant l'adresse IP.

4) La réponse revient (et est généralement mise en cache)

Le résolveur renvoie l'IP à votre système d'exploitation, puis au navigateur, qui peut enfin se connecter. La plupart des recherches semblent instantanées parce que les résolveurs et les appareils mettent les réponses en cache pendant une durée fixée par le propriétaire du domaine (TTL).

Un modèle mental simple

Un flux facile à retenir est : Navigateur → cache OS → cache du résolveur → Racine (renvoi) → TLD (renvoi) → Autoritatif (réponse) → retour au Navigateur.

Mise en cache et TTL : pourquoi le DNS est rapide (et parfois lent à changer)

Le DNS serait lent si chaque visite nécessitait de repartir de zéro et d'interroger plusieurs serveurs pour la même réponse. Au lieu de cela, le DNS repose sur la mise en cache — une « mémoire » temporaire des recherches récentes — de sorte que la plupart des utilisateurs obtiennent des réponses en millisecondes.

Ce qu'est la mise en cache (et pourquoi elle existe)

Quand votre appareil demande à un résolveur DNS example.com, ce résolveur peut devoir travailler la première fois. Après avoir appris la réponse, il la stocke dans un cache. La prochaine personne qui demande le même nom peut ainsi être servie immédiatement.

La mise en cache existe pour deux raisons :

• Vitesse : moins d'allers‑retours réseau, chargements de pages plus rapides.
• Réduction de charge : les serveurs autoritatifs n'ont pas à répondre à chaque requête individuelle de chaque utilisateur.

TTL : « combien de temps garder cette réponse avant de reposer la question »

Chaque enregistrement DNS est servi avec une valeur TTL (Time To Live). Pensez au TTL comme à une instruction : garder cette réponse pendant X secondes, puis la jeter et redemander.

Si un enregistrement a un TTL de 300, les résolveurs peuvent le réutiliser jusqu'à 5 minutes avant de le vérifier à nouveau.

Le compromis : changement vs stabilité

Le TTL est un compromis :

• TTLs courts aident les changements à se propager plus vite (utile lors de migrations), mais peuvent augmenter le volume de requêtes DNS.
• TTLs longs réduisent le trafic de requêtes et améliorent la stabilité, mais les modifications mettent plus de temps à être visibles.

Situations réelles où le TTL compte

Si vous migrez un site vers un nouvel hôte, changez de CDN ou réalisez une bascule d'e‑mail (modification des enregistrements MX), le TTL détermine la rapidité à laquelle les utilisateurs cessent d'aller vers l'ancien endroit.

Une approche courante consiste à baisser les TTL à l'avance d'un changement planifié, effectuer la bascule, puis remonter les TTL une fois que tout est stable. C'est pourquoi le DNS peut être rapide au quotidien — et « têtu » juste après une mise à jour.

Les enregistrements DNS que vous verrez (A, AAAA, CNAME, MX, TXT)

Quand vous ouvrez un tableau de bord DNS, vous modifiez principalement une poignée de types d'enregistrements. Chaque enregistrement est une petite instruction qui indique où envoyer les gens (web), où livrer le courrier, ou comment vérifier la propriété.

Les types d'enregistrements courants (avec exemples simples)

Erreurs fréquentes

Quelques erreurs DNS reviennent souvent :

• Placer un CNAME à l'apex (example.com). Beaucoup de fournisseurs DNS ne le permettent pas car le nom racine doit aussi porter des enregistrements tels que NS et SOA. Si vous avez besoin que le root pointe vers un nom d'hôte, utilisez un enregistrement A/AAAA ou une fonctionnalité « ALIAS/ANAME » si votre fournisseur la propose.
• Enregistrements conflictuels : ne définissez pas un CNAME et un A pour le même nom d'hôte (par exemple sur www). Choisissez une méthode.
• Fautes de frappe et problèmes de format : un caractère erroné dans mail.provider.com peut casser l'e‑mail ; les points manquants/en trop et la copie du mauvais champ d'hôte (par ex. @ vs www) sont des causes fréquentes de pannes.

Si vous partagez des consignes DNS avec une équipe, une petite table comme celle ci‑dessus dans votre doc (ou une page runbook) accélère les revues et le dépannage.

Qui gère le DNS : domaines, registrars et serveurs racine

Le DNS fonctionne parce que la responsabilité est répartie entre de nombreuses organisations. Cette répartition explique aussi pourquoi vous pouvez changer de fournisseur, modifier des paramètres et garder votre nom en ligne sans demander la permission de « l'Internet ».

Enregistrement de domaine vs hébergement DNS (ce n'est pas la même chose)

Enregistrer un domaine revient à acheter le droit d'utiliser un nom (comme example.com) pour une période donnée. Pensez‑y comme réserver une étiquette pour que personne d'autre ne puisse la réclamer.

Héberger le DNS consiste à exécuter les paramètres qui disent au monde où ce nom doit pointer — votre site web, fournisseur d'e‑mail, enregistrements de vérification, etc. Vous pouvez enregistrer un domaine chez une entreprise et héberger le DNS chez une autre.

Registre, registrar et serveurs de noms — rôles en clair

• Registre : l'organisation qui exploite un TLD (comme .com, .org ou .uk). Elle maintient la base officielle des détenteurs de nom sous ce TLD et quels serveurs de noms en sont responsables.
• Registrar : le revendeur que vous utilisez pour enregistrer (et renouveler) un domaine. Le registrar parle au registre pour vous et vous permet d'éditer les paramètres clés du domaine.
• Serveurs de noms : les machines (gérées par votre hébergeur DNS) qui publient les enregistrements de votre domaine — A/AAAA, MX, TXT, CNAME, etc. Ils sont dits autoritifs parce qu'ils fournissent les réponses finales pour votre domaine.

Ce que font (et ne font pas) les serveurs racine

Les serveurs racine se situent au sommet du DNS. Ils ne connaissent pas l'adresse IP de votre site et ne stockent pas les enregistrements de votre domaine. Leur rôle est plus limité : ils disent aux résolveurs où trouver les serveurs autoritatifs pour chaque TLD (par ex. où .com est géré).

Délégation : comment le contrôle passe du TLD à votre domaine

Quand vous définissez des « serveurs de noms » pour votre domaine chez votre registrar, vous créez une délégation. Le registre .com (via ses serveurs autoritatifs) indiquera alors aux requêtes pour example.com les serveurs de noms que vous avez choisis.

À partir de ce moment, ces serveurs de noms contrôlent les réponses que le reste d'Internet reçoit — jusqu'à ce que vous changiez à nouveau la délégation.

Sécurité et confiance : ce qui peut mal tourner et comment le DNS aide

Le DNS repose sur la confiance : quand vous tapez un nom, vous supposez que la réponse pointe vers le vrai service. La plupart du temps c'est le cas — mais le DNS est aussi une cible d'attaque, car un petit changement dans « où pointe ce nom » peut rediriger beaucoup de monde.

Risques DNS courants (et à quoi ils ressemblent)

Un problème classique est le spoofing ou l'empoisonnement du cache. Si un attaquant parvient à tromper un résolveur pour qu'il stocke une fausse réponse, les utilisateurs peuvent être envoyés vers une mauvaise IP même s'ils ont tapé le bon domaine. Cela peut conduire à des pages de phishing, des téléchargements malveillants ou une interception du trafic.

Un autre risque est le détournement de domaine au niveau du registrar. Si quelqu'un compromet votre compte registrar, il peut changer les serveurs de noms ou les enregistrements DNS et prendre le contrôle de votre domaine sans toucher à l'hébergement.

Enfin, il y a le danger quotidien : les mauvaises configurations. Un CNAME mal placé, un TXT ancien ou un MX incorrect peut casser des flux de connexion, la livraison d'e‑mails ou des vérifications. Ces pannes ressemblent souvent à « Internet est en panne », alors que la cause est une petite édition DNS.

Comment DNSSEC aide (grand angle)

DNSSEC ajoute des signatures cryptographiques aux données DNS. En clair : la réponse DNS peut être validée pour confirmer qu'elle n'a pas été altérée en transit et qu'elle provient bien du DNS autoritatif du domaine. DNSSEC n'encrypte pas les requêtes et ne rend pas les recherches anonymes, mais il peut empêcher que des réponses forgées soient acceptées.

Confidentialité : DoH et DoT

Les requêtes DNS traditionnelles sont faciles à observer pour les réseaux. DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) chiffrent la connexion entre votre appareil et un résolveur, réduisant l'espionnage et certaines manipulations en cours de route. Elles ne rendent pas le DNS totalement anonyme, mais elles changent qui peut voir et manipuler les requêtes.

Mesures pratiques pour les équipes

Activez la MFA sur votre registrar, mettez des verrous de transfert, et limitez qui peut modifier le DNS. Traitez les changements DNS comme des déploiements en production : exigez une revue, conservez un journal des modifications et configurez des alertes/monitoring pour les changements d'enregistrements ou de serveurs de noms afin d'être informé rapidement des surprises.

Conseils pratiques pour les équipes qui gèrent un site ou des e‑mails

Le DNS peut sembler « configuré et oublié », jusqu'à ce qu'un petit changement fasse tomber votre site ou vos e‑mails. La bonne nouvelle : quelques habitudes rendent la gestion du DNS prévisible — même pour les petites équipes.

Une checklist simple pour les petites équipes

Commencez par un processus léger et répétable :

• Choisissez un fournisseur DNS de confiance : privilégiez une interface claire, un historique des changements, et le support des enregistrements modernes (y compris TXT pour l'authentification d'email). Vous pouvez enregistrer votre domaine chez un prestataire et héberger le DNS ailleurs.
• Décidez d'une stratégie TTL : le TTL contrôle la durée pendant laquelle les autres mettent en cache vos enregistrements. Utilisez des TTL plus longs pour les services stables (meilleures performances) et abaissez temporairement les TTL avant des migrations planifiées.
• Documentez chaque changement : gardez une note partagée indiquant ce qui a changé, pourquoi, quand et qui l'a approuvé. Incluez les valeurs précédentes pour pouvoir revenir rapidement en arrière.

Habitudes de fiabilité qui empêchent les « pannes mystérieuses »

La plupart des problèmes DNS ne sont pas compliqués — ils sont juste difficiles à remarquer rapidement.

• Utilisez plusieurs serveurs de noms : votre fournisseur DNS doit publier au moins deux serveurs de noms autoritatifs situés à des emplacements différents. Cela réduit le risque qu'une seule panne vous mette hors ligne.
• Surveillez depuis l'extérieur de votre réseau : un monitoring basique qui vérifie la résolution DNS (et pas seulement le HTTP) peut détecter les problèmes plus tôt.
• Ayez un plan de rollback : avant toute modification, copiez les enregistrements actuels de la zone. Si quelque chose casse, restaurer des valeurs connues bonnes doit prendre des minutes, pas des heures.

Si vous déployez des applications fréquemment, le DNS fait partie de votre processus de release. Par exemple, les équipes qui publient des apps depuis des plateformes comme Koder.ai (où l'on peut construire et déployer via chat puis attacher des domaines personnalisés) reposent sur les mêmes fondamentaux : cibles A/AAAA/CNAME correctes, TTL judicieux lors des bascules et un chemin de retour clair si quelque chose pointe au mauvais endroit.

Livraison d'e‑mails : les enregistrements DNS importants

Si vous envoyez des e‑mails depuis votre domaine, le DNS affecte directement la capacité des messages à atteindre les boîtes de réception.

• SPF (enregistrement TXT) : liste les serveurs autorisés à envoyer des mails pour votre domaine.
• DKIM (enregistrement TXT) : ajoute une signature cryptographique pour que les destinataires vérifient que le message n'a pas été altéré.
• DMARC (enregistrement TXT) : indique aux destinataires quoi faire quand SPF/DKIM échouent (et fournit des rapports). Commencez par une politique de « surveillance », puis serrez-la une fois que vous êtes confiants.

Les noms conviviaux ont permis à l'Internet de s'étendre au‑delà d'une petite communauté de recherche. Traitez le DNS comme une infrastructure partagée : un peu d'attention en amont garde votre site joignable et vos e‑mails dignes de confiance à mesure que vous grandissez.