Changer de fournisseur SMTP sans interruption.

Plan de migration + checklist DNS (SPF/DKIM/DMARC) + warm-up + plan de retour arrière

Changer de fournisseur SMTP devrait être simple. Pourtant, si vous basculez trop vite (ou si vous modifiez le mauvais enregistrement DNS au mauvais moment), vous risquez des échecs d’authentification, des retards de livraison ou une chute brutale vers le dossier spam. Résultat : mots de passe de réinitialisation qui n’arrivent pas, factures perdues, paniers abandonnés, et tickets support inutiles.

Ce guide vous explique comment migrer avec zéro downtime en faisant tourner les deux fournisseurs en parallèle, en validant correctement vos DNS, en chauffant l’envoi progressivement (warm-up) et en gardant un vrai plan de rollback.

Si vous migrez vers Mailpro, vous suivez exactement les mêmes étapes — en utilisant le Serveur SMTP et les Emails transactionnels de Mailpro, ainsi que les enregistrements d’authentification.

Ressources Mailpro (FR) : Serveur SMTP | Emails transactionnels | Configurer SPF | DKIM (définition + bonnes pratiques) | Configurer DMARC | Tarifs

Réponse rapide : la méthode la plus sûre pour changer de SMTP

Si vous ne suivez qu’une seule chose, respectez cet ordre :

1. Publiez DKIM du nouveau fournisseur (en premier).
2. Mettez à jour SPF pour inclure les deux fournisseurs pendant une courte période en parallèle.
3. Vérifiez DMARC (au minimum en mode “monitoring” pendant la migration).
4. Routez 5–10% du trafic via le nouveau fournisseur.
5. Augmentez le volume progressivement sur 7–14 jours en surveillant rebonds / blocages / plaintes.
6. Retirez l’ancien fournisseur du SPF uniquement une fois la livraison stable.

Pourquoi ça marche : vous évitez un “cutover” brutal où un seul DNS mal réglé peut stopper vos emails pendant des heures.

CTA : Si vous migrez vers Mailpro, commencez par sécuriser vos envois : SPF, DKIM et DMARC.

Étape 0 : choisir votre structure d’envoi (évite beaucoup de problèmes)

Avant de toucher aux DNS, décidez comment vous structurez l’envoi. Beaucoup de migrations échouent parce que tout est mélangé.

Option A (recommandée) : séparer transactionnel vs marketing

Si vous envoyez à la fois des newsletters (marketing) et des emails transactionnels (réinitialisation de mot de passe, factures, reçus), séparez-les au minimum par sous-domaine :

• Transactionnel : mail.votredomaine.com ou tx.votredomaine.com
• Marketing : news.votredomaine.com ou em.votredomaine.com

Pourquoi : le marketing génère plus de plaintes. Si une campagne abîme votre réputation, vous ne voulez pas impacter les emails critiques (mot de passe, facture, confirmation).

Option B : tout garder sur le domaine principal

C’est possible, mais plus risqué pendant une migration : SPF devient vite surchargé, l’alignement DMARC est plus difficile à diagnostiquer, et un émetteur oublié peut casser l’authentification.

Conseil simple : si vous ne changez qu’une chose pour gagner en stabilité, utilisez un sous-domaine dédié au transactionnel.

Étape 1 : inventorier toutes les sources qui envoient des emails

Listez tout ce qui envoie “au nom de votre domaine”. C’est indispensable pour DMARC et pour éviter les surprises après bascule.

• Votre site / application (transactionnel : reset mot de passe, alertes)
• Votre e-commerce (commande, livraison, confirmations)
• CRM et outils commerciaux
• Support / tickets
• Outils de rendez-vous / rappels
• Formulaires (certains envoient des emails)
• Outils internes (rapports, alertes)

Astuce : DMARC (avec rapports) peut révéler des émetteurs “inconnus”. Si vous n’avez pas DMARC, activez-le en monitoring pendant la migration (voir étape 4).

