Enregistrements Cloudflare proxifiés (nuage orange) qui cassent l'email : la solution

Ce que ça veut dire

Dans le DNS de Cloudflare, chaque enregistrement A, AAAA et CNAME a un Proxy status (statut du proxy) : Proxied (nuage orange) ou DNS only (nuage gris). Quand un enregistrement est proxifié, Cloudflare ne publie pas la vraie IP de votre serveur. Il répond avec ses propres IP et transmet le trafic web (HTTP/HTTPS) à votre serveur.

L'email ne passe pas par ce proxy. Donc si un enregistrement utilisé pour l'email est proxifié, les autres serveurs obtiennent l'adresse de Cloudflare au lieu de celle de votre serveur mail. Les symptômes :

• Personne ne peut vous envoyer d'email : le MX pointe vers un hôte qui renvoie vers Cloudflare, et la connexion sur le port 25 échoue ou expire.
• Le SPF échoue : un mécanisme a ou mx renvoie maintenant vers des IP de Cloudflare, et non vers votre serveur.
• Le DKIM ou la vérification du domaine échoue chez SendGrid, Mailgun et outils similaires : leurs enregistrements CNAME ont été ajoutés en mode proxifié.
• Vos applications mail ne peuvent pas se connecter à mail.yourdomain.com en IMAP ou en SMTP.

Pourquoi cela arrive

• Passage du DNS chez Cloudflare : pendant l'import, Cloudflare peut passer des enregistrements en mode proxifié, y compris mail.
• Un seul enregistrement A pour les deux : le site web et le serveur mail partagent un nom d'hôte, et quelqu'un l'a proxifié pour le site.
• CNAME du prestataire email proxifiés : des CNAME comme em1234.yourdomain.com ou s1._domainkey.yourdomain.com ajoutés avec le nuage orange activé.

Les enregistrements MX et TXT ne peuvent pas être proxifiés eux-mêmes ; le problème vient toujours de l'enregistrement A, AAAA ou CNAME dont ils dépendent.

Comment vérifier

1. Ouvrez le scanner de domaine et regardez vos enregistrements MX et l'IP vers laquelle pointe chaque hôte MX. Faites un Whois sur cette IP : si elle appartient à Cloudflare et que vous n'utilisez pas de produit mail Cloudflare pour cet hôte, l'enregistrement est proxifié.
2. Avec dig :

   dig MX yourdomain.com +short
   10 mail.yourdomain.com.
   dig A mail.yourdomain.com +short
   104.16.x.x        (Cloudflare range: wrong for a mail server)

3. Testez un CNAME DKIM : un CNAME proxifié ne renvoie pas la clé TXT qui se trouve derrière.

   dig TXT s1._domainkey.yourdomain.com +short

4. Envoyez un email de test depuis votre serveur à l'adresse unique affichée sur la page d'accueil de Delivmail (/) et lisez le résultat SPF. Un échec pour l'IP de votre propre serveur vient souvent d'une cible a ou mx proxifiée.
5. Dans le tableau de bord Cloudflare, ouvrez votre domaine, allez dans DNS > Records et regardez la colonne Proxy status.

Comment corriger

1. Passez les enregistrements mail en DNS only

Modifiez chacun de ces enregistrements et passez le Proxy status sur DNS only (nuage gris) :

• l'enregistrement A/AAAA de chaque hôte utilisé dans vos enregistrements MX (par exemple mail, mx) ;
• les hôtes auxquels vos applications mail se connectent en IMAP, POP et SMTP ;
• chaque CNAME fourni par un prestataire email (sélecteurs DKIM, domaines de return-path ou de bounce, suivi des liens sauf indication contraire du prestataire) ;
• tout hôte cité dans le SPF avec a:.

Type   Name       Content          Proxy status
A      @          203.0.113.80     Proxied   (website: OK)
A      mail       203.0.113.25     DNS only  (mail server)
MX     @          mail.yourdomain.com   priority 10
CNAME  s1._domainkey  s1.domainkey.u123.wl.sendgrid.net   DNS only

2. Séparez le site web et l'hôte mail

Ne faites pas pointer votre MX vers le même nom que votre site proxifié. Utilisez un nom dédié comme mail.yourdomain.com, en DNS only. Notez qu'un hôte mail en DNS only publie son IP ; si c'est la même IP que celle de votre site, cela révèle l'adresse réelle de votre site. Héberger l'email sur une autre IP ou chez un prestataire email évite ce problème.

3. Rendez le SPF indépendant des noms proxifiés

Dans le SPF, préférez ip4:/ip6: ou l'include: de votre prestataire à a et mx :

v=spf1 ip4:203.0.113.25 include:_spf.google.com ~all

Si vous utilisez Google Workspace ou Microsoft 365, votre MX pointe vers leurs serveurs et il n'y a rien à changer côté proxy pour lui ; vérifiez plutôt les CNAME DKIM et l'enregistrement SPF. Pour les problèmes voisins, voir enregistrements email perdus après le déménagement de votre DNS.

Vérifiez que c'est corrigé

Les changements de proxy s'appliquent vite, mais les résolveurs peuvent garder les anciennes réponses en cache pendant le TTL de l'enregistrement (voir propagation DNS et TTL). Relancez ensuite dig A mail.yourdomain.com : la commande doit renvoyer l'IP de votre serveur. Lancez un nouveau test Delivmail et vérifiez que le SPF et le DKIM passent, revérifiez le domaine dans votre outil d'emailing, et envoyez un email depuis une boîte extérieure vers votre domaine pour confirmer la réception.