Cloudflare ne proxifie pas le SMTP : ports 25, 465, 587

Vous venez de basculer vos serveurs DNS vers Cloudflare ou d'activer le proxy sur votre domaine, et les messages entrants rebondissent pendant que vos propres clients n'arrivent plus à envoyer. La cause est presque toujours la même : le proxy ne transporte que du HTTP et du HTTPS, donc le SMTP sur les ports 25, 465 et 587 n'atteint jamais votre serveur de messagerie.

Cloudflare ne proxifie pas le SMTP, ni sur le port 465 ni sur aucun autre port de messagerie

Le nuage orange est un proxy inverse destiné au trafic web. Il accepte des connexions HTTP et HTTPS sur une liste fermée de ports et les transmet à votre serveur d'origine. Tout ce qui n'est pas du HTTP ou du HTTPS sur l'un de ces ports n'a tout simplement aucun interlocuteur sur l'edge. La documentation Cloudflare le dit sans détour : le proxy ne traite que le trafic HTTP et HTTPS, et proxifier un enregistrement utilisé par un autre protocole envoie ce trafic vers Cloudflare, qui abandonne la connexion non HTTP.

Voici la liste complète des ports transportés par défaut, sur tous les plans :

HTTP : 80, 8080, 8880, 2052, 2082, 2086, 2095
HTTPS : 443, 2053, 2083, 2087, 2096, 8443

C'est toute la liste. Le SMTP sur 25, 465 et 587, l'IMAP sur 143 et 993, le POP3 sur 110 et 995 n'y figurent nulle part, et aucun niveau de plan ni aucun interrupteur ne les ajoute à un enregistrement DNS proxifié. Deux conséquences en découlent directement :

Seuls les enregistrements A, AAAA et CNAME portent un statut de proxy. Les enregistrements MX et TXT sont toujours en DNS only, par type d'enregistrement. Il n'y a aucun nuage orange à désactiver sur un MX, et c'est précisément pour cela que le problème passe inaperçu.
Un même hostname ne peut pas servir à la fois un site proxifié et un service de messagerie. La partie web continuerait de fonctionner, la partie messagerie non, et c'est ce site en apparence sain qui envoie la plupart des gens chercher au mauvais endroit.

La seule exception documentée est Spectrum, un proxy de niveau 4 qui prend en charge tous les ports TCP et UDP sur le plan Enterprise. Il est mal adapté à la messagerie, et Cloudflare l'écrit : Spectrum transmet le trafic sans jouer le rôle de serveur de messagerie, l'adresse vue par le serveur destinataire devient une adresse edge Cloudflare sauf si Proxy Protocol est activé, et les applications Spectrum n'ont pas d'entrée DNS inverse, ce qui est exactement le contrôle que la plupart des serveurs destinataires effectuent avant d'accepter un message. Sur une zone Free, Pro ou Business, la question ne se pose pas : les enregistrements de messagerie passent en nuage gris.

Ports 25, 465 et 587 : l'entrant et le sortant sont deux problèmes distincts

C'est la partie sortante qui crée le plus de confusion, et les deux sens échouent pour des raisons différentes et se corrigent à des endroits différents. Les séparer évite des heures passées à chercher un réglage qui n'existe pas.

En entrée, le port 25

Les serveurs de messagerie distants qui vous livrent du courrier utilisent toujours le port 25. Ils résolvent votre enregistrement MX, obtiennent un nom d'hôte, résolvent ce nom d'hôte en enregistrement A ou AAAA, puis ouvrent une connexion TCP sur le port 25 de l'adresse obtenue. Si cette adresse est une adresse anycast Cloudflare parce que l'hôte de messagerie est proxifié, rien sur l'edge ne répond en SMTP. Le serveur expéditeur ne reçoit pas un refus qu'il pourrait signaler tout de suite, il reçoit du silence. Il met le message en file, retente pendant des heures, et finit par renvoyer un rebond à l'expéditeur d'origine. Votre site web fonctionne normalement pendant tout ce temps, ce qui explique que l'incident soit toujours remonté comme une panne de messagerie et jamais comme une panne DNS.

En sortie, les ports 465 et 587

