Check a PTR record: reverse DNS for your mail server

What is a PTR record?

DNS connects names with technical addresses. A normal DNS lookup starts with a hostname and returns its IP address: an A record provides an IPv4 address, while an AAAA record provides an IPv6 address.

Reverse DNS works in the other direction. You look up an IP address and use its PTR record to retrieve a hostname. PTR stands for “pointer”. For a mail server, that name might be mail.werkstatt.example.

To confirm that both directions match, look up the returned hostname again. It should resolve to the IP address you started with. This check is called forward-confirmed reverse DNS.

The reverse zone normally belongs to the provider responsible for the IP address range. Adding a field called PTR in your domain’s DNS control panel is not enough if that provider does not control the reverse zone. Cloudflare explains how reverse DNS zones are managed.

Why does reverse DNS matter for business email?

A receiving mail server sees the IP address of the server connecting to it. A plausible, verifiable hostname helps identify that sender. Google requires valid forward and reverse DNS records for sending IP addresses. See Gmail’s email sender guidelines.

A correct PTR record does not guarantee inbox delivery. IP reputation, domain authentication and actual sending behaviour also matter. Fixing reverse DNS alone does not automatically resolve every rejection.

For a small business, the practical question is: Which server makes the final SMTP connection to the recipient? SMTP is the protocol used to transfer email between servers. The public IP address used for that final connection is the one we need to check.

Direct delivery or SMTP relay: which IP should you check?

With direct delivery, your mail server connects to the recipients’ servers itself. If it sits behind a router, its private address, such as 192.168.1.20, is not the address that matters here. You need the public address used for outbound connections.

With an SMTP relay, your server hands outgoing mail to a delivery service. The recipient sees the relay’s sending IP address. The relay provider manages that server identity; you still need to configure your sending domain according to its instructions.

• Your own server with direct delivery: identify the outgoing public IP address in your server and network configuration. Check every address that is actually used.
• MailPlus with a relay: inspect the relay configuration and the service provider’s requirements. The PTR record of your own internet connection may not be relevant to the final delivery.
• Hosted business email: send the delivery error and complete mail headers to your provider. You normally do not manage its sending IP addresses.

Your website’s IP address is not a reliable substitute. Web hosting and email delivery may use entirely different providers.

Check PTR and forward DNS in three steps

The following commands only query DNS; they do not change any records. Run them in a terminal with dig installed. All addresses and outputs below are reserved examples, not measurements of a real server. Replace them with the addresses used by your actual sending route.

1. Look up the hostname

For the example address, run:

dig -x 203.0.113.25 +short

A matching example answer would be:

mail.werkstatt.example.

The final dot marks a fully qualified DNS name. If no answer appears, inspect the complete response without +short. An empty short answer alone does not explain whether the record is missing or a lookup failed.

2. Check the forward lookup

Now query the hostname returned by the reverse lookup:

dig mail.werkstatt.example A +short

The result should include the address you checked:

203.0.113.25

For IPv6, query the actual sending IPv6 address with dig -x, then check the returned hostname’s AAAA record. A working IPv4 route tells you nothing about the IPv6 route.

3. Compare with real delivery

Send a test message through the relevant route to an external mailbox you control. Inspect its complete headers and, if delivery fails, the delivery report. The important question is whether your DNS check covers the address actually seen by the receiving server.

Ask your mail provider or administrator to help interpret complex headers. Complete headers can contain addresses and internal technical details; review them before sharing them publicly.

How to request a PTR change

If the mapping is missing or incorrect, use the reverse DNS settings offered by your IP provider or contact its support team. This is typically your internet provider for a fixed business connection, or your server host for a VPS.

Please set the PTR record for our public sending IP address to our mail server’s hostname. The hostname’s A or AAAA record should resolve to the same address. Please confirm which IPv4 and IPv6 addresses this change covers.

Replace the generic wording with your actual addresses and hostname before sending it. Also check the hostname your server announces over SMTP. That server setting is separate from the DNS record.

Allow for cached DNS answers after a change. TTL describes how long an answer is intended to remain cached, so some resolvers may still return the old value. Verify again instead of making several speculative changes.

Common problems and what to check next

Observation	Next check
The reverse lookup returns no hostname.	Inspect the full DNS response and contact the provider responsible for the IP range.
PTR returns a name whose A record points elsewhere.	Correct forward and reverse DNS together.
IPv4 works, but some deliveries still fail.	Check whether the server also sends over IPv6 and whether that route is configured correctly.
DNS looks correct, but the recipient rejects mail.	Inspect the precise SMTP error, domain authentication and IP reputation.
Your connection cannot provide a suitable PTR record.	Reassess direct delivery; consider an SMTP relay or hosted email.

With CGNAT, multiple connections share one public IPv4 address. Adding a DNS record cannot turn that into an independently controlled public address for your own mail server. Check the connection’s limitations before building the system.

Does every email domain need its own PTR record?

Not necessarily. One mail server can send for several domains using the same IP address. PTR describes that server address; it does not have to reproduce the domain after the visible @ in every message.

SPF, DKIM and DMARC address other aspects of sending-domain authentication. An MX record has another job again: it identifies the servers that receive incoming mail for a domain. A valid MX record does not replace a PTR record.

What you can do next

Write down your actual sending route, its outgoing public IP address and the provider responsible for it. Check PTR and forward DNS. If something does not match, you now have a specific support request rather than a vague “our email does not arrive”.

Find short explanations of related terms in the glossary. The next topic is domain authentication; our SPF, DKIM and DMARC guide explains the next steps.