Free DNS tool

Reverse DNS Checker

Look up the PTR record for any IPv4 address, confirm it is forward-confirmed (FCrDNS), and find the reverse DNS issues that quietly hold back your email delivery.

No login required. We query live DNS and never store your IP address.

Try it instantly

Run a reverse DNS check on a public resolver IP, or enter your own above.

Next steps after reverse DNS
BlacklistCheck blacklist statusMXLook up MX recordsGradeFull reputation report
Reverse DNS, explained

What is reverse DNS and a PTR record?

Reverse DNS, or rDNS, resolves an IP address back to a hostname. It is the mirror image of the forward lookup you use every day, where a name like example.com resolves to an IP address. The reverse direction answers a different question: given the address 192.0.2.25, what hostname does the owner of that address say belongs to it? The answer lives in a single DNS record called a PTR, short for pointer record.

PTR records do not live in your normal domain zone. They live in a special reverse zone under in-addr.arpa that is controlled by whoever holds the IP address block, usually your host or ISP. For IPv4 the address is reversed octet by octet and the suffix is appended, so 192.0.2.25 becomes 25.2.0.192.in-addr.arpa. That is the name a receiving server queries when it wants to know who is really behind a connecting IP.

Why mail servers require reverse DNS

Reverse DNS is one of the first trust signals a receiving mail server reads. The moment your server opens an SMTP connection, the receiver looks up the PTR record for your IP. If no record comes back, or if the hostname looks like a throwaway ISP string, the message starts the conversation at a disadvantage before SPF, DKIM, or DMARC are even evaluated. Many providers reject or heavily downgrade mail from IPs with no valid reverse DNS, and the largest mailbox providers list it among their baseline sender requirements.

RFC 1912 has recommended a matching PTR record for every mail-sending host for decades, and RFC 5321 expects the name a server announces in its HELO or EHLO greeting to be a real, resolvable hostname. Reverse DNS ties those expectations to the IP itself, which is far harder to forge than a header. A clean PTR record tells the receiver that a responsible owner stands behind the address.

Forward-confirmed reverse DNS (FCrDNS)

A PTR record on its own is only half the picture. The stronger signal that receivers actually trust is forward-confirmed reverse DNS, often shortened to FCrDNS. It requires both directions to agree:

  1. The IP has a PTR record that resolves to a hostname, for example mail.yourdomain.com.
  2. That hostname has an A record that resolves back to the very same IP address.

When both checks line up, the IP and the hostname vouch for each other, and that round trip is what receiving servers grade. This tool runs both lookups for you and tells you plainly whether the address is forward-confirmed or whether one side of the loop is broken.

How to set up a PTR record

Because the reverse zone belongs to the IP owner, you cannot create a PTR record in your own domain registrar. The setup is a short, deliberate process:

  1. Decide on a hostname. Pick a name on a domain you control, such as mail.yourdomain.com, and create an A record for it that points to your sending IP.
  2. Ask the IP owner to add the PTR. Contact your host, ISP, or cloud provider and request a PTR record mapping the IP to that hostname. Cloud platforms usually expose this in a control panel; smaller hosts handle it by support request.
  3. Confirm both directions. Once the change propagates, re-run this checker to verify the PTR resolves to your hostname and the hostname resolves back to the IP, completing forward confirmation.

Generic versus branded PTR hostnames

Not every PTR record helps you equally. Many IPs ship with a generic default name that bakes the address into the hostname, such as 192-0-2-25.static.example-isp.net. That string is technically valid, but it signals a shared or unconfigured address and can weigh on deliverability. A branded hostname that matches your sending domain, like mail.yourdomain.com, reads as a deliberate, owned mail server and aligns neatly with the name your server announces at HELO time. If your reverse DNS is generic, ask whoever controls the IP to set a branded hostname instead.

Reverse DNS is only one layer of sender trust. Pair a clean PTR record with a strong sender reputation, confirm your IP is not on any blacklist, and check that your MX records point where you expect.

Frequently asked

Reverse DNS and PTR questions

What is reverse DNS and what is a PTR record?
Reverse DNS resolves an IP address back to a hostname, the opposite of a normal lookup that turns a name into an IP. The answer comes from a PTR (pointer) record stored in a reverse zone under in-addr.arpa. For the IP 192.0.2.25 the reverse name is 25.2.0.192.in-addr.arpa, and its PTR record holds the hostname the address owner has assigned, such as mail.yourdomain.com.
How do I check the reverse DNS of an IP address?
Enter the IPv4 address in the checker above. It performs a live PTR lookup, then resolves that hostname forward to confirm it points back to the same IP (the FCrDNS check). You can cross-check from a terminal with dig +short -x 192.0.2.25 on Linux or macOS, but the tool also verifies the forward match and flags generic hostnames, which a raw lookup does not.
Why does email need reverse DNS?
Receiving mail servers read the PTR record of your sending IP as an early trust signal during the SMTP connection. An IP with no reverse DNS, or with a mismatched or generic hostname, is a common spam indicator, so many providers reject or downgrade the mail. RFC 1912 has long recommended a matching PTR for every mail host, and major mailbox providers list valid reverse DNS among their baseline requirements for senders.
How do I set up a PTR record?
PTR records are managed by whoever owns the IP block, not by your domain registrar, so you cannot add one in your own DNS zone. Create an A record for a hostname you control, such as mail.yourdomain.com, pointing to your sending IP, then ask your host, ISP, or cloud provider to add a PTR record mapping that IP to the hostname. Re-check once the change propagates to confirm both directions agree.
What is forward-confirmed reverse DNS (FCrDNS)?
FCrDNS is a two-way verification. First the PTR record of an IP resolves to a hostname, then the forward lookup of that hostname resolves back to the same original IP. When both directions match, the IP and the hostname vouch for each other, which is a far stronger signal than a one-way PTR lookup. Most spam filters and mail servers grade this round trip rather than the PTR alone.
What makes a good PTR hostname?
A good PTR hostname is branded and resolvable: a name on a domain you control, like mail.yourdomain.com, that has a matching A record back to the IP. Avoid generic defaults that embed the address, such as 192-0-2-25.static.example-isp.net, because they read as shared or unconfigured space. Ideally the PTR hostname also matches the name your server announces in its HELO or EHLO greeting.
Who controls the PTR record for an IP address?
The owner of the IP address block controls it, which is typically your ISP, hosting provider, or cloud platform such as AWS, Google Cloud, or Azure. Reverse DNS lives in a zone delegated to that block holder, not in your registrar account, so you request the PTR change from them. Larger providers often offer a self-service control panel, while smaller ones handle it through a support ticket.
What happens if an IP has no reverse DNS?
Without a PTR record, receiving servers cannot confirm a hostname for the connecting IP, so they often reject the message outright or apply a steep spam penalty. The IP is also more likely to attract blocklist attention. Because reverse DNS is checked at connection time, a missing PTR can hold back mail even when SPF, DKIM, and DMARC all pass, which is why every sending IP should have a valid, forward-confirmed PTR record.
How long does a PTR record take to take effect?
Reverse DNS changes usually begin working within a few minutes to an hour, though some resolvers cache the old value for the length of the previous TTL, which can be a few hours. You can typically start testing 30 to 60 minutes after the change and expect full consistency within a day. Re-run this checker afterward to confirm the PTR resolves and forward-confirms.
Can one IP address have more than one PTR record?
It is technically possible but not recommended. Multiple PTR records on a single IP produce unpredictable results, because different lookups can return different hostnames, which undermines the trust the record is meant to build. Keep exactly one PTR per sending IP, pointing to a single hostname that forward-confirms back to that IP.
Why does my PTR record not match my forward DNS?
Forward-confirmed reverse DNS requires both directions to agree, so a mismatch means the hostname in your PTR has no matching A record, or the forward and reverse lookups return different values. The fix is to make sure the hostname your PTR points to has an A record that resolves back to the exact same IP. Until both line up, receivers treat the reverse DNS as broken even though a PTR exists.
Do I need a PTR record if I send through a third-party email service?
Usually not. When you send through a hosted email or marketing platform, that provider owns the sending IPs and is responsible for their reverse DNS, so it handles the PTR for you. You only manage PTR records when you send from your own mail server on an IP you control. If you run your own infrastructure, every sending IP should have a valid, forward-confirmed PTR.
Keep exploring

Related tools & resources

Hand-picked next steps for this topic: checkers, guides, and plain-English definitions that go deeper.

Tool MX Lookup Resolve mail-exchange records and confirm your mail routing. Tool Blacklist Checker Scan 10+ major DNS blacklists for any domain or IP in seconds. Guide DNS Records for Email Configure MX, SPF, DKIM, DMARC, and PTR records the right way. Term PTR Record A DNS record that maps an IP address back to a hostname (reverse DNS). Required for proper mail server config. Term rDNS (Reverse DNS) Resolving an IP address to a hostname using PTR records. Essential for email deliverability. Term Forward-confirmed Reverse DNS (FCrDNS) A validation where a PTR record resolves to a hostname, and that hostname resolves back to the original IP.