Reverse DNS Lookup

Ordinary DNS goes from a name to an address: the A record of a host name gives its IPv4 address. A reverse DNS lookup goes the other way, from an IP address to a host name. The name is kept in a PTR (pointer) record, published at a special name built from the address: under in-addr.arpa for IPv4 and ip6.arpa for IPv6 (RFC 1035 §3.5, RFC 3596 §2.5).

This tool asks our DNS resolver for the PTR record of the address you enter. Then, for each name it returns, the first 10 at most, it looks up that name's A record (AAAA for an IPv6 address) and checks that your address is among the answers. When a name leads back to the address, that is called forward-confirmed reverse DNS (FCrDNS); RFC 8601 calls the same test iprev. The resolver runs on the same server as this site and asks the name servers itself; the answers it got, and which resolver gave them, are in the Raw evidence panel under the result. The lookup only reads DNS: it never connects to the address.

The examples under the form ran on September 26, 2026, and all three passed: 8.8.8.8 and 2001:4860:4860::8888 both have the PTR name dns.google, which points back to each of them, and 80.241.213.11 is our own server, mx.mxverdict.com.

How does reverse DNS work?

The reverse name of an IPv4 address is its four numbers in reverse order, followed by in-addr.arpa: the PTR record of 80.241.213.11 is published at 11.213.241.80.in-addr.arpa. RFC 1035 gives the reason: “The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space.” Read from right to left, the name goes from the large network down to the one address, the same way a domain name goes from com down to a host, so each block of addresses can be a DNS zone of its own, handed to whoever holds the block.

For IPv6 the address is written out in full, one hexadecimal digit per label, again in reverse, under ip6.arpa (RFC 3596 §2.5). For 2001:4860:4860::8888 that is the 32-digit name 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa.

We followed the chain for our own server on September 26, 2026, with dig +trace -x 80.241.213.11. The root servers sent us to the servers of in-addr.arpa; those sent us to the servers for 80.in-addr.arpa (pri.authdns.ripe.net, rirns.arin.net and three more); those sent us to ns1.contabo.net and ns2.contabo.net, the name servers of our hosting provider, which hold 213.241.80.in-addr.arpa; and they answered with the PTR record mx.mxverdict.com.

So the PTR record of an address lives with whoever the address block is delegated to: your hosting company, cloud provider or internet provider, not the DNS host of your domain. That is why you set reverse DNS in your provider's control panel, while the A record that confirms it goes in your own domain's DNS. The two directions are often kept by different companies, and RFC 1035 already warned that, living in different zones, “the data may be inconsistent”. The forward check on this page is how you catch that.

Why mail servers check reverse DNS

A server that receives email can look up the reverse DNS of the address that connects to it and check that the name points back. RFC 8601 §3 describes this test and notes: “Often an MTA receiving a connection that fails this test will simply reject the connection.” Gmail requires it of all senders since February 1, 2024, as “valid forward and reverse DNS records”, and spells it out: “The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname,” and that host name “must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server.” Yahoo requires every sender to “Have a valid forward and reverse DNS record for your sending IPs” and recommends names that are “meaningful, non-generic”.

The same RFC also says: “There is some contention regarding the wisdom and reliability of this test.” For a server that sends to Gmail or Yahoo, their rules settle it; for other hosts, see whether reverse DNS is necessary.

The result opens with the verdict, a colored icon and a short label, next to the data that decided it, such as PTR of 8.8.8.8: dns.google · points back. A reverse DNS lookup ends in Pass, Warning or Could not check. There is no Fail: the lookup reports what DNS publishes for the address.

Pass: a PTR name points back to the address

The address has a PTR record, and at least one of its names has an A record (AAAA for an IPv6 address) that includes this same address. That is all the test asks: RFC 8601 §3 calls it successful when the address is among the addresses of its PTR names. Other names in the same PTR record that do not point back, or whose lookup failed, do not change a Pass; the result still lists each of them with what its lookup gave.

What the result shows

• Queried name. The reverse name we asked for, such as 8.8.8.8.in-addr.arpa, with a reminder that it is published by whoever controls the address block.
• Each PTR name and its forward lookup: points back, with the addresses the name has; does not point back, because its records name other addresses, because it is an alias (CNAME) that does not lead to this address, or because it has no such records or does not exist; could not check, with the resolver's reason; or not looked up, for a name that is not a usable host name.
• Names past the first 10 are listed as not checked (see below).
• Not a public internet address, with the kind of range, for a private or special address (see below).

The raw DNS answers, with the TTL of every record, are in the Raw evidence panel.

Warning: no reverse DNS name, or one that is not a host name

No PTR record. The result says what the resolver answered: NXDOMAIN, the reverse name does not exist, or NODATA (NOERROR with an empty answer), no PTR record at that name, which does not prove that the name exists (RFC 9824). Either way the address has no reverse DNS, and only the holder of the address block can add it (see how to set up reverse DNS). If you set it only just now, the resolver may still have its earlier answer, that there is no record, cached; when the answer says for how long, the result shows it.

A PTR name that is not a host name. The record holds something we cannot look up as a host name: the DNS root (.), a name with characters DNS has to escape, such as spaces, accented letters or a dot inside a label, or a name longer than DNS allows. We do not look such a name up, so it cannot point back; the holder of the address has to set a proper name. A proper host name is plainer still: “Allowable characters in a label for a host name are only ASCII letters, digits, and the `-' character” (RFC 1912 §2.1). A name that breaks only that rule, with an underscore for example, is still looked up like any other.

Forward-confirmed reverse DNS: does the name point back?

For each PTR name, the first 10 at most, we look up its A record (AAAA for an IPv6 address) and look for your address in the answer. This is the test of RFC 8601 §3: with the address as I and all the addresses of its PTR names as L, “this test is successful if I is an element of L.”

• Pass: at least one name points back.
• Warning: every name we looked up got an answer, and none of them includes the address: each name's A records name other addresses, or it has none, or it does not exist. The fix under the result depends on the name. For a name with no address records it gives the exact A record to add (AAAA for an IPv6 address). For a name that already points elsewhere it gives none, because adding this address there would send part of that name's traffic, a website's for example, to this address: choose a name used only by this server instead.
• Could not check: a forward lookup got no usable answer and no other name points back, or the address has more than 10 PTR names and none of the first 10 points back. We check only those, because a checker must limit the names it follows; RFC 8601 §3 mentions SPF's limit of 10 as an example. Receiving mail servers must stop somewhere too (RFC 8601 §3), so one PTR name per address is the safe setup.

A PTR name that is an alias (CNAME) counts as pointing back when the alias leads to the address, as it does for a receiving server that follows the alias. RFC 1912 §2.1 still asks for more: “PTR records must point back to a valid A record, not a alias defined by a CNAME.”

Private and special addresses

An address such as 192.168.1.10, 10.0.0.5 or 127.0.0.1 is not a public internet address, and the result says so, with the kind of range. The private blocks of RFC 1918 are used inside many separate networks at once, so public DNS cannot name their addresses, and resolvers answer such reverse lookups themselves: RFC 6303 has them return a name error (NXDOMAIN) for these zones unless configured otherwise. Our resolver runs Unbound with its default settings. On September 27, 2026, it answered the reverse lookup of 192.168.1.1 with NXDOMAIN and gave 127.0.0.1 the name localhost. By Unbound's documentation, it should also answer NXDOMAIN for the reverse zones of the other private ranges and of many reserved ones, give ::1 the name localhost too, and resolve that name back to both addresses.

So a private address normally gives a Warning, no PTR record, and 127.0.0.1 gives a Pass with localhost. Neither says anything about a real server. The reverse name of a private address, if there is one, is known only to the DNS server of the network that uses it.

Could not check

The PTR query got no usable answer: it timed out, the resolver reported a server failure (SERVFAIL) or refused the query, or the answer could not be decoded safely. That says nothing about whether the address has reverse DNS, and we never count it as a Pass or a Warning. The same holds when the PTR names are there but their forward lookups failed (see above). A Could not check result is not reused, so you can try again right away.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

A PTR record in your domain's own DNS zone does not give your server reverse DNS: the record has to be in the reverse zone of the address block (see how reverse DNS works). The reverse DNS name of a server's address is set by whoever owns that address: your hosting company, cloud provider or internet provider, not your DNS host. If a mail provider or sending service delivers your mail, the sending addresses are theirs, and so is their reverse DNS: ask the service before you change anything. Twilio SendGrid lets you set reverse DNS for a dedicated IP yourself: in Settings, Sender Authentication, it gives you the records to add at your DNS host.

1. Pick the host name, for example mail.example.com: a name used only by this server, ideally also the name the server gives when it greets other mail servers.
2. Publish its A record (and AAAA for an IPv6 address) with the server's address (for mail.example.com, the name is mail), at your DNS host; the A record lookup shows the steps at Cloudflare, GoDaddy and Namecheap. At Cloudflare, set the record to DNS only: a proxied record is answered “with Cloudflare anycast IP addresses”, so the name would not point back to your server. Several providers below check the A record before they accept the PTR name.
3. Set the PTR record at the provider of the address, as described below.
4. Look the address up here. A Pass means both directions match.

A Warning result always comes with the steps to fix it; so does a Could not check result for an address with too many PTR names.

Amazon Web Services, Google Cloud and Microsoft Azure

• AWS (Amazon EC2). Reverse DNS is set on an Elastic IP address, and AWS requires the A record first: the name must resolve to that Elastic IP. In the EC2 console, choose Elastic IPs, select the address, then Actions, Update reverse DNS; enter the domain name, type update to confirm, and choose Update. With the AWS CLI:

  aws ec2 modify-address-attribute \
    --allocation-id eipalloc-abcdef01234567890 \
    --domain-name mail.example.com

  AWS notes that an Elastic IP with a reverse DNS record stays locked to your account until the record is removed.
• Google Cloud (Compute Engine). PTR records exist only for a VM's primary network interface, not for load balancers or Cloud NAT. Google first asks you to verify that you own the domain, in Search Console or by adding an A record with the VM's external IP. Then edit the VM's primary network interface (Public DNS PTR record, PTR domain name), or run:

  gcloud compute instances update-access-config INSTANCE_NAME \
    --public-ptr --public-ptr-domain mail.example.com

  For the VM's IPv6 address, run the same command with --ipv6-public-ptr-domain=mail.example.com in place of both options. When you remove the record, reverse lookups get a default name under googleusercontent.com.
• Microsoft Azure. Reverse DNS is a setting of the public IP address resource, and only for IPv4. The Azure portal cannot set it; use the Azure CLI or PowerShell. Azure accepts the name only if it resolves to the same public IP (or to a name in your subscription):

  az network public-ip update --resource-group MyResourceGroup \
    --name PublicIp --reverse-fqdn mail.example.com.

  For an address that has no PTR record yet, Azure also wants a DNS name label: add --dns-name with one. Azure creates no reverse DNS record unless you set one.

Hetzner, OVHcloud, DigitalOcean, Akamai (Linode) and Contabo

• Hetzner Cloud. In Hetzner Console, select the server and open Networking; edit the rDNS entry to the right of the address.
• OVHcloud. In the Control Panel, Network, Public IP Addresses (for a Public Cloud instance: Public Cloud, your project, Public IPs): the menu button (three dots) in the row of the address, then Configure the reverse DNS. In the Public IP Addresses guide, OVHcloud wants the name with a final dot (mail.example.com.) and checks at once that its A or AAAA record points back; the Public Cloud guide also asks for the A record to be in place first. Either way, publish that record first.
• DigitalOcean. There is no PTR field: DigitalOcean creates the PTR record from the Droplet's name, which must be a full domain name such as mail.example.com. Give the Droplet that name.
• Akamai (Linode). Add the A (and AAAA) record first. Then in Cloud Manager, open the Linode, the Network tab, the menu of the address, and Edit RDNS. Until you do, the address has a default name under ip.linodeusercontent.com.
• Contabo. In the Customer Panel, Reverse DNS Management lists the addresses of your servers; the pencil icon changes the PTR value, and “Add a PTR record for an IPv6 address” sets one for an IPv6 address that has none. The reverse DNS of our own server, mx.mxverdict.com, is kept at Contabo.

When the reverse zone is delegated to your DNS servers

The holder of an address block can have its reverse zone delegated to name servers of its own, the way 213.241.80.in-addr.arpa is delegated to Contabo's. Then the PTR records go into that zone like any other record. In zone-file form, for the address 203.0.113.25:

$ORIGIN 113.0.203.in-addr.arpa.
25   IN  PTR  mail.example.com.

The final dot after mail.example.com. matters: without it the name is read as relative to the zone. A block smaller than 256 addresses has no in-addr.arpa zone of its own; RFC 2317 describes a way to delegate its reverse DNS anyway, and your provider says whether it does.

1. To check reverse DNS, enter the IP address in the form at the top of this page: IPv4 such as 80.241.213.11 or IPv6 such as 2001:4860:4860::8888. An address with a port, in brackets, or written as its reverse name (11.213.241.80.in-addr.arpa) works too.
2. Select Check. The result shows the PTR name and whether it points back to the address.

Every result has its own address, such as /reverse-dns-lookup/8.8.8.8; however the address was written, it leads to that one page. An IPv4 address written in IPv6 form, ::ffff:8.8.8.8, the way a server that listens on IPv6 sees an IPv4 visitor (RFC 3493 §3.7, RFC 4291 §2.5.5.2), is looked up as 8.8.8.8: its reverse name lives under in-addr.arpa. On September 26, 2026, the ip6.arpa name of ::ffff:8.8.8.8 did not exist (NXDOMAIN from the public resolver 1.1.1.1). A domain name is refused, because reverse DNS starts from an address; to find the addresses of a domain, use the A record lookup.

How to check reverse DNS from the command line

On macOS and Linux, dig -x builds the reverse name for you, and +short prints only the answer:

dig -x 8.8.8.8 +short
dig -x 2001:4860:4860::8888 +short

On September 26, 2026, both printed dns.google.; the dot at the end is the root of DNS. To check the forward direction too, look the name up: dig dns.google A +short printed 8.8.4.4 and 8.8.8.8, so the name points back. dig +trace -x with an address shows the whole delegation chain described above.

nslookup does a reverse lookup when you give it an address, on Windows as on macOS, and host does too:

nslookup 8.8.8.8
host 8.8.8.8

On macOS on September 26, 2026, they answered:

8.8.8.8.in-addr.arpa	name = dns.google.
8.8.8.8.in-addr.arpa domain name pointer dns.google.

In Windows PowerShell, ask for the PTR record of the reverse name, the address written backward; for 80.241.213.11:

Resolve-DnsName -Name 11.213.241.80.in-addr.arpa -Type PTR

Enter the address in the form above, or run dig -x with it: the PTR record gives the host name of the address. That is the name the holder of the address chose, and only that. It is not a list of the websites or domains on the address: one address can serve many sites, and HTTP tells them apart by the Host header, “enabling the origin server to distinguish among resources while servicing requests for multiple host names” (RFC 9110 §7.2).

Two lookups from September 26, 2026 show what that means. www.github.com led to 140.82.121.3, and the PTR record of 140.82.121.3 is lb-140-82-121-3-fra.github.com: a host name under github.com, not github.com itself. Our own site, mxverdict.com, pointed to 104.21.39.143 and 172.67.146.29, addresses of Cloudflare, which serves our website. Neither had a PTR record, so a reverse lookup of them leads nowhere near mxverdict.com.

When there is a name, check that it points back before you trust it. A PTR record can hold any domain name, including one in someone else's domain; Azure, for one, checks the name before it accepts it, because “A third party shouldn't have access to create reverse DNS records for Azure service mapping to your DNS domains.” Only the owner of the domain can make the name point back, and that is what the forward check on this page tests.