Étape 2 : configurer DKIM sur le nouveau fournisseur (toujours en premier)

DKIM est souvent le changement le plus sûr au départ : vous publiez les enregistrements DKIM sans perturber l’ancien fournisseur, vous testez, puis seulement vous routez du trafic.

1. Générez les clés DKIM chez le nouveau fournisseur (Mailpro fournit les infos nécessaires).
2. Publiez les enregistrements DKIM dans votre DNS (souvent CNAME, parfois TXT).
3. Attendez la propagation DNS.
4. Envoyez un email de test et vérifiez dans les en-têtes : DKIM=pass.

Ressource : DKIM : définition + bonnes pratiques

Erreur fréquente : publier DKIM sur le mauvais domaine / sous-domaine. Si vous envoyez depuis tx.votredomaine.com, DKIM doit être configuré pour ce sous-domaine.

Étape 3 : mettre à jour SPF en toute sécurité (période “double fournisseur”)

Pendant la migration, SPF doit autoriser temporairement les deux fournisseurs. Ne retirez pas l’ancien du SPF avant d’être sûr que le nouveau délivre correctement.

Règles SPF à respecter

• Un seul enregistrement SPF TXT par domaine / sous-domaine (deux SPF = souvent un SPF cassé).
• Évitez un SPF trop complexe avec trop de include: (risque de PermError).
• DKIM est votre “ancre” pendant la migration si SPF devient trop chargé.

Ce que vous faites concrètement

• Gardez les include de l’ancien fournisseur.
• Ajoutez le include du nouveau fournisseur (fourni lors de la configuration Mailpro).
• Testez SPF sur le domaine/sous-domaine réel d’envoi.
• Après stabilité, retirez l’ancien fournisseur du SPF.

Ressource : Comment configurer SPF avec Mailpro

Mini guide de dépannage SPF (très utile en migration)

Les 3 problèmes SPF qui cassent le plus de migrations :

• Deux enregistrements SPF : plusieurs TXT qui commencent par v=spf1. Solution : fusionner en un seul.
• PermError (trop d’includes) : trop de recherches DNS. Solution : supprimer des services inutiles, simplifier, ou déplacer une partie des envois sur un sous-domaine avec un SPF plus léger.
• SPF sur le mauvais domaine : vous avez modifié votredomaine.com mais l’app envoie depuis mail.votredomaine.com. Solution : publier SPF sur le domaine/sous-domaine d’envoi réel.

Pro tip : si votre SPF est “plein”, pas de panique. Souvent, DKIM + alignement DMARC stabilisent la délivrabilité. SPF doit être correct, mais pas ingérable.

Étape 4 : vérifier DMARC (et l’alignement)

DMARC renforce la confiance des boîtes mail et sert de “radar” pendant une migration : il révèle les sources qui échouent (authentification ou alignement).

Approche recommandée pendant la migration

Si vous avez déjà DMARC, gardez-le. Sinon, démarrez en mode monitoring :

• Départ : p=none (monitoring / rapports)
• Après stabilité : envisagez p=quarantine ou p=reject

Ressource : Enregistrement DMARC avec Mailpro

Alignement DMARC (explication simple)

DMARC passe si :

• SPF passe et le domaine SPF est aligné avec le domaine visible dans le “From”, ou
• DKIM passe et le domaine signé DKIM est aligné avec le domaine du “From”

Règle pratique : assurez-vous que DKIM est configuré pour le domaine/sous-domaine exact utilisé dans le “From”. C’est la voie la plus simple pour réussir DMARC pendant une migration.

Étape 5 : envoi en parallèle (ce qui évite le downtime)

Vous préparez une migration ? Le SMTP de Mailpro permet une bascule sans interruption — accompagnement DNS et warm-up pour ne rien arrêter.

Vous faites tourner les deux fournisseurs en même temps sur une courte période. C’est le cœur d’une migration sans interruption.

Comment router une partie seulement des emails

• App / site : router un pourcentage du trafic (ou certains types d’emails) vers le nouveau fournisseur.
• E-commerce : commencer par un sous-ensemble contrôlé, ou migrer le transactionnel en priorité si votre base est saine.
• Marketing : commencer par les destinataires les plus engagés, puis élargir.

Warm-up : IP partagée vs IP dédiée

IP partagée : souvent ramp-up plus rapide (l’IP a déjà un historique), mais surveillez quand même.

IP dédiée : chauffez plus lentement. Un pic brutal depuis une IP “neuve” peut déclencher du throttling.

Exemples de ramp-up (à ajuster selon votre volume)

Exemple A : transactionnel d’abord (recommandé pour “zéro downtime”)

• Jour 1 : 10% du transactionnel (reset mot de passe / reçus) via le nouveau fournisseur
• Jour 2–3 : 25%
• Jour 4–5 : 50%
• Jour 6–7 : 80–100%
• Semaine 2 : migrer le marketing

Exemple B : marketing d’abord (si votre liste est très propre)

• Jour 1–2 : uniquement “engagés sur 30 jours”
• Jour 3–4 : élargir à 60 jours
• Jour 5–7 : élargir à 90 jours
• Semaine 2 : volume marketing complet
• Transactionnel : migrer après stabilité (ou garder provisoirement sur l’ancien)

Important : pour les emails critiques (mot de passe, factures), évitez le cutover brutal. Migrez en parallèle avec rollback prêt.

Étape 6 : monitoring quotidien (ce qu’il faut regarder)

Les migrations échouent souvent “silencieusement” au début. Surveillez chaque jour pendant le ramp-up.

Indicateurs essentiels

• Erreurs de livraison : hard bounces vs temporaires (deferrals)
• Blocages / throttling : “rate limited”, “try again later”
• Plaintes spam
• Ouvertures / clics : indicateur utile (surtout marketing)
• Succès des emails critiques : reset, factures, confirmations

Lecture utile (dépannage) : Erreurs SMTP courantes et comment les corriger

Vérification simple des en-têtes

Sur quelques messages de test, confirmez :

• SPF=pass
• DKIM=pass
• DMARC=pass

Si DMARC échoue mais DKIM passe, c’est souvent un problème d’alignement (domaine signé). Si SPF échoue, c’est souvent un include manquant, un double SPF, ou un PermError.

Étape 7 : plan de rollback (retour arrière) si quelque chose casse

Si l’envoi s’arrête ou si la délivrabilité s’effondre, un rollback clair permet de réduire l’interruption à quelques minutes.

Ordre recommandé pour rollback

1. Rétablir le routage d’abord : renvoyer le trafic vers l’ancien fournisseur (config app, identifiants SMTP, règles).
2. Ne supprimez pas vos DNS tout de suite : la propagation DNS prend du temps et peut aggraver la situation.
3. Identifier le type de panne : auth/DNS, throttling, réputation/spam.
4. Corriger la cause (DKIM mal publié, SPF trop complexe, alignement DMARC).
5. Reprendre progressivement une fois stable.

Checklist de diagnostic rapide

• Rejets immédiats ? (souvent auth/DNS)
• Deferrals / throttling ? (warm-up ou limites)
• Spam soudain ? (réputation ou auth incohérente)
• Deux SPF publiés ? (très fréquent)
• DKIM publié sur le bon domaine ? (très fréquent)

Bonne nouvelle : si vous gardez l’ancien fournisseur prêt et que vous pouvez rerouter vite, le downtime reste minimal.

Étape 8 : retirer l’ancien fournisseur (uniquement après stabilité)

Après 7–14 jours stables (ou plus si gros volume) :

• Retirez l’ancien fournisseur du SPF.
• Optionnel : nettoyez les anciens enregistrements DKIM (ou gardez-les temporairement).
• Conservez DMARC (avec rapports) pour détecter des émetteurs oubliés.