Les ports 587 (soumission) et 465 (soumission en TLS implicite) ne sont pas utilisés par les serveurs distants qui vous livrent du courrier. Ils servent à vos propres clients de messagerie et à vos propres applications pour remettre un message à votre serveur, qui se charge ensuite de l'acheminer. Rien ne se passe sur l'edge Cloudflare ici, parce que le proxy n'est pas sur ce chemin : c'est un proxy inverse, il ne voit que les connexions que le reste d'Internet ouvre vers vos hostnames, jamais celles que votre serveur ou votre poste ouvre vers l'extérieur.

Le proxy n'intercepte donc pas, n'inspecte pas, ne limite pas et ne bloque pas le SMTP sortant. La documentation Cloudflare est explicite sur ce point : sauf configuration explicite de Spectrum pour le SMTP, le courrier est délivré directement à votre serveur de messagerie et ne traverse pas du tout le réseau Cloudflare.

Quand l'envoi casse juste après une migration, la cause n'est donc jamais une interception de trafic. C'est la résolution de noms :

Votre client de messagerie ou votre application est configuré avec un hôte de soumission du type smtp.exemple.com ou mail.exemple.com.
Cet enregistrement est proxifié, il résout donc désormais vers une adresse anycast Cloudflare et non vers votre serveur de messagerie.
Le client ouvre le port 465 ou 587 vers cette adresse, rien ne répond, et vous obtenez un délai d'attente dépassé dans Outlook, Thunderbird ou les journaux de votre application.

La correction est la même qu'en entrée : DNS only sur ce nom d'hôte. La distinction compte surtout parce qu'elle vous dit où ne pas chercher. Il n'existe aucune option Cloudflare pour autoriser le SMTP sortant, aucune règle de sécurité à écrire, aucun port à ouvrir sur l'edge. Seul l'enregistrement DNS est en cause.

La conséquence en sortie à laquelle personne ne pense

Puisque le courrier sortant ne traverse jamais le réseau Cloudflare, il part avec l'adresse réelle de votre serveur d'origine. Le proxy masque cette adresse aux visiteurs du site ; il ne la masque pas au serveur de messagerie destinataire, et il ne doit pas le faire. C'est pour cette raison qu'inscrire les plages Cloudflare dans un enregistrement SPF n'aurait aucun sens, et que votre SPF doit autoriser l'adresse d'émission réelle de votre origine, ou le mécanisme include de votre plateforme d'envoi.

Une autre panne sortante est régulièrement imputée à Cloudflare sans aucun rapport avec lui : beaucoup d'hébergeurs et de plateformes cloud bloquent par défaut le port 25 sortant depuis leur propre réseau, pour limiter le spam. Si le port 25 échoue depuis votre serveur alors que les ports 465 et 587 fonctionnent normalement, la question est à poser à votre hébergeur, pas à votre fournisseur DNS.

Pourquoi un enregistrement MX ne doit jamais viser un hôte proxifié

Un enregistrement MX ne porte pas de statut de proxy. Le dashboard n'affiche aucune icône de nuage pour ce type d'enregistrement, et Cloudflare maintient les MX en DNS only par nature. Le piège se situe un niveau plus bas : le MX désigne un nom d'hôte, et ce nom d'hôte possède un enregistrement A ou AAAA qui peut parfaitement être en nuage orange, le plus souvent parce qu'il s'agit du domaine racine qui sert aussi le site web.

Concrètement, quand la messagerie tourne sur le même nom que le site :

dig MX exemple.com +short renvoie 10 mail.exemple.com.
dig A mail.exemple.com +short renvoie une adresse anycast Cloudflare et non votre serveur de messagerie.
Un serveur distant ouvre le port 25 sur cette adresse et attend une bannière d'accueil 220 qui n'arrive jamais.
À l'issue de la fenêtre de reprise, typiquement un premier avis de retard au bout de quelques heures et un échec définitif après plusieurs jours selon la durée de file de l'expéditeur, le message rebondit vers son auteur.

Il existe une seconde règle, structurelle : un enregistrement MX doit désigner un nom d'hôte doté d'enregistrements d'adresse, jamais un alias. Faire pointer un MX vers un CNAME est invalide, et les implémentations destinataires le traitent de façon inégale, ce qui produit la pire catégorie de panne, celle qui ne touche que certains expéditeurs et paraît aléatoire.

