---
title: Mail rejected for missing PTR? How to do a reverse DNS lookup with the Reverse DNS Lookup
description: Gmail bounces your mail with 550 5.7.25 and something about a PTR record. A reverse DNS lookup turns an IP address back into a hostname by querying its PTR record under in-addr.arpa or ip6.arpa. For a mail server that name must exist and resolve back to the same IP. Here's how to check it in seconds with the free Reverse DNS Lookup, what a correct and a missing PTR look like, and how to fix it.
canonical: https://watchfor.io/blog/how-to-do-a-reverse-dns-lookup
---

# Mail rejected for missing PTR? How to do a reverse DNS lookup with the Reverse DNS Lookup

2026-10-04 · WatchFor Team · Guides · guides, dns, email

Gmail bounces your mail with 550 5.7.25 and something about a PTR record. A reverse DNS lookup turns an IP address back into a hostname by querying its PTR record under in-addr.arpa or ip6.arpa. For a mail server that name must exist and resolve back to the same IP. Here's how to check it in seconds with the free Reverse DNS Lookup, what a correct and a missing PTR look like, and how to fix it.

To do a reverse DNS lookup, query the PTR record for the IP address. For
IPv4 you reverse the four octets and append `in-addr.arpa`, so
`209.85.220.41` becomes `41.220.85.209.in-addr.arpa`. For IPv6 you reverse
the address one hex digit at a time under `ip6.arpa`. The answer is the
hostname the owner of the address gave it. For a mail server, that name must
also resolve forwards to the same IP: forward-confirmed reverse DNS.

The free [Reverse DNS Lookup](/reverse-dns-lookup) builds the reverse name
for you, asks a resolver from a WatchFor location and shows the PTR record,
the response code and the time it took. No signup.

## What this tool answers

*What name does this IP address have in DNS, if any?* Reach for it when mail
from a new server bounces or lands in spam, before you put a fresh cloud IP
into production as a mail sender, when an address in your logs needs a name,
or after you set a PTR in your provider's panel and want to see it live.

## A real example

### Doing a reverse DNS lookup for a mail server

The bounce looks like this (Gmail, shortened):

```text
550-5.7.25 The IP address sending this message does not have a PTR record setup,
550-5.7.25 or the corresponding forward DNS entry does not point to the sending IP.
```

Gmail's sender guidelines require every sending IP to have a PTR record whose
name resolves back to that IP, and other large mailbox providers treat a
missing PTR as a strong spam signal. We checked two addresses: one that is
known to send mail correctly, and one that was never meant to.

First, `209.85.220.41`, an address Google's own mail servers send from (it
sits in `209.85.128.0/17`, listed in Google's SPF record). In the
[Reverse DNS Lookup](/reverse-dns-lookup) we entered the IP:

![The Reverse DNS Lookup for 209.85.220.41: 32 ms resolve time, PTR, NOERROR, 1 record: address 209.85.220.41, TTL 21600, type PTR, value mail-sor-f41.google.com.](/blog/how-to-do-a-reverse-dns-lookup-ptr.webp)

`NOERROR` in 32 ms and one PTR record: `mail-sor-f41.google.com`, cached
for 21,600 seconds (6 hours). A forward lookup of
that name returns `209.85.220.41` again (see the command line below), so
forward and reverse agree. This is what a mail server's reverse DNS should
look like.

Then `172.66.147.243`, one of the addresses `example.com` resolves to, a
Cloudflare-proxied web address:

![The Reverse DNS Lookup for 172.66.147.243: 22 ms resolve time, PTR, NOERROR, 0 records, No records returned](/blog/how-to-do-a-reverse-dns-lookup-none.webp)

Zero records: the address has no name at all. (Public resolvers and
Cloudflare's own nameserver answer this query with `NXDOMAIN`, as the
command-line section shows; the tool reports the same empty answer as
`NOERROR` with 0 records. Either way, there is no PTR.) For a website that's
normal; browsers never look. If this address were sending your mail, it is
exactly what produces the 5.7.25 bounce.

**The answer:** the fix for the bounce is a PTR record on the *sending IP*,
pointing at a hostname that resolves back to it, such as
`mail.example.com` with an A record for the same IP. Only whoever controls
the IP block can create it, which is your hosting or cloud provider, not
your domain's DNS host:

- **AWS:** request reverse DNS for an Elastic IP in the EC2 console (or with
  `aws ec2 modify-address-attribute --domain-name`). The A record must
  exist first.
- **Most VPS and dedicated hosts** (Hetzner, OVH, Linode, Vultr…): set
  "Reverse DNS" or "PTR" on the IP in the control panel. DigitalOcean uses
  the droplet's name.
- **Office or home line:** ask the ISP. Residential IPs usually can't get a
  custom PTR and shouldn't send mail directly; relay through your mail
  provider instead.

