Mail Stopped After Moving to Cloudflare — Proxied Mail Records
Cloudflare's proxy (orange cloud) only handles HTTP/S traffic. If you accidentally enable the proxy for records used for mail, SMTP/IMAP traffic hits a wall and mail stops across the entire domain — mail records must always be DNS-only (grey).
I often move domains to Cloudflare and point DNS at the host. Once everything is set up, the website works normally, but sometimes incoming or outgoing mail suddenly stops, even though I haven't touched anything on the mail side. The cause I keep running into is the same, so I'm writing it down here along with the other pitfalls that come with setting up Cloudflare.
The one rule behind missing mail: mail records must be grey, not orange
Cloudflare's proxy (the orange cloud icon) only handles HTTP/HTTPS. Mail traffic (SMTP/IMAP/POP) cannot pass through the proxy. If you accidentally enable the proxy for mail-related records, mail traffic hits the proxy and gets dropped.
mail, smtp, pop, imap, webmail and the host that MX points to must all be grey — if they are orange, incoming mail will fail across the entire domain while the website still works normally, leaving you thinking, "I haven't touched anything."
Check which host MX points to, then make sure that host is grey:
dig +short MX example.com # ได้ mail.example.com
dig +short A mail.example.com # ต้องได้ IP โฮสต์จริง ไม่ใช่ IP Cloudflare (104.x/172.x)
If dig A for the mail host returns an IP in Cloudflare's range, that record is still orange and needs to be switched to grey.
Pitfall 2: the token passes verify but does not work
When using the API to configure DNF through a script, there is a pitfall: the verify endpoint reports success even if the token lacks permissions or is blocked by IP — don't trust verify; try actually listing zones.
If zones returns an empty result, the token is missing Zone:DNS:Edit + Zone:Zone:Read permissions. And if your connection's source IP changes (such as on home/mobile internet), you need to allowlist the entire ISP range, not just one IP; otherwise, the token will stop working tomorrow because the IP has changed.
# อย่าเชื่อ verify — เช็คด้วยการ list zones จริง
curl -s -H "Authorization: Bearer $CF_TOKEN" \
'https://api.cloudflare.com/client/v4/zones?per_page=50' | \
python3 -c 'import sys,json; d=json.load(sys.stdin); print("zones:", len(d.get("result",[])))'
# ได้ 0 = token สิทธิ์ไม่พอ หรือ IP ไม่อยู่ใน allowlist
Pitfall 3: the wrong SSL mode makes the website return 526
If a domain has just been added to Cloudflare and the host is still serving its default cert (a cert for the new domain has not been issued yet), setting SSL to Full (strict) will produce error 526 because Cloudflare cannot validate the origin cert.
For a new domain whose host is still serving its default cert, set SSL to Full first. Once the domain's cert has been issued (Let's Encrypt), switch to Full (strict).
Rules for adding a domain to Cloudflare
- Web records (www/root) can be orange — improve speed + hide the IP
- Mail records (mail/smtp/pop/imap + MX target) must all be grey
- SPF/DKIM/DMARC (TXT) are grey
- Configure the API token: Zone:DNS:Edit + Zone:Zone:Read permissions, allowlist the entire ISP range
- For a new domain, SSL = Full first, then switch to strict
The key is understanding that Cloudflare's proxy only handles HTTP/S. Everything that isn't web traffic must go straight to the host (grey) — this one rule prevents almost every case of "mail stopped after moving to Cloudflare." If you manage multiple domains on one host, feel free to turn this into a checklist. If I've missed anything in the explanation or made a typo, I'll come back and correct it later.
Want us to set this up?
Get help with server setup, configuration, migration, or troubleshooting. Save time for the work that matters.
Hit something like this? Stuck somewhere?
Come trade notes on the LinuxThai board
Comments 0
No comments yet — be the first