Cloudflare documente aussi une bonne pratique à appliquer pendant que vous remettez la zone à plat : n'hébergez pas le service de messagerie sur la même machine que la ressource web que vous protégez. Les rebonds renvoyés vers un destinataire inexistant transportent l'adresse du serveur de messagerie, et si cette adresse est aussi votre origine web, le proxy ne masque plus rien.

Passer le sous-domaine de messagerie en nuage gris, pas à pas

Suivez ces étapes dans l'ordre et validez le résultat de chacune avant de passer à la suivante. D'autres guides pratiques de ce type sont réunis dans notre hub de guides Cloudflare.

Lisez votre DNS comme le voient les serveurs de messagerie, avant de toucher à quoi que ce soit. Depuis n'importe quelle machine :
```
dig MX exemple.com +short
dig A mail.exemple.com +short
dig A smtp.exemple.com +short
dig TXT exemple.com +short
dig TXT _dmarc.exemple.com +short
```
La première commande montre où est dirigé le courrier entrant, les deux suivantes montrent vers quoi résolvent aujourd'hui vos hôtes de messagerie, les deux dernières donnent les politiques SPF et DMARC. Si vous connaissez votre sélecteur DKIM (souvent default ou google), ajoutez dig TXT default._domainkey.exemple.com +short. Notez les réponses : c'est votre état de départ.
Auditez le statut de proxy de chaque enregistrement lié à la messagerie. Dans le dashboard, ouvrez DNS > Records et vérifiez l'icône de nuage de chaque hostname utilisé par la messagerie : la cible de chaque enregistrement MX, l'hôte de soumission configuré dans vos clients, l'hôte IMAP ou POP3, et les entrées autodiscover ou autoconfig exigées par votre fournisseur. Chacune doit indiquer DNS only. Les enregistrements de votre site, et le webmail s'il est servi en HTTPS, peuvent rester proxifiés sans aucun effet sur la messagerie.
Basculez chaque hôte de messagerie en DNS only. Cliquez sur Edit sur l'enregistrement, cliquez sur le nuage orange dans la colonne de statut de proxy pour qu'il passe au gris et affiche DNS only, puis enregistrez. Le type et le contenu de l'enregistrement ne changent pas, seul le statut de proxy change. Cloudflare applique la modification immédiatement au niveau autoritatif ; ce qui prend du temps ensuite, c'est le cache des résolveurs, pas Cloudflare.
Corrigez les cibles MX elles-mêmes. Chaque entrée MX doit désigner un nom d'hôte doté d'un enregistrement A ou AAAA direct et non proxifié. Supprimez les entrées périmées héritées de l'ancien fournisseur et conservez une seule cible propre avec la priorité 10, sauf si votre fournisseur en documente plusieurs avec des priorités explicites.
Vérifiez l'aplatissement des CNAME. Plusieurs fournisseurs exigent un vrai CNAME pour le DKIM ou l'autodiscover. Quand l'aplatissement (CNAME flattening) est actif globalement ou sur cet enregistrement précis, le CNAME est servi comme un enregistrement A et le fournisseur ne lit plus ce qu'il attend. Désactivez l'aplatissement pour ces enregistrements.
Vérifiez qu'aucun sous-domaine de messagerie n'est délégué. Si mail.exemple.com est délégué à un autre fournisseur DNS par des enregistrements NS, son enregistrement d'adresse ne se trouve pas du tout dans votre zone Cloudflare, et modifier quoi que ce soit dans Cloudflare restera sans effet. La correction se fait chez le fournisseur autoritatif pour ce sous-domaine.
Vérifiez Email Routing. Si vous exploitez votre propre serveur de messagerie ou un fournisseur externe, Email > Email Routing doit être désactivé. Quand il est actif, Cloudflare gère lui-même vos enregistrements MX et ceux qu'il crée entrent en conflit avec ceux de votre fournisseur, ce qui écrase silencieusement votre routage de production. Email Routing ne fait par ailleurs que recevoir et retransmettre le courrier entrant, il ne fait pas de votre domaine un expéditeur.
Vérifiez depuis l'extérieur. Relancez les commandes dig de la première étape : les réponses doivent désormais être l'adresse réelle de votre serveur de messagerie. Confirmez ensuite que le service répond vraiment, avec les contrôles de la section suivante, et envoyez un vrai message depuis une boîte externe avant de clore l'incident.
Baissez le TTL avant votre prochaine modification. Des enregistrements de messagerie laissés à un TTL de 24 heures signifient que la prochaine erreur restera en circulation dans le monde entier pendant une journée entière. Un TTL de cinq minutes sur ces enregistrements transforme un retour arrière en pause café.