Use a name that matches what the server says in its SMTP `HELO`/`EHLO`, and
recheck here once the provider confirms.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Resolve time** | How long the resolver took. Green under 50 ms, amber under 200 ms, red above. Speed, not correctness. |
| **PTR** | The record type asked for. The tool builds the `in-addr.arpa` or `ip6.arpa` name from the IP you type. |
| **NOERROR** (green) | The query was answered. Check the record count: 1 record is a PTR; **0 records** means the address has no PTR. |
| **NXDOMAIN** (amber) | The name doesn't exist. Reverse lookups for an address without a PTR usually come back this way from resolvers; the tool may show them as 0 records instead. |
| **SERVFAIL / REFUSED** (amber) | The reverse zone's nameservers are broken or refused to answer. Usually the provider's problem; retry, then contact them. |
| **N records** | How many PTR records came back. One is normal; several are legal but confuse some mail filters. |
| **Resolver** | Which resolver answered, when the tool reports it. |
| **Record row** | The hostname the IP points to. Copy it and look it up forwards to confirm it returns the same address. |

## More ways to use it

- **Before you launch a mail server.** Check the new IP has a PTR, that the
  name resolves back, and that the name doesn't look like a dynamic pool
  (`host-203-0-113-7.dynamic.isp.example`). Then check
  [SPF, DKIM and DMARC](/blog/spf-dkim-dmarc-explained).
- **Identify an address in your logs.** The PTR often names the provider or
  the service: `…compute.amazonaws.com`, `…googleusercontent.com`,
  `crawl-….googlebot.com`. The [IP Address Lookup](/ip-lookup) adds the ASN
  and prefix; the [IP lookup guide](/blog/how-to-look-up-an-ip-address)
  shows how to verify a crawler that way.
- **After changing a PTR.** Reverse zones are cached like any other DNS, for
  the PTR's TTL. If the old name still shows, wait that long.
- **IPv6 mail.** If your server has an AAAA record and sends over IPv6, the
  IPv6 address needs its own PTR. Gmail checks whichever address connected.
- **Audit a whole range.** Look up a few addresses from your block; providers
  sometimes leave generic names on addresses you assumed were set.

## Tips and gotchas

- **The PTR lives with the IP owner.** Adding a PTR record in your domain's
  DNS zone does nothing; the `in-addr.arpa` zone for your address is run by
  whoever owns the IP block.
- **Forward and reverse must match.** A PTR pointing at a name that doesn't
  resolve, or resolves to a different IP, fails the same checks as no PTR.
- **One PTR per address.** Several mail domains can share one server; give
  the IP one neutral name (`mail.provider-example.net`) instead of many.
- **Generic names hurt.** Filters treat names with the IP baked in and words
  like `dynamic`, `dsl` or `pool` as residential and score them down, even
  though a PTR exists.
- **A PTR isn't proof of identity.** Anyone who controls an IP can set its
  PTR to any name, `google.com` included. Only the forward check makes it
  trustworthy.
- **Blocklists are a separate problem.** A perfect PTR won't help a listed
  IP; run the [blacklist checker](/blacklist-checker) too. More causes in
  [why emails go to spam](/blog/why-emails-go-to-spam).

## Check it from the command line too

`dig -x` builds the reverse name for you:

```bash
dig +noall +answer -x 209.85.220.41
dig +noall +answer mail-sor-f41.google.com A
```

```text
41.220.85.209.in-addr.arpa. 1497 IN	PTR	mail-sor-f41.google.com.
mail-sor-f41.google.com. 1498	IN	A	209.85.220.41
```

PTR name, then the A record pointing back at the same address: forward-
confirmed. And the address without a name:

```bash
dig +noall +comments -x 172.66.147.243 @1.1.1.1 | grep status
```

```text
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35313
```

`NXDOMAIN` from Cloudflare's resolver: no PTR, the same conclusion as the
tool's empty answer. To see that the address really is in
Google's sending range, read their SPF record:

```bash
dig +short TXT _netblocks.google.com
```

```text
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ~all"
```

`nslookup 209.85.220.41` and `host 209.85.220.41` give the same PTR on
Windows and macOS.

## Keep watching it

A PTR can disappear when an IP is reassigned or a provider migrates its
reverse zones, and you find out from bounces. A [DNS monitor](/dns-monitoring)
with record type **PTR** and your server's IP as the target looks up the
reverse name on a schedule (a hostname target works too: it's resolved
first, then every address is checked in reverse). The **Expected DNS
Records** rule, set to your mail hostname, opens an incident when the PTR
changes or goes missing.

## FAQ

**What is a PTR record?**
A DNS record that maps an IP address to a hostname: the reverse of an A or
AAAA record. It lives in the `in-addr.arpa` (IPv4) or `ip6.arpa` (IPv6) zone
run by the owner of the IP block.
[DNS record types explained](/blog/dns-record-types-explained) covers the rest.

**How do I fix "does not have a PTR record setup"?**
Ask whoever provides the sending IP (cloud, host or ISP) to set a PTR to a
hostname you control, and add an A record for that hostname pointing to the
same IP. Then wait for the old negative answer to expire from caches.

**How long does a reverse DNS change take?**
The new PTR is live at the provider immediately; resolvers that cached the
old answer keep it for its TTL, or for the zone's negative TTL if there was
no PTR before. Usually minutes to a few hours.

---

Canonical page: https://watchfor.io/blog/how-to-do-a-reverse-dns-lookup · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt