CF GarageClassic DNS traps when migrating zones to Cloudflare
Cloudflare's reverse proxy (the orange cloud) is designed strictly for HTTP and HTTPS web traffic (ports 80 and 443). It does not proxy raw mail protocols such as SMTP (ports 25, 465, 587), IMAP (port 993), or POP3 (port 995). When importing or configuring DNS records automatically, several common mistakes break mail routing:
- Proxied mail hostname records: If your
mail.your-domain.comor apex domain record is set to orange cloud (proxied), external mail servers attempt to deliver messages to Cloudflare edge IPs, which immediately drop raw SMTP traffic. - MX records pointing to proxied hostnames or CNAMEs: Email RFC specifications require MX records to point directly to canonical A or AAAA records on unproxied hostnames.
- Missing or truncated SPF, DKIM, and DMARC TXT records: During DNS migrations, long 2048-bit DKIM keys or composite SPF strings are frequently truncated, resulting in failed SPF/DKIM alignment and immediate spam filtering by Google Workspace and Microsoft 365.
- Accidental Cloudflare Email Routing conflicts: Enabling Cloudflare Email Routing without configuring target forwarding rules overrides external production MX priorities.
A clean DNS architecture for 100% email deliverability
To restore reliable message routing and secure maximum authentication scores:
- Set dedicated mail hostnames to DNS Only (Grey Cloud): Create a clean subdomain (such as
mail.your-domain.com) with a grey-cloud A record pointing directly to your mail server IP. - Point MX records strictly to unproxied targets: Assign clear priorities (e.g. priority 10) without passing mail server hostnames through the edge proxy.
- Align SPF validation: Ensure your
v=spf1record includes all authorized sending IP addresses and outbound SaaS services (Google Workspace, Microsoft 365, SendGrid, Postmark). - Deploy full DKIM selectors and DMARC policies: Implement complete cryptographic DKIM keys and a strict DMARC policy with reporting to prevent domain spoofing.