A quick refresher

DNS is the directory that tells the internet where your website and your email live. A few record types matter here:

• A / AAAA: where your website is
• CNAME: an alias pointing to another name
• MX: where incoming email is delivered
• TXT: free-form records, used for SPF, DKIM, DMARC and domain verification
• NS: which servers are authoritative for your domain

The key distinction: the registrar is where the domain is registered and renewed. The DNS host is where the records are stored. They can be the same company or different ones. Changing the DNS host means changing the NS records, which is not the same as transferring the domain.

Step 1: Take a full inventory of the current zone

Export the current records, or copy them manually if no export exists. Do not rely on a "scan" feature of a new provider, since it may miss things.

Pay attention to records people forget:

• MX records and their priorities
• SPF (a TXT record starting with v=spf1)
• DKIM records, usually CNAMEs or TXT records on names like selector._domainkey
• DMARC (a TXT record on _dmarc)
• Autodiscover / autoconfig records used by mail clients
• Verification records for Google, Microsoft, and other services
• Subdomains (shop, support, status, staging, old marketing sites)
• Records for third-party senders: newsletter tools, invoicing software, CRM, helpdesk
• SRV records for chat or voice services
• CAA records limiting who can issue SSL certificates

If nobody can explain a record, do not delete it. Note it, keep it, and investigate later.

Step 2: Lower the TTL in advance

At least two days before the change, reduce the TTL on all important records (5 to 10 minutes is typical). That limits how long some people see the old setup after the switch. Keep in mind that the TTL of NS records is controlled at the registrar or parent zone level and often cannot be shortened. Plan extra time. The same TTL idea applies when you switch hosting.

Step 3: Recreate the zone at the new provider

Add every record before touching nameservers. Then compare the two zones line by line. Typical mistakes:

• A trailing dot or a missing hostname in a CNAME value
• TXT records split into multiple strings that get altered
• DKIM keys truncated when pasted (they are long)
• A proxied or "orange cloud" setting that was not there before, which can break mail-related records
• A CNAME on the root of the domain, which is not allowed by DNS rules (some providers offer an "alias" or "flattening" feature as a workaround, with varying behavior)

You can query the new provider's nameservers directly with a DNS lookup tool, to check that the answers match the old ones before the switch.

Step 4: Check the email authentication trio

These three records decide whether your mail is trusted.

SPF lists the servers allowed to send mail for your domain. Two common errors:

• More than one SPF record (only one is allowed)
• Too many lookups: SPF allows at most 10 DNS lookups, and every include: counts. Companies that add one tool after another often exceed this limit, and SPF then fails

DKIM signs outgoing messages. If the DKIM records do not exist at the new DNS host, signed mail starts failing verification.

DMARC tells receivers what to do when SPF or DKIM fails. If you currently have a strict policy and something is broken after migration, mail will be rejected rather than just flagged. Consider setting the policy to monitoring mode during the change, then tightening it again once everything is stable.

Step 5: Watch out for DNSSEC

If DNSSEC is enabled on your domain, there is a signing record (DS) at the registrar. If you change DNS providers without handling it, the domain can stop resolving for many users, which also takes email down.

The safe order is generally:

1. Remove the DS record at the registrar (or disable DNSSEC) well ahead of the change, and wait for old TTLs to expire.
2. Migrate the DNS.
3. Re-enable DNSSEC with the new provider's keys, and add the new DS record.

Check your registrar and new provider documentation for their exact procedure.

Step 6: Switch nameservers

Choose a quiet time, not Friday evening. Update the NS records at the registrar to the new provider's nameservers. Propagation can take from minutes to a couple of days, so both old and new servers must answer correctly throughout. Do not delete the old zone yet.

Step 7: Test email actively

Do not wait for someone to complain. Right after the switch:

• Send a message to your domain from an external address (Gmail, Outlook, and one other provider)
• Send a message from your domain to those same addresses
• Check message headers for SPF, DKIM and DMARC "pass"
• Send from each system that uses your domain (CRM, shop, invoicing, newsletter, helpdesk)
• Check the mail logs of your email provider
• Repeat the next day, and a few days later

Free online tools can check your records and send you a test report.

