InboxRatio
Check your domain

Free tool

Reverse DNS checker

Run a reverse DNS lookup for any IPv4 or IPv6 address. The checker fetches the PTR record, then forward-confirms it — the same FCrDNS test Gmail and most receivers apply to every IP that connects to them. Enter a domain instead and it checks the PTR of the domain's MX hosts.

Enter your sending IP for the real check. A domain input checks the PTR of the domain's inbound MX hosts instead — labelled accordingly.

Why receivers care about the reverse path

When your mail server connects to Gmail, the first thing Gmail knows about you is your IP address. Before a single SMTP command is processed, it runs a PTR lookup on that IP. A legitimate mail server has a name; a botnet-infected laptop on a residential connection usually has either no PTR or a generic one stamped out by the ISP. That single lookup filters out an enormous share of junk before content filtering even starts, which is why the requirement made it into Gmail's published sender guidelines as a hard rule rather than a recommendation.

The check has three outcomes, and this tool reports which one you land on:

  • No PTR. The reverse zone has no entry for the IP. Several large receivers refuse the connection at this point — the mail never gets far enough to be judged on content.
  • PTR without forward confirmation. A hostname comes back, but resolving that hostname does not lead to the same IP. Receivers treat this as unverified: anyone controlling a reverse zone can write any name into it, so the forward step is what makes the claim checkable.
  • FCrDNS pass. PTR resolves to a hostname, hostname resolves back to the IP. This is the state every sending IP should be in.

PTR lookup for an IP vs. a domain

The PTR that matters for your deliverability belongs to the IP your outbound mail leaves from — your SMTP server, or your email platform's infrastructure. If you send through a provider, the PTR of their IPs is their responsibility (and the well-run ones handle it; our deliverability rankings reflect how well in practice). If you run your own server, it is yours.

Entering a domain here checks something adjacent: the PTR records of the domain's inbound MX hosts. That is still worth knowing — a mail server that receives on an IP with broken reverse DNS is often misconfigured in other ways — but it is not your sending reputation. The tool labels domain-mode results explicitly so the two are never confused. To find your real sending IP, open a message you sent, view the raw source, and read the IP from the last Received header added by the recipient's server — or paste the whole thing into our header analyzer.

What a good PTR looks like

10.113.0.203.in-addr.arpa → mail.example.com
mail.example.com → 203.0.113.10   ✓ forward-confirmed

Beyond existing and confirming, the hostname itself carries signal. mail.example.com reads as deliberate infrastructure; 203-0-113-10.dyn.isp.example reads as a dynamic consumer line, and some receivers pattern-match exactly that. Use a hostname on a domain you control, ideally one that relates to the sending domain your recipients see.

Limits of this check

Reverse DNS is one gate among several. Passing FCrDNS says nothing about your SPF, DMARC, or whether the IP sits on a blocklist — run the blacklist checker for that. IPv6 senders should also know that receivers hold IPv6 mail to stricter authentication standards, since reverse zones there are frequently auto-generated. And a PTR check is a snapshot: if your provider rotates your IP, the answer changes with it.

For the whole picture in one pass — SPF, DKIM, DMARC, MX, and the PTR state of your MX hosts together — use the full email DNS check.

Frequently asked questions

What is a reverse DNS lookup?

A normal DNS lookup turns a name into an IP; a reverse DNS lookup turns an IP back into a name via its PTR record. For 203.0.113.10 the query goes to 10.113.0.203.in-addr.arpa, and the answer is a hostname like mail.example.com. Receiving mail servers run this lookup on every connecting IP.

What is FCrDNS (forward-confirmed reverse DNS)?

The two-step test receivers actually apply: look up the IP's PTR hostname, then resolve that hostname forward and check it comes back to the same IP. A PTR that points at a name which resolves elsewhere (or nowhere) fails the confirmation and counts for little. This tool runs both steps and reports which stage failed.

Do I need a PTR record to send email?

Effectively yes. Gmail's sender guidelines state that sending IPs must have a PTR record and that the PTR hostname must resolve back to the same IP. Many receivers refuse SMTP connections outright from IPs without reverse DNS, and generic PTRs like 1-2-3-4.dynamic.isp.example are treated almost as badly as none.

How do I fix a missing or wrong PTR record?

You usually cannot set it yourself in your own DNS zone — PTR records live in the reverse zone owned by whoever controls the IP block. On AWS, Hetzner, DigitalOcean and most clouds it is a field in the console; with an ISP or colo provider it is a support ticket. Set it to your mail server's real hostname, then make sure that hostname has a matching A record.

Why does the domain mode check MX hosts instead of my sending IP?

A domain doesn't have a PTR — IPs do. When you enter a domain, the only mail-related IPs discoverable from public DNS are its inbound MX hosts, so the tool checks those and labels the result accordingly. Your outbound sending IP (your ESP's or your own SMTP server's) can be entirely different: find it in a sent message's Received headers and check it directly.