Symptômes observables : messages d'erreur, codes et retours des outils

La signature de cette panne est remarquablement constante, et la reconnaître vous évite d'auditer toute votre configuration de messagerie.

Ce que rapportent les expéditeurs et les clients

Les serveurs expéditeurs rapportent un délai d'attente dépassé, jamais un refus. Postfix journalise une ligne du type connect to mail.exemple.com[198.51.100.1]:25: Connection timed out, diffère le message avec un statut 4.4.1, puis émet un avis définitif 4.4.7 ou 5.4.7 « delivery time expired » une fois la durée de file épuisée.
Les clients de messagerie rapportent un délai d'attente dépassé sur le port de soumission, 465 ou 587 : « la connexion au serveur a expiré » dans Thunderbird, « impossible de se connecter au serveur sortant » dans Outlook.
Aucun outil ne rapporte d'erreur de certificat ni d'échec d'authentification. Cette absence est un signal utile en soi : l'échec survient avant même le début du dialogue SMTP, ce n'est donc ni un problème d'identifiants ni un problème TLS.

Ce que montre telnet

telnet mail.exemple.com 25

Un serveur de messagerie opérationnel répond en moins d'une seconde avec sa bannière d'accueil, par exemple 220 mail.exemple.com ESMTP. Face à un hostname proxifié, vous obtenez l'un de deux résultats : soit la connexion reste bloquée sur Trying 198.51.100.1... jusqu'à ce que votre client abandonne, soit la session TCP s'ouvre puis reste totalement silencieuse, sans la moindre bannière.

Ce second cas mérite une explication, car il donne l'impression que le port est ouvert. Les adresses anycast de Cloudflare servent de nombreux produits, et Cloudflare documente le fait que des ports autres que 80 et 443 peuvent être signalés comme ouverts par netcat ou un scanner de sécurité, puisque du trafic destiné à d'autres clients y est servi. Un port TCP ouvert qui n'envoie jamais de bannière 220 reste un chemin de messagerie mort. Jugez sur la bannière, pas sur l'état du port.

Ce que montre openssl s_client

Pour le TLS implicite sur le port 465, exactement le cas de figure de la plupart de ces incidents :

openssl s_client -connect mail.exemple.com:465

Un serveur opérationnel termine la négociation TLS, affiche sa chaîne de certificats, puis envoie la bannière 220. Face à une adresse Cloudflare, la négociation ne démarre jamais : sous Linux, openssl sort sur connect:errno=110, le code du délai de connexion dépassé, sans une seule ligne de certificat.

Pour STARTTLS sur le port 587 :

openssl s_client -starttls smtp -connect mail.exemple.com:587

Même comportement, une étape plus tôt : openssl ne parvient même pas à lire la bannière initiale dont il a besoin avant d'émettre la commande STARTTLS. L'équivalent rapide avec curl renvoie le délai dépassé de façon explicite :

curl -v --max-time 10 telnet://mail.exemple.com:465

Sur un hostname proxifié, la commande se termine sur Connection timed out after 10000 milliseconds. Sur un hostname correctement configuré, elle ouvre la session en silence et attend, ce qui est le comportement attendu pour une session TCP brute.

Confirmer la cause en une commande

dig +short mail.exemple.com

Si la réponse tombe dans l'une des plages d'adresses publiées par Cloudflare, le hostname est proxifié et vous avez votre diagnostic sans ouvrir le dashboard. Faites ce contrôle sur la cible du MX en particulier, et pas seulement sur le domaine racine : ce sont fréquemment deux enregistrements distincts avec des statuts de proxy différents.

Ce que cela change pour SPF, DKIM et DMARC

Le statut de proxy et l'authentification du courrier sont deux mécanismes indépendants, mais une migration de zone casse généralement les deux en même temps, ce qui mélange les symptômes et fait dériver le diagnostic.

Le SPF est un enregistrement TXT, il n'est donc jamais proxifié. Ce qui casse, c'est son contenu : il doit autoriser l'adresse réelle depuis laquelle votre origine émet, ou le mécanisme include de votre plateforme d'envoi. Proxifier votre enregistrement web n'y change rien, puisque le courrier sortant ne traverse pas le proxy. Deux enregistrements v=spf1 dans la zone, ou plus de dix requêtes DNS, produisent un PermError que les destinataires traitent comme un échec franc.
Le DKIM est lui aussi un enregistrement TXT, souvent très long. Les migrations les tronquent. Une clé découpée en fragments de 255 caractères à laquelle il manque un fragment résout quand même et paraît présente, tout en faisant échouer chaque vérification de signature. Certains fournisseurs publient le DKIM sous forme de CNAME, ce qui ramène le problème d'aplatissement décrit plus haut.
Le DMARC a besoin que le SPF ou le DKIM passe et qu'il soit aligné avec le domaine visible dans le champ From. Un enregistrement SPF techniquement valide qui autorise le bon serveur mais n'est pas aligné échoue quand même au contrôle DMARC, et c'est de loin la première raison pour laquelle un domaine aux enregistrements corrects continue d'atterrir en spam.

Si votre vrai problème relève de l'authentification et non du routage, la procédure complète, de l'inventaire des expéditeurs à la politique en mode strict, est dans notre guide sur la configuration de SPF, DKIM et DMARC sur le DNS Cloudflare. Cette hygiène côté origine compte aussi pour le trafic web ; notre guide sur les erreurs 521, 522 et 524 intermittentes couvre l'aspect joignabilité de l'origine.

Les erreurs fréquentes qui cassent la messagerie en silence

Des enregistrements MX pointant vers la racine proxifiée : quand la messagerie tourne sur le même domaine que le site, le MX vise souvent l'enregistrement A racine, qui est proxifié. Le courrier entrant est alors abandonné par l'edge Cloudflare alors que tous les autres enregistrements de la zone sont corrects.
Chercher un réglage de port qui n'existe pas : il n'y a aucune option pour ouvrir le port 465 ou 587 sur un enregistrement proxifié, sur aucun plan. Le temps passé dans les paramètres de sécurité à en chercher une est du temps qui n'est pas consacré à l'enregistrement DNS réellement fautif.
Modifier des enregistrements sans baisser le TTL : un TTL de 24 heures mis en cache par les résolveurs du monde entier signifie que les anciennes réponses cassées continuent de circuler pendant des heures après le correctif. Baissez les TTL un jour avant toute migration.
Conserver plusieurs enregistrements SPF : ajouter un second enregistrement v=spf1 au lieu de fusionner ses includes dans l'existant invalide les deux. Fusionnez, n'ajoutez jamais.
Coller des clés DKIM sans le découpage en 255 caractères : le DNS stocke les valeurs TXT longues en plusieurs chaînes entre guillemets, et les reformater à la main fait souvent perdre un fragment, ce qui produit des signatures qui n'échouent que chez certains destinataires.
Laisser Email Routing à moitié configuré : activer la fonctionnalité sans règles de transfert complètes détourne les enregistrements MX sans rien délivrer, ce qui ressemble exactement à une panne totale de messagerie.

Questions fréquentes

Cloudflare proxifie-t-il le SMTP sur le port 465 ?

Non. Le proxy Cloudflare transporte du HTTP et du HTTPS sur une liste fermée de ports : 80, 8080, 8880, 2052, 2082, 2086 et 2095 en HTTP, et 443, 2053, 2083, 2087, 2096 et 8443 en HTTPS. Le port 465 n'y figure pas, pas plus que le 25 et le 587. Une connexion ouverte sur le port 465 vers un hostname proxifié ne trouve aucun service de messagerie sur l'edge, et la connexion non HTTP est abandonnée. Aucun niveau de plan et aucun réglage n'ajoute les ports de messagerie à un enregistrement DNS proxifié. La seule exception documentée est Spectrum, un proxy de niveau 4 disponible sur le plan Enterprise, que Cloudflare signale lui-même comme mal adapté au SMTP car les applications Spectrum n'ont pas d'entrée DNS inverse.

