Introduction

Cloudflare can sit in front of websites, but it is not supposed to proxy normal mail protocols. After a DNS change, operators often turn on the orange cloud for every hostname and accidentally proxy mail, webmail, autodiscover, or autoconfig. The website may keep working while IMAP, POP, SMTP, or client auto-setup starts failing. This is not usually a mailbox problem. It is a DNS and proxy mode problem on mail-related hostnames.

Symptoms

  • Outlook, Thunderbird, Apple Mail, or mobile mail apps stop connecting after DNS changes
  • Webmail, autodiscover, or autoconfig starts failing after Cloudflare was enabled
  • SMTP, IMAP, or POP connections time out or refuse to connect on hostnames behind Cloudflare
  • The website works, but mail clients cannot reach the expected mail server
  • Only hostnames like mail.example.com or autodiscover.example.com fail while the root domain is normal
  • The issue starts immediately after changing DNS records or enabling Cloudflare proxy

Common Causes

  • mail, webmail, autodiscover, or autoconfig was switched from DNS-only to proxied in Cloudflare
  • A bulk DNS import or migration enabled proxy on every record by default
  • The wrong hostname was given to mail clients after cutover
  • Webmail or setup endpoints were placed behind Cloudflare even though the underlying service was not meant to be proxied
  • DNS was updated correctly, but Cloudflare proxy mode changed the connection path unexpectedly
  • Operators assumed every subdomain should use the same Cloudflare mode as the website

Step-by-Step Fix

  1. List every hostname users and devices rely on for mail access, including mail, webmail, smtp, imap, pop, autodiscover, and autoconfig, because the break often affects more than one record after a bulk DNS change.
  2. Check each relevant DNS record in Cloudflare and see whether it is orange-cloud proxied or gray-cloud DNS-only, because mail-related hostnames should usually stay DNS-only.
  3. Turn proxy off for the affected mail service hostnames and leave them as DNS-only, because Cloudflare proxy mode is the common reason the hostname stops behaving like a normal mail endpoint.
  4. Verify that each DNS-only record points to the correct destination IP or hostname for the new mail server, because disabling proxy alone does not help if the record target is still wrong.
  5. Test the exact hostnames your users configure in mail clients instead of assuming one shared hostname covers everything, because some environments use separate names for webmail, IMAP, SMTP, or client discovery.
  6. Review client auto-setup records and URLs such as autodiscover and autoconfig, because those can break even when the main mail hostname has already been corrected.
  7. Clear or wait out DNS cache where needed and retest from a second network, because some users may still resolve the old proxied path for a while after you change the Cloudflare record mode.
  8. Check the provider documentation for any mail-related hostnames that must never be proxied in your setup, because different mail stacks expose different endpoints and not all of them are obvious during migration.
  9. After mail connectivity returns, document which Cloudflare records are allowed to be proxied and which must remain DNS-only, because this exact mistake tends to come back during later DNS edits and onboarding.