Find the public IP address of a domain
Enter a domain or URL to see its public IPv4 and IPv6 addresses. Results come from this server's DNS resolver and may point to a CDN rather than the origin server.
Need more than an IP address?
Check mail records, SPF and DKIM setup, reverse DNS, subnet math, and related infrastructure signals without leaving the browser.
Troubleshoot the result, not just the record
Practical checks for DNS changes, email authentication and failed lookups.
- How to Change Nameservers Without Downtime: A Step-by-Step Runbook
How to move DNS hosting with no outage: copy and diff the zone, lower TTLs, handle DNSSEC DS, switch NS, verify with dig +trace, and roll back.
- SPF PermError: Too Many DNS Lookups, a Troubleshooting Runbook
Read the receiver's headers, count SPF lookups with dig, find the culprit include, and fix the permerror in a safe order, then confirm DMARC still passes.
- Why Is My CNAME Record Not Propagating? Real Causes and Verification Steps
Why a CNAME looks stuck: apex limits, records at the same name, target typos, negative caching and proxies, with dig checks and a fix order.
- Fix DNS_PROBE_FINISHED_NXDOMAIN on Windows: Find the Broken Layer
How to fix DNS_PROBE_FINISHED_NXDOMAIN in Chrome on Windows by testing the browser, Windows, router, and ISP in order, with exact commands.
- Fixing DKIM Public Key Not Available: DNS Selector and Syntax Troubleshooting
Fix the DKIM 'public key not available' error: read s= and d= from the header, check selector._domainkey, TXT or CNAME, 255-byte splits and caching.
- DNS Query Refused: Find the Server Policy Behind the Error
What a DNS REFUSED response means, which server role caused it, and how to tell with dig. Fixes for resolver admins, zone owners and end users.
- CAA Record Errors: Why Certificate Issuance Fails and What to Check
Why a CA refuses to issue a certificate because of CAA: how it finds the policy, SERVFAIL and DNSSEC traps, wildcard tags, and a safe fix order.
IPv4 + IPv6
Address families
Zero
External APIs
None
Signup required
Built for real DNS work
Clear answers, fast checks, and safer handling of public-domain data.
Dual-stack resolution
Every lookup resolves IPv4 and IPv6 separately so you can see the full public footprint of a hostname instead of guessing from one family alone.
Bulk lookups at scale
Paste thousands of domains in one go and review results in a controlled, repeatable way without overwhelming the DNS layer.
Retry logic for transient failures
Temporary timeouts and resolver errors are retried intentionally, while permanent failures like NXDOMAIN are reported clearly instead of looping for no value.
Safety checks for public data only
Resolved addresses are filtered against private, loopback, and cloud-metadata ranges before they are displayed to prevent unsafe or internal-targeted lookups.
CSV and JSON export
Download complete results for analysis, auditing, or scheduled monitoring without rebuilding the data set manually.
Rate-limited for stability
Per-user limits and bulk-job caps keep the service usable for everyday troubleshooting and portfolio monitoring alike.
How the lookup works
Enter a domain or a list
Use a single hostname or paste a full batch of domains and resolve them with the same workflow.
Resolve in real time
The tool queries public DNS directly through the runtime resolver so you see the current public answer instead of cached assumptions.
Review and export the result
Inspect the addresses, review the status, and export the batch when you need to share or analyze it further.
What a domain-to-IP lookup is really telling you
The public DNS answer is useful context, not a complete health report.
What a lookup actually does
A hostname like example.com is just a human-friendly label. The network still routes traffic by IP, so DNS exists to map that label to the addresses a client can actually connect to. A domain-to-IP lookup asks public resolvers for the current A and AAAA records, then returns the answer the internet is currently publishing for that name. It is one of the most useful first checks in DNS troubleshooting because it shows the route and the public footprint, but it is not a full health check on the service behind it.
Why one domain can return several IPs
This is common and usually healthy. Large sites spread traffic across several servers for redundancy, load balancing, or edge delivery. Content-delivery networks and multi-region deployments often publish several valid addresses for one hostname, which means the resolution result is broader than a single server or a single location. Seeing more than one IP is often a sign of a modern, resilient setup rather than a problem by itself.
How to read a failed lookup
Not every domain resolves, and the reason matters. NXDOMAIN means the name is not currently registered or does not exist in DNS. SERVFAIL or REFUSED usually indicate a resolver or authoritative problem. A timeout means no answer came back in time, which may be temporary network congestion rather than a domain-level issue. A strong diagnosis always begins by classifying the failure correctly instead of treating every empty result as the same problem.
Why the same domain can resolve differently over time
DNS is designed to change. Records carry TTL values, recursive resolvers cache answers, and infrastructure teams move services or shift traffic during migrations. A new IP may appear only after caches expire, so a result can differ from what you saw a few minutes earlier without being a contradiction. That is exactly why repeated checks and before-and-after comparisons matter when a change is underway.
Where this is genuinely useful
It helps after a site migration, when verifying a CDN or load-balancer configuration, when checking whether a domain still points to the right infrastructure, or when you need to map a wide portfolio of hostnames to the IPs they currently publish. It is also useful in monitoring: a domain that suddenly resolves to an unexpected set of addresses is often the first visible sign of an infrastructure change.
Who uses this tool
Infrastructure monitoring
Track where important domains are pointing and catch unexpected DNS changes before they become incidents.
Developer workflows
A fast way to confirm the current public IPs behind a hostname without juggling multiple terminal commands for a simple check.
Security research
Review large domain sets safely with SSRF protections and public-only resolution rules in place.
Privacy-first teams
No signup, no third-party API dependency, and no need to hand a domain to an external service just to understand where it resolves.
Security is part of the design
Every resolved address is checked against private, loopback, link-local, and cloud-metadata ranges before it is presented. That reduces the risk of DNS rebinding and keeps public-domain lookups from being used as a shortcut to probe internal infrastructure.
Frequently asked questions
Ready to check a hostname?
Use the lookup to inspect the public DNS path behind a domain before you move on to the next layer of troubleshooting.
Try the lookup