Pro tip : la stabilité d’abord, le “ménage” ensuite.

Checklist DNS (copier/coller)

La plupart des migrations SMTP nécessitent :

• SPF (TXT) sur le domaine/sous-domaine d’envoi
• DKIM (CNAME ou TXT) (1 à 3 sélecteurs selon le fournisseur)
• DMARC (TXT) sur _dmarc.votredomaine.com (ou équivalent sous-domaine)

Optionnel (selon votre architecture) :

• Return-Path / domaine d’enveloppe et alignement
• Warm-up IP dédiée
• Paramètres TLS

Erreurs fréquentes (et comment les éviter)

1. Deux SPF : fusionnez en un seul TXT qui commence par v=spf1.
2. Router avant DKIM : DKIM doit être publié et validé avant d’envoyer du volume.
3. SPF surchargé : réduisez les includes ou utilisez un sous-domaine avec un SPF plus simple.
4. DMARC échoue à cause d’un outil oublié : faites l’inventaire + utilisez les rapports.
5. Basculer 100% en 24h : faites un ramp-up progressif.
6. Pas de rollback : gardez l’ancien fournisseur opérationnel jusqu’à stabilité réelle.
7. Mélanger marketing + transactionnel sans segmentation : protégez les emails critiques.

FAQ

Combien de temps faut-il pour changer de fournisseur SMTP en sécurité ?

Pour la plupart des petits/moyens expéditeurs : 7 à 14 jours avec envoi en parallèle et ramp-up progressif. Avec IP dédiée ou gros volumes, prévoyez plus.

Dois-je changer SPF quand je change de fournisseur SMTP ?

En général oui. Pendant la migration, autorisez les deux fournisseurs temporairement, puis retirez l’ancien une fois stable. Gardez un seul SPF.

Faut-il configurer DKIM avant de toucher à SPF ?

Oui. DKIM est souvent l’étape la plus sûre au départ. Publiez DKIM, validez DKIM=pass, puis mettez à jour SPF et routez un petit pourcentage.

Que se passe-t-il si j’ai deux enregistrements SPF ?

Beaucoup de serveurs le traitent comme une erreur SPF. La solution est de fusionner en un seul enregistrement TXT v=spf1.

Ai-je besoin de DMARC pour migrer ?

Ce n’est pas obligatoire, mais c’est fortement recommandé : DMARC vous aide à valider l’alignement et à détecter des sources oubliées via les rapports. Commencez en p=none si besoin.

Dois-je migrer le transactionnel d’abord ou le marketing ?

Pour “zéro downtime”, transactionnel d’abord est souvent plus sûr : vous validez les flux critiques et le rollback est simple. Marketing d’abord peut marcher si votre liste est très propre.

Comment éviter une chute de délivrabilité pendant la migration ?

Envoi en parallèle, ramp-up progressif, commencer par les destinataires engagés, et s’assurer que SPF/DKIM/DMARC passent et sont alignés.

Quel est le rollback le plus simple si ça tourne mal ?

Reroutez d’abord le trafic vers l’ancien fournisseur (config/identifiants). Ne supprimez pas les DNS dans la panique. Corrigez DKIM/SPF/DMARC, puis recommencez progressivement.

Si vous migrez vers Mailpro

Mailpro est conçu pour l’envoi professionnel fiable, notamment :

• Serveur SMTP pour applications et sites web
• Emails transactionnels (reset mot de passe, factures, alertes, reçus)
• Outils et guidance d’authentification (SPF, DKIM, DMARC)

Démarrez ici :

• Serveur SMTP Mailpro
• Emails transactionnels
• Configurer SPF
• DKIM
• Configurer DMARC

Appel à l’action : pour migrer sans stress, configurez votre domaine dans Mailpro, publiez les enregistrements d’authentification, puis suivez le plan “en parallèle + ramp-up” de ce guide.

Voir les plans et tarifs