Origin behind CDN: why your WAF doesn't matter if your A record leaks

You moved your site behind Cloudflare. The orange cloud is on. The pricing tier includes DDoS protection, bot management, a WAF with custom rules. The reverse proxy is doing its job — every request now lands on Cloudflare's anycast network, gets inspected, gets cached. Your origin server is invisible. Right?

Probably not. The Cloudflare proxy hides traffic only as long as no DNS record ever points directly at your origin IP. In practice, four common DNS records leak it.

The four leaks

1. The MX record

Cloudflare doesn't proxy SMTP. Your MX record has to point at a hostname whose A record resolves to a real mail server, often hosted on the same box as your web server (small infrastructures). One dig MX yourdomain.com followed by dig A <mx-target> and the attacker has your origin IP.

$ dig +short MX example.com
10 mail.example.com.
$ dig +short A mail.example.com
51.75.32.18      <-- this is your "hidden" origin

2. The SPF record

Your SPF record literally enumerates IPs and hostnames authorised to send mail "from" your domain. It frequently includes the same origin IP that runs your web server:

$ dig +short TXT example.com | grep spf
"v=spf1 ip4:51.75.32.18 ip4:51.75.32.19 mx -all"

Both 51.75.32.18 values are right there. Free for the taking.

3. The legacy subdomain

Before the CDN move, you had cpanel.example.com, direct.example.com, ftp.example.com, autodiscover.example.com, relay.example.com, origin.example.com, direct-connect.example.com, sometimes literally origin.example.com. The orange cloud was disabled on those because they were needed for direct admin access. They're still there. They still resolve to the origin.

4. Historical certificate transparency

Before you moved to the CDN, you issued certs for the apex pointing at the origin IP. CT logs are forever; an attacker queries crt.sh, finds an old direct.example.com or pre-CDN apex cert, and tries to resolve it. If the record still exists, jackpot.

Why this matters

Once an attacker has the origin IP, they bypass your CDN entirely:

• DDoS protection bypassed — they hit the origin directly, saturating its uplink. Your Cloudflare bill stays the same; your origin goes down anyway.
• WAF bypassed — direct origin requests skip Cloudflare's rule engine. SQL injection, XSS, broken auth, every signature your WAF would have caught becomes a free shot.
• Geo / IP-based access controls bypassed — Cloudflare-level "block requests from country X" rules apply only to traffic that goes through Cloudflare.
• Rate limits bypassed — same logic.
• Bot management bypassed — cf_bot is a header set on Cloudflare, ignored on the origin.

The point of putting a CDN in front is that nothing reaches the origin without passing through. As soon as one direct path exists, the protection is approximately as useful as a vault door bolted to a tent.

Detection: 5 minutes with dig

# 1. Origin IP via MX
dig +short MX example.com | sort -k1 -n | head -1 | awk '{print $2}' \
  | xargs -I {} dig +short A {}

# 2. Origin IP via SPF
dig +short TXT example.com | grep -oE 'ip4:[0-9.]+' | sed 's/ip4://'

# 3. Suspicious subdomains
for sub in cpanel direct origin server ftp mail relay autodiscover \
           webmail smtp imap pop3 vpn admin staging; do
  ip=$(dig +short A "$sub.example.com")
  [ -n "$ip" ] && echo "$sub.example.com → $ip"
done

# 4. Historical CT logs
curl -s "https://crt.sh/?q=example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

Compare the IPs you collect against your apex's CDN range (Cloudflare publishes cloudflare.com/ips). Anything outside that range that responds to HTTPS on 443 is a leak.

Remediation

1. Move every direct subdomain behind the CDN. Cloudflare's grey-cloud-only records can be re-enabled (orange cloud) for HTTPS. Subdomains that need direct access (SSH, custom protocols) should use a VPN or bastion, not a public DNS record.
2. Use a separate mail provider — Postmark, SES, SendGrid, Mailgun, your-own-MTA-on-a-different-IP. Don't run mail and web from the same box.
3. Audit your SPF record. Replace explicit IPs with include: directives where possible. The IPs that remain should be mail-only servers, separated from web infrastructure.
4. Allow only CDN traffic at the origin firewall. Cloudflare publishes their IP ranges; cap your ingress to those. Even if the origin IP leaks, the connection from "anywhere else" is dropped at the network layer. This is the gold-standard fix.
5. Rotate the origin IP after migrations. Old CT logs reference the old IP. New IP, new public surface.

What UnveilScan flags

Our origin_behind_cdn checker (Extended profile) detects when the apex resolves to a known CDN ASN (Cloudflare, Fastly, Akamai, AWS CloudFront, GCP, Azure Front Door, Vercel, Netlify, Sucuri…) and then probes:

• The MX record + every mail., autodiscover., cpanel., direct., ftp., smtp., imap., pop., relay., origin., server. subdomain.
• Every ip4: in your SPF record.
• The result is cross-checked against MaxMind ASN — anything pointing to a non-CDN ASN is flagged as a likely origin leak with a MEDIUM finding.

The fix list comes with copy-paste suggestions: which subdomain to move, which SPF entry to replace, which firewall rule to add. Run an Extended scan to see them.