Email atterrissant dans le spam après migration vers Cloudflare : liste de contrôle pour ramener les e-mails dans la "Boîte de réception"

Après avoir déplacé le site vers un nouvel hébergement et transféré les DNS vers Cloudflare, les e-mails transactionnels — confirmations d'inscription, notifications, réinitialisations de mot de passe — commencent soudainement à atterrir dans le dossier "Spam". Avant le déménagement, tout arrivait dans la "Boîte de réception". Cela vous dit quelque chose ? Analysons étape par étape pourquoi cela se produit et comment y remédier — voici une checklist prête à l'emploi qui peut être complétée en 20 à 30 minutes.

Pourquoi cela se produit

Dans la plupart des cas, la raison est unique : lors de l'importation de la zone dans Cloudflare, les enregistrements d'authentification des e-mails sont déplacés "tels quels" — avec l'ancien hôte. L'importation automatique des DNS (et les assistants IA qui aident de plus en plus à la migration) transfère les enregistrements "un par un" et ne réassemble pas le SPF pour le nouvel expéditeur. Le site fonctionne extérieurement, mais les e-mails tombent silencieusement en panne — les e-mails sont envoyés mais atterrissent dans le spam, et personne ne s'en rend compte pendant des semaines.

Un exemple classique : le SPF racine reste v=spf1 include:_spf.old-hoster.com ~all, alors que les e-mails sont désormais réellement envoyés par un service différent — Amazon SES, Resend, SendGrid, ou Postmark. Le domaine "autorise" l'ancien hôte, mais pas l'expéditeur réel. Gmail voit SPF: fail ou softfail et envoie l'e-mail dans le spam, même si le contenu est parfaitement légitime.

Étape 1. Diagnostiquer (Ne pas deviner)

• Envoyez un e-mail de test à mail-tester.com — le service fournit une adresse unique et affiche un rapport avec un score sur 10 et une ventilation de chaque enregistrement.
• Dans Gmail, ouvrez l'e-mail → cliquez sur le menu "⋮" → "Afficher l'original." Trouvez trois lignes : SPF, DKIM, DMARC. Les trois doivent être PASS.

Si au moins un est fail / softfail — le problème vient des DNS, pas du contenu de l'e-mail. Continuez avec la checklist.

Étape 2. Checklist des enregistrements DNS

Tout est corrigé dans Cloudflare → DNS → Records :

• SPF (racine du domaine). Doit autoriser le VRAI expéditeur. Pour Amazon SES / Resend, c'est v=spf1 include:amazonses.com ~all. ⚠️ Il ne peut y avoir qu'un seul enregistrement v=spf1 par domaine — s'il y en a deux, les deux deviennent invalides. Si les e-mails sont envoyés à la fois via un service externe et depuis votre boîte aux lettres — combinez tout en une seule ligne en utilisant include:.
• DKIM. Un enregistrement sélecteur (par exemple, resend._domainkey) doit être présent. Il s'agit d'une signature cryptographique que le service de messagerie utilise pour confirmer que l'e-mail provient bien de vous et n'a pas été falsifié.
• DMARC. Enregistrement _dmarc. Pour un nouveau domaine, il est acceptable de commencer par p=none (surveillance uniquement) ; après un échauffement, augmentez-le à p=quarantine.
• MX et return-path. Doivent pointer vers votre fournisseur d'envoi/réception, pas vers l'ancien hôte.
• PTR (enregistrement inversé, rDNS). Pertinent uniquement si vous envoyez des e-mails depuis votre propre serveur SMTP — l'enregistrement inversé de l'IP doit correspondre au nom du serveur.
• Supprimer les éléments inutiles de l'ancien hôte. Un MX racine cassé, un sélecteur DKIM ancien et obsolète, un include: supplémentaire dans le SPF — une cause fréquente oubliée après la migration.

La règle principale : après TOUT transfert de DNS, effectuez une vérification de messagerie séparément. L'importation de zone copie les enregistrements "tels quels", et "tels quels" correspond à la configuration de l'ancien fournisseur.

Étape 3. Si les e-mails SONT DÉJÀ allés dans le Spam

Vous avez corrigé les DNS, mais les anciens e-mails sont déjà dans le "Spam", et le client de messagerie a "mémorisé" le domaine comme suspect. Aidez-le à reconsidérer sa décision :

• Allez sur votre Google Mail (Gmail), ouvrez un e-mail du dossier "Spam" → cliquez sur le bouton "Non spam". C'est le signal le plus fort au niveau du compte : Gmail examinera la réputation de l'expéditeur plus rapidement et commencera à placer ses e-mails dans la "Boîte de réception".
• Demandez aux premiers destinataires de faire de même — quelques marques "Non spam" de personnes réelles accéléreront considérablement le processus.

Étape 4. Considérer le facteur "Nouveau domaine"

Si le domaine a été enregistré récemment, il manque encore d'historique et de réputation. Même avec des SPF, DKIM et DMARC parfaitement configurés, certains e-mails peuvent encore atterrir dans le spam initialement — et c'est normal ; il ne s'agit plus des DNS.

• Échauffez le domaine : commencez avec de petits volumes d'envoi et augmentez progressivement, pas "mille e-mails le premier jour".
• Surveillez les plaintes et les désabonnements — des pics brusques nuisent à la réputation.
• Les marques "Non spam" de destinataires réels à ce stade échauffent le domaine le plus rapidement.

Vous corrigez les DNS une fois, puis la réputation se construit par le volume et le comportement des destinataires.

Étape 5. Vérifier le résultat

• Répétez le test sur mail-tester.com → visez 10/10.
• Dans les en-têtes d'e-mail (Gmail → "Afficher l'original") : SPF: PASS, DKIM: PASS, DMARC: PASS.
• Un e-mail de test arrive dans la "Boîte de réception", pas dans le "Spam".

Conclusion

Les e-mails qui vont dans le spam après une migration ne sont presque jamais de la "magie", mais plutôt le SPF transféré de l'ancien hôte, qui n'autorise pas le nouvel expéditeur (un effet secondaire courant de la migration DNS automatique et IA vers Cloudflare). L'algorithme de traitement : réassembler le SPF pour l'expéditeur réel → vérifier DKIM, DMARC, MX → nettoyer les éléments inutiles de l'ancien hôte → tester sur mail-tester → si les e-mails sont déjà allés dans le spam, marquer "Non spam" manuellement → pour un nouveau domaine, ajouter un échauffement. Suivez cette checklist une fois — et les e-mails retourneront systématiquement dans la "Boîte de réception".