How to Find Your Real Origin IP Behind Cloudflare, Safely (and How to Fix Leaks)

Source: Dev.to

Why Cloudflare Can’t Hide Your MX IP

• MX records tell the world where to deliver email.
• Cloudflare can’t proxy SMTP mail the way it proxies HTTP/HTTPS, so the mail server needs a real, publicly reachable IP address.

Key point: your MX IP is not automatically your website origin IP, but it often becomes the origin IP when you host mail and web on the same box.

What You’ll Answer in This Audit

1. What hostnames are used for MX?
2. What IP address(es) do those MX hostnames resolve to? (confirmed across resolvers)
3. Who owns that IP, and what kind of network is it? (hosting, ISP, suspicious, etc.)
4. Is that IP blacklisted anywhere? (useful for email deliverability and risk signalling)

Step 1 – Find the MX Hostnames

1. Open a DNS‑records lookup tool, e.g. NetworkWhois – DNS Records.

2. Enter:

   • Domain: example.com
   • Record type: MX

3. Note the MX targets that appear, for example:

   • mail.example.com
   • mx1.provider.tld
   • example-com.mail.protection.outlook.com (Microsoft 365)
   • aspmx.l.google.com (Google Workspace)

Record the exact MX hostname(s) – you’ll resolve them in the next step.

Step 2 – Resolve the MX Hostname(s) to an IP (and Confirm Consistency)

1. Go to NetworkWhois – DNS Propagation.

2. For each MX hostname:

   • Enter: the MX hostname (e.g., mx.example.com)
   • Select record type: A (and also AAAA if you use IPv6)
   • Run the check

3. Look for agreement among major resolvers. Example output:

DNS Server          Status      IP Address   TTL
Google (8.8.8.8)    Propagated  192.0.2.10   3600
Cloudflare (1.1.1.1) Propagated  192.0.2.10   3600
Quad9 (9.9.9.9)     Propagated  192.0.2.10   3600

What this tells you: the mail server hostname resolves to the same public IP everywhere – that’s the public mail IP.

Quick “Same Server” Check

If your web and mail servers share a box, you’ll often see one of the following patterns:

• mx.example.com resolves to the same IP as your website origin.
• cpanel.example.com and webmail.example.com also resolve to that IP.
• Your root domain (example.com) has DNS‑only records pointing to the same IP (or you forgot to proxy a hostname).

Compare the IPs you obtained with the IPs of hostnames you control, such as:

• origin.example.com
• cpanel.example.com
• webmail.example.com
• Any “grey‑cloud” (DNS‑only) records

Step 3 – Run WHOIS on the IP to Identify Its Owner

1. Take the IP you discovered (e.g., 192.0.2.10).
2. Use NetworkWhois – WHOIS Lookup.

What to look for in the WHOIS/Hazard Report:

• ASN type – hosting provider (typical for VPS/dedicated), residential/mobile (often wrong for production mail), proxy/Tor (high risk).
• Reputation flags – Spamhaus, UCEPROTECT, “Known as Mail Server”, “Hosting likelihood”, “Bogon”, “Unreachable”, etc.

These signals aren’t legal evidence, but they give valuable context. A clean hosting ASN is fine; a “high‑risk proxy, listed everywhere” result indicates reputation problems or a possibly compromised system.

Step 4 – Check If the IP Is Blacklisted (Email Deliverability & Risk)

1. Visit NetworkWhois – IP Blacklist Checker.
2. Paste the same IP address.

The tool will query major DNSBLs (Spamhaus, SORBS, etc.) and show any listings.

If the IP appears on blacklists, you’ll need to address the underlying issue (spam, open relay, compromised server, etc.) before mail deliverability suffers.

What to Do If You Find an Unwanted “Hidden” Origin

1. Separate services – Move mail to a different server or IP.
2. Proxy the web‑only hostnames – Use Cloudflare (orange‑cloud) for all web‑facing records, leaving only the MX record pointing to the mail server.
3. Update DNS – Ensure any “grey‑cloud” records that expose the origin are changed to point to a proxy or a different IP.
4. Monitor reputation – Regularly re‑run WHOIS and blacklist checks, especially after any infrastructure changes.

TL;DR

• MX records expose a public IP because SMTP can’t be proxied.
• If you host web and mail on the same box, that IP often reveals your website origin.
• Use public DNS tools to enumerate MX hostnames, resolve them, run WHOIS, and check blacklists.
• If the IP is the same as your web origin and you don’t want it exposed, move mail off that server or proxy the web‑only hostnames.

Happy auditing! 🚀

📸 Image

Why This Step Matters

• If that IP is your mail‑server IP, blacklisting can directly explain spam‑folder issues and bounces.
• If that IP is also your website origin, blacklisting can signal that the server has been abused, compromised, or previously used for spam.

What to Do If You Confirmed the MX IP Equals Your Web‑Origin IP

If your mail server and website share the same IP and you want the origin to stay private, you have only a few realistic options.

Option 1 – Separate Mail from Web (best, simplest)

Move mail to:

• a dedicated mail provider (Google Workspace, Microsoft 365, Mailgun, etc.)
• a separate mail VPS with its own IP

Result: MX reveals only the mail IP; your web origin stays hidden behind Cloudflare.

Option 2 – Keep Mail on the Same Server, but Accept the Origin Exposure

This is the common cPanel reality. If you do nothing, your origin IP is discoverable by anyone who checks MX. That isn’t automatically “dangerous”, but you should harden the server accordingly.

Hardening Checklist

• Firewall the origin so only Cloudflare IP ranges can reach ports 80/443.
• Lock down admin panels (/wp-admin, /cpanel, /plesk) with IP allow‑lists, MFA, and rate limits.
• Remove unnecessary DNS‑only hostnames that point to the origin (e.g., direct.example.com, origin.example.com, old subdomains).
• Disable unused services and apply patches aggressively.

Option 3 – Use a Mail Gateway or Relay

If you must keep local mailboxes but want a cleaner reputation and separation, use an outbound relay. Inbound mail still needs an MX that points somewhere reachable, so this is only a partial solution.

Common Leaks That Expose the Origin Even When You “Use Cloudflare”

• mail.example.com points directly to the origin, and the site shares the same server.
• cpanel.example.com, webmail.example.com, direct.example.com are DNS‑only and expose the origin.
• You proxied www.example.com but forgot the root domain (@).
• Old subdomains still resolve to the server IP and haven’t been cleaned up.
• Service records (SRV, TXT, etc.) unintentionally reveal origin hostnames.

Fixing these is mostly DNS hygiene plus network hardening.

Try It Now – Audit in 5 Minutes

1. Find MX hostnames
2. Resolve MX hostnames
3. Verify ownership

Run through the checklist, and you’ll know whether your web origin is exposed and what steps to take next.