Cloudflare proxifie-t-il le trafic SMTP sortant sur le port 465 ?

Non, et dans ce sens le proxy n'est même pas sur le chemin. Le proxy Cloudflare est un proxy inverse : il ne traite que les connexions ouvertes depuis Internet vers vos hostnames. Une connexion que votre serveur ou votre client de messagerie ouvre vers le port 465 ne touche jamais le réseau Cloudflare, qui ne peut donc ni l'intercepter, ni la limiter, ni la bloquer. Quand l'envoi casse juste après une migration, la cause est la résolution de noms, pas une interception : l'hôte de soumission configuré dans votre client, smtp.exemple.com par exemple, est proxifié et résout désormais vers une adresse anycast Cloudflare. Passez cet enregistrement en DNS only et l'envoi refonctionne. Il n'y a aucun réglage sortant à modifier côté Cloudflare.

Quels ports le proxy Cloudflare transporte-t-il réellement ?

Le HTTP sur les ports 80, 8080, 8880, 2052, 2082, 2086 et 2095, et le HTTPS sur les ports 443, 2053, 2083, 2087, 2096 et 8443. C'est la liste complète par défaut. Tout autre port, dont le SMTP sur 25, 465 et 587, l'IMAP sur 143 et 993 et le POP3 sur 110 et 995, impose de passer l'enregistrement en DNS only pour que le trafic contourne le réseau Cloudflare et atteigne directement votre serveur.

Peut-on garder le nuage orange sur le hostname de messagerie ?

Non. Le proxy Cloudflare parle HTTP et HTTPS sur les ports web uniquement ; il ne relaie pas les connexions SMTP, IMAP ou POP3. Tout hostname utilisé pour la messagerie doit être en DNS only, sinon les clients de messagerie et les serveurs distants atteignent l'edge et la connexion est abandonnée. Les hostnames web, et le webmail servi en HTTPS, peuvent rester proxifiés sans aucun effet sur la messagerie.

Passer mon enregistrement de messagerie en nuage gris expose-t-il l'IP de mon serveur ?

L'hôte de messagerie devient publiquement visible, mais c'est inhérent à l'email : les enregistrements MX sont publics par conception et révèlent un point d'entrée de messagerie quel que soit le proxy. Les rebonds transportent eux aussi l'adresse du serveur de messagerie vers celui qui les a déclenchés. La recommandation de Cloudflare est donc de ne pas héberger le service de messagerie sur la même machine que la ressource web que vous protégez, et d'utiliser des adresses issues de plages différentes, pour qu'exposer le point d'entrée de messagerie n'apprenne rien sur votre origine web.

Combien de temps avant que la messagerie refonctionne après correction des enregistrements ?

Le routage suit les TTL du DNS : de quelques minutes à quelques heures selon les valeurs qui étaient en cache. Les messages déjà mis en file par les serveurs expéditeurs sont retentés pendant plusieurs jours, donc le courrier différé pendant la panne est généralement délivré une fois les enregistrements corrects. La réputation en dossier spam, en revanche, se reconstruit sur plusieurs jours de passes SPF, DKIM et DMARC cohérents.

SPF, DKIM et DMARC nécessitent-ils un plan Cloudflare payant ?

Non. La gestion des enregistrements TXT, MX et CNAME est identique sur le plan Free, sans plafond sur ces types d'enregistrements. La difficulté ne vient jamais du plan, mais de la justesse des valeurs : un seul enregistrement SPF, des sélecteurs DKIM complets et une politique DMARC qui correspond à vos sources d'envoi réelles. Notez qu'un faux positif de sécurité peut aussi bloquer les formulaires web qui déclenchent vos notifications, un problème distinct avec son propre diagnostic.

Pourquoi Vos Emails Ne Fonctionnent Plus Après le Passage sous Cloudflare™