Step 8: Clean up

• After a week or two of stable operation, raise TTL to a normal value
• Remove the old zone from the previous provider
• Document the final zone, with a note explaining each unusual record
• Store registrar and DNS access in your team's password manager (see the 30-minute account audit)

Common pitfalls

• Forgetting an MX record or its priority
• Missing DKIM for a secondary sender such as a newsletter tool
• Two SPF records, or one over the lookup limit
• Forgetting subdomains, which suddenly stop resolving
• DNSSEC left enabled after the move
• Deleting the old zone immediately
• Doing the change right before a busy period
• Mistaking a registrar transfer for a DNS move, and doing both at once. Do them separately, and with at least a few days between them

Safer alternative: separate things permanently

A lasting improvement is to keep email, website and DNS with separate, well-documented ownership. A hosting change then never touches email, and a registrar change never touches the website. It is slightly more to manage, but it removes the most common source of outages. Put that ownership map in your exit plan.

Checklist

• Full export of the current zone saved
• TTL lowered 48 hours ahead
• New zone built and compared record by record
• SPF, DKIM and DMARC verified
• DNSSEC plan decided
• Test emails sent in both directions
• Old zone kept for at least a week
• Final documentation saved

Rappel rapide

Le DNS est l'annuaire qui dit à Internet où vivent votre site et votre email. Quelques types d'enregistrements comptent ici:

• A / AAAA: où est le site
• CNAME: un alias vers un autre nom
• MX: où arrive le courrier entrant
• TXT: enregistrements libres, utilisés pour SPF, DKIM, DMARC et vérifications de domaine
• NS: quels serveurs font autorité pour le domaine

Distinction clé: le registrar, c'est où le domaine est enregistré et renouvelé. L'hébergeur DNS, c'est où sont stockés les enregistrements. Ce peut être la même société ou deux. Changer d'hébergeur DNS, c'est changer les NS. Ce n'est pas un transfert de domaine.

Étape 1: Inventaire complet de la zone actuelle

Exportez les enregistrements, ou copiez-les à la main s'il n'y a pas d'export. Ne comptez pas sur un « scan » du nouveau prestataire: il peut en manquer.

Attention aux enregistrements qu'on oublie:

• MX et leurs priorités
• SPF (TXT qui commence par v=spf1)
• DKIM, souvent CNAME ou TXT sur des noms du type selector._domainkey
• DMARC (TXT sur _dmarc)
• Autodiscover / autoconfig pour les clients mail
• Enregistrements de vérification Google, Microsoft, et autres
• Sous-domaines (boutique, support, status, staging, vieux sites marketing)
• Émetteurs tiers: newsletter, facturation, CRM, helpdesk
• SRV pour chat ou voix
• CAA limitant qui peut émettre des certificats SSL

Si personne ne peut expliquer un enregistrement, ne le supprimez pas. Notez-le, gardez-le, et regardez plus tard.

Étape 2: Baisser le TTL à l'avance

Au moins deux jours avant, réduisez le TTL des enregistrements importants (5 à 10 minutes est courant). Cela limite le temps où certains voient encore l'ancienne config après la bascule. Le TTL des NS est souvent piloté au niveau registrar / zone parente et se raccourcit rarement. Prévoyez de la marge. La même logique TTL sert aussi pour changer d'hébergeur.

Étape 3: Recréer la zone chez le nouveau prestataire

Ajoutez chaque enregistrement avant de toucher aux nameservers. Puis comparez les deux zones ligne à ligne. Erreurs typiques:

• Point final en trop ou hostname manquant dans une valeur CNAME
• TXT découpés en plusieurs chaînes qui se déforment
• Clés DKIM tronquées au collage (elles sont longues)
• Un réglage « proxied » / orange cloud qui n'était pas là avant, et qui casse des enregistrements liés au mail
• Un CNAME à la racine du domaine, interdit par les règles DNS (certains proposent un « alias » ou du flattening, avec un comportement variable)

Vous pouvez interroger directement les nameservers du nouveau prestataire avec un outil de lookup, pour vérifier que les réponses collent aux anciennes avant la bascule.

Étape 4: Le trio d'authentification email

Ces trois enregistrements décident si votre mail est digne de confiance.

SPF liste les serveurs autorisés à envoyer pour votre domaine. Deux erreurs fréquentes:

• Plus d'un enregistrement SPF (un seul est autorisé)
• Trop de lookups: SPF autorise au plus 10 lookups DNS, et chaque include: compte. Ajouter un outil après l'autre dépasse souvent la limite, et le SPF échoue

DKIM signe les messages sortants. Sans les enregistrements DKIM chez le nouvel hébergeur DNS, la vérification échoue.

DMARC dit aux récepteurs quoi faire si SPF ou DKIM échoue. Avec une politique stricte et quelque chose de cassé après migration, le mail est rejeté plutôt que juste signalé. Passez en mode surveillance pendant le changement, puis resserrez une fois stable.

Étape 5: Attention au DNSSEC

Si le DNSSEC est activé, il y a un enregistrement de signature (DS) chez le registrar. Changer de DNS sans le traiter peut faire cesser de résoudre le domaine pour beaucoup d'utilisateurs, email inclus.

Ordre prudent en général:

1. Retirer le DS chez le registrar (ou désactiver le DNSSEC) bien avant, et attendre l'expiration des anciens TTL.
2. Migrer le DNS.
3. Réactiver le DNSSEC avec les clés du nouveau prestataire, et ajouter le nouveau DS.

Suivez la doc exacte de votre registrar et du nouveau prestataire.

Étape 6: Basculer les nameservers

Choisissez un créneau calme, pas un vendredi soir. Mettez à jour les NS chez le registrar vers ceux du nouveau prestataire. La propagation peut aller de quelques minutes à un ou deux jours: les deux zones doivent répondre correctement pendant toute cette période. Ne supprimez pas encore l'ancienne zone.

Étape 7: Tester l'email activement

N'attendez pas qu'on se plaigne. Juste après la bascule:

• Envoyer un message vers votre domaine depuis une adresse externe (Gmail, Outlook, et un autre)
• Envoyer depuis votre domaine vers ces mêmes adresses
• Vérifier les en-têtes: SPF, DKIM et DMARC en « pass »
• Envoyer depuis chaque système qui utilise votre domaine (CRM, boutique, facturation, newsletter, helpdesk)
• Regarder les logs de votre prestataire mail
• Recommencer le lendemain, puis quelques jours plus tard

Des outils en ligne gratuits peuvent vérifier vos enregistrements et vous envoyer un rapport de test.

Étape 8: Nettoyage

• Après une ou deux semaines stables, remonter le TTL à une valeur normale
• Supprimer l'ancienne zone chez le précédent prestataire
• Documenter la zone finale, avec une note pour chaque enregistrement inhabituel
• Mettre les accès registrar et DNS dans le coffre d'équipe (voir l'audit de comptes en 30 minutes)

Pièges fréquents

• Oublier un MX ou sa priorité
• DKIM manquant pour un émetteur secondaire (newsletter, etc.)
• Deux SPF, ou un au-delà de la limite de lookups
• Oublier des sous-domaines, qui cessent de résoudre
• DNSSEC laissé actif après le déménagement
• Supprimer l'ancienne zone tout de suite
• Faire le changement juste avant une période chargée
• Confondre transfert de domaine et déménagement DNS, et faire les deux d'un coup. Séparez-les, avec au moins quelques jours entre les deux

Alternative plus sûre: séparer pour de bon

Une amélioration durable: garder email, site et DNS sous des propriétés séparées et documentées. Un changement d'hébergement ne touche plus l'email, un changement de registrar ne touche plus le site. Un peu plus à gérer, mais ça enlève la cause d'indispo la plus courante. Mettez cette carte dans votre plan de sortie.

Checklist

• Export complet de la zone actuelle sauvegardé
• TTL baissé 48 h à l'avance
• Nouvelle zone construite et comparée enregistrement par enregistrement
• SPF, DKIM et DMARC vérifiés
• Plan DNSSEC décidé
• Emails de test envoyés dans les deux sens
• Ancienne zone gardée au moins une semaine
• Documentation finale sauvegardée