Reverse DNS and IP Reputation: PTR Records and Deliverability

May 7, 2026 · Operations · ITProMail team

When a server connects to deliver mail, the receiving side looks at the connecting IP address before it reads the message. It asks whether the address has a sensible name, whether that name points back to the address, and whether the address has a history of sending good or bad mail. These checks are often invisible to the sender, but they strongly influence whether mail is accepted, filtered or delayed.

PTR records and reverse DNS

Forward DNS maps a name to an address, for example an A record for mail.example.net. Reverse DNS does the opposite: a PTR record in the reverse zone maps an IP address to a name. The reverse zone for IPv4 is under in-addr.arpa, and for IPv6 under ip6.arpa. A PTR record is set by whoever controls the IP block, which is usually the hosting provider, not the domain owner.

You can query a PTR record with dig:

dig -x 203.0.113.25 +short
mail.example.net.

If the answer is empty, a generic provider name, or a name that does not look like a mail host, many receivers will treat the sender with suspicion.

Forward-confirmed reverse DNS

Forward-confirmed reverse DNS, often abbreviated FCrDNS, means the PTR name resolves back to the same IP address. This closes a gap: anyone who controls an IP block can set a PTR record to any name, including a name that belongs to someone else. Confirming the name forward ensures the owner of the name agrees with the IP.

dig -x 203.0.113.25 +short
mail.example.net.
dig mail.example.net A +short
203.0.113.25

If both answers match, the IP passes forward confirmation. Also check that the hostname your server announces in its SMTP greeting matches the PTR name, because mismatches are a common reason for rejection. Repeat the check for IPv6 if your server uses it, with the matching AAAA record.

What IP reputation is

Reputation is a score or a judgment that a receiver assigns to a sending IP address, a sending domain, or both. It is built from observable behavior over time:

How often mail from the address is marked as spam by recipients.
Whether the address appears on DNS-based blocklists, which are published lists of addresses known for spam, compromised hosts or open relays.
How many messages bounce, and why. Many invalid recipient attempts suggest address harvesting.
Whether authentication passes. Consistent SPF and DKIM results for a domain build trust in the domain, independent of the IP.
The volume and pattern of sending. A sudden surge from a new address looks like abuse.

Reputation can attach to the IP, so a shared hosting address can inherit problems caused by other tenants. It can also attach to the domain, which makes authentication and consistent sending more valuable as the IP changes.

Shared and dedicated addresses

A shared IP is used by many senders. Its reputation is the combined behavior of all of them, so one bad tenant can affect the rest. A dedicated IP gives you control over reputation, but you then carry the full burden of managing it. A new dedicated address starts with no history, so it is usually introduced gradually, with volume increasing over days or weeks while you watch the results. This is often called warming.

Practical steps

Set a PTR record that names a host in a domain you control, and make sure that host has an A or AAAA record pointing back.
Use the same hostname in the SMTP greeting and in the PTR.
Check blocklists for your address after changes, and follow the delisting process of each list if you appear.
Publish SPF, DKIM and DMARC so that the domain carries its own reputation. See SPF, DKIM and DMARC explained.
Watch bounce and complaint rates, and act on spikes quickly.
Increase volume gradually when you add a new address or a new stream of mail.

What a receiver may do

A receiver can accept mail, file it as spam, defer it, or reject it at the connection stage. The response depends on the receiver's policy and the strength of the signals. Missing forward confirmation alone may not reject mail, but in combination with a poor history and failed authentication it can be decisive. The more signals you control, the less likely a single weak one will cause trouble.

If your mail is being deferred or rejected, check the response text in the logs, then the PTR, then the blocklists, then the authentication results. The delivery troubleshooting guide walks through these checks, and the sending limits page lists the per-account outbound limits on ITProMail.