Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — Reverse DNS Check

Does your sending IP look legitimate?

Enter an IP or hostname and we'll check its reverse DNS (PTR) and confirm whether it forward-confirms — the round trip receiving servers use to decide if a sender is trustworthy. Runs in your browser, no signup.

Request infrastructure review How rDNS works

Looks up the PTR and forward records over DNS-over-HTTPS. IPv4 and IPv6 supported. Nothing is sent or stored.

/ What this checks

A reverse DNS check looks up the PTR record of a sending IP — the name the IP maps back to — and then confirms whether that name maps forward to the same IP. That round trip is forward-confirmed reverse DNS, or FCrDNS, and it's one of the first things a receiving mail server checks. A missing PTR gets mail rejected by many providers outright; a PTR that doesn't forward-confirm, or a generic provider-default name, is treated as suspicious.

For any IP you send production email from, this is a baseline you want green before you worry about anything else. Authentication proves the message is from your domain; reverse DNS proves the connecting server is a real, deliberately configured mail host rather than a random address in a pool. This tool reads both directions and tells you whether your IP passes the round trip receivers rely on.

  • PTR required

    Many receivers reject mail from an IP with no PTR record outright, before authentication is even considered. A missing PTR is a hard deliverability blocker.

  • FCrDNS

    The round trip — PTR points to a name, the name points back to the IP — is what receivers trust. A PTR that doesn't forward-confirm carries little weight.

  • Set by the IP owner

    Unlike SPF or DKIM, you can't set a PTR in your own DNS — it's controlled by whoever owns the IP block: your host, cloud, or ISP.

  • Avoid generic

    A provider-default PTR like 203-0-113-5.pool.host.net signals a shared pool. Serious senders want a PTR reflecting their own mail hostname.

/ How rDNS works

How does the reverse round trip actually work?

Normal DNS turns a name into an address: you ask for the IP of a hostname. Reverse DNS does the opposite — it turns an address back into a name using a special PTR record, stored under a reversed form of the IP. When a mail server receives a connection, it takes the connecting IP, looks up its PTR to get a hostname, then looks up that hostname's forward record to see if it points back to the same IP. If the loop closes, the sender forward-confirms. 

# The round trip a receiver performs
1. connecting IP        203.0.113.5
2. PTR lookup           5.113.0.203.in-addr.arpa  ->  mail.example.com
3. forward lookup       mail.example.com          ->  203.0.113.5
4. do they match?       yes  ->  FCrDNS passes (trusted)
                        no   ->  PTR set but not confirmed (weak)
                        none ->  no PTR at all (often rejected)

The crucial detail is who controls each half of that loop. The forward record — the hostname pointing to the IP — lives in your normal DNS, where you control it. The PTR record lives in the reverse zone for the IP block, which is controlled by whoever owns that block: your hosting provider, cloud platform, or ISP. This split is why reverse DNS trips people up. You can publish perfect SPF, DKIM, and DMARC yourself, but if the PTR is missing or wrong, you have to go to whoever owns the IP to fix it, often through a control panel or a support request, and on shared infrastructure you may not be able to set it at all.

That control question is also why dedicated sending IPs matter for reverse DNS specifically. On a shared IP, the PTR is whatever the provider set for the pool, usually a generic name you can't change — which means your reverse DNS reflects the provider, not you, and you're at the mercy of how the whole pool behaves. On a dedicated IP, the PTR can be set to your own mail hostname and forward-confirmed against your own DNS, giving you a clean, trusted, self-controlled round trip. For a serious sender, that control is part of the point of dedicated infrastructure.

The honest limit of any reverse DNS check is that it tells you the configuration is correct, not that your IP has a good reputation. A clean, forward-confirming PTR is necessary for trust but doesn't by itself guarantee inbox placement — an IP can have perfect rDNS and still carry a poor sending reputation from past behavior. Reverse DNS is the identity foundation that lets reputation be built on top of it; passing this check clears a hard requirement and removes a common, silent reason for rejection, but the ongoing work of building and protecting reputation sits above it.

/ Common problems

What are the common reverse DNS failures?

The most damaging failure is the simplest: no PTR at all. It usually happens when a server is spun up on a fresh IP and the reverse record is never set, because setting it requires a separate step at the IP owner that's easy to skip. The IP sends mail, the receiving servers find no PTR, and a meaningful share of that mail is rejected before authentication is even evaluated. The fix is a request to whoever owns the block, but the symptom — mysterious rejections from certain providers — often gets misdiagnosed as an authentication problem first.

The second is a PTR that exists but doesn't forward-confirm. This happens when the reverse record points to a hostname whose forward record was never created, or was changed and no longer matches the IP. The PTR check passes, so it looks fine at a glance, but receivers that verify the round trip see it break and discount the PTR accordingly. Because the two halves of the loop are controlled in different places, they drift out of sync more easily than you'd expect, especially after an IP migration or a hostname change.

The third is the generic PTR you can't change. On shared infrastructure, the provider sets a pool-style name for the whole block, and you inherit whatever reputation that pool carries while being unable to set a name of your own. It satisfies the basic check but signals shared, undifferentiated sending, and it ties your fate to every other sender on the same block — including ones you'll never meet and can't influence. This is the reverse-DNS case that dedicated infrastructure exists to solve, because a self-controlled PTR set to your own mail hostname, forward-confirmed against DNS you manage, is something a shared IP structurally can't ever give you no matter how careful you otherwise are with the rest of your setup.

/ Reverse DNS FAQ

Why does a sending IP need reverse DNS?
Receiving mail servers routinely check the reverse DNS (PTR record) of the IP connecting to them, and many reject or heavily penalize mail from an IP that has none. A missing PTR is one of the clearest signals of a misconfigured or untrustworthy sender, because legitimate mail infrastructure almost always has it set. For any IP you send production email from, a valid PTR isn't optional — it's a baseline requirement that several major providers enforce at connection time, before they even look at your authentication.
What is FCrDNS and why does it matter more than a plain PTR?
Forward-Confirmed reverse DNS (FCrDNS) is the round trip: the IP's PTR record points to a hostname, and that hostname's forward (A or AAAA) record points back to the same IP. A plain PTR proves a name is set; FCrDNS proves the name and the IP genuinely belong together, which is much harder to fake and therefore much more trusted. Receivers weight FCrDNS heavily because it confirms the sender controls both ends of the mapping. An IP with a PTR that doesn't forward-confirm is treated as more suspicious than you'd expect — passing FCrDNS is what you actually want, and a bare PTR on its own doesn't get you there.
What's wrong with a generic PTR record?
A generic PTR is the default name a hosting provider assigns, usually something like the IP address with dashes plus the provider's domain — for example, 203-0-113-5.pool.examplehost.net. It technically satisfies the 'has a PTR' check, but it signals that the IP is part of a shared or dynamic pool rather than dedicated, purpose-set mail infrastructure, and many filters treat generic-looking PTRs with suspicion. For serious sending, you want a PTR that reflects your own mail hostname, set deliberately, not the provider's default.
How do I set or fix reverse DNS for my IP?
Reverse DNS is controlled by whoever owns the IP block, not through your normal authoritative DNS for the domain. That means you set or change a PTR through your hosting provider, cloud platform, or ISP — usually in their control panel or by support request — rather than in your domain's DNS zone. This is a frequent source of confusion: you can publish SPF, DKIM, and DMARC yourself, but the PTR has to be set by the party that controls the IP. With dedicated sending infrastructure, this is set correctly once and stays under your control.
Does this tool send anything or store my IP?
No. The check runs in your browser using DNS-over-HTTPS to look up the PTR record and the forward record, the same lookups a receiving mail server performs. Nothing is sent to our servers, no email is dispatched, and the IP or hostname you enter isn't logged. It's a read-only series of DNS queries against public records.

A clean PTR is the floor. Reputation is built on top of it.

Reverse DNS set correctly is the start of a trusted sending IP. We run dedicated IPs with self-controlled, forward-confirmed rDNS, warmed and monitored so the reputation above it holds. Bring us your sending setup and we'll check the foundation.

Book infrastructure review

Related capabilities