PTR records are DNS records used for reverse DNS lookups. Instead of pointing a domain name to an IP address like an A record does, a PTR record points an IP address back to a hostname. This is commonly used for mail servers, logging, network verification and reputation checks.

For Apexhost customers, PTR records are most relevant when using services that send email directly from a server or when a third-party platform requires a valid reverse DNS record for an IP address. Understanding how PTR records work can help you avoid email deliverability issues and better understand how public-facing services are identified on the internet.

DNS, or Domain Name System, usually helps users find the IP address for a domain name. A PTR record works in the opposite direction. It allows systems to start with an IP address and check which hostname is associated with it.

In simple terms, a PTR record tells the internet which hostname should be returned when an IP address is looked up in reverse.

For example, if a server uses the public IP address 203.0.113.25, a PTR record may point that IP address to mail.example.com. When another server performs a reverse DNS lookup on that IP address, it can see that hostname as the expected reverse DNS result.

PTR records are stored in special reverse DNS zones rather than in the normal forward DNS zone for your domain. This is why PTR records are usually managed by the provider that controls the public IP address block, not simply by whoever manages the domain’s standard DNS records.

PTR records are especially important for services that send email from a server IP address. Many receiving mail systems check reverse DNS as part of their trust and filtering process. If a sending IP address has no PTR record, or the PTR record points to an unexpected hostname, messages may be treated as suspicious, filtered to spam or rejected.

PTR records may also be used for:

• mail server identity and reputation

• reverse lookup checks during troubleshooting

• server identification in logs and monitoring tools

• some application, security or compliance requirements

A PTR record does not control where a website loads from and does not replace A, AAAA, MX or CNAME records. It serves a different purpose.

A normal DNS lookup is often called forward DNS. For example, a query for www.example.com may return an A record with an IPv4 address. Reverse DNS does the opposite by taking an IP address and querying the reverse DNS namespace to find the matching hostname.

For IPv4, the reverse DNS zone is built under in-addr.arpa. For IPv6, the reverse DNS zone is built under ip6.arpa.

Although the technical structure is different behind the scenes, most customers only need to know the practical result: a PTR record links a public IP address to a hostname for reverse lookups.

In many setups, the hostname returned by the PTR record should also have a matching forward DNS record. For example, if the PTR record for an IP address returns mail.example.com, that hostname should usually also resolve back to the same IP address using an A record or AAAA record. This is often referred to as forward-confirmed reverse DNS, and it is commonly expected for mail services.

You may need a PTR record when:

• running a mail server that sends outbound email from a dedicated public IP address

• using a VPS, dedicated server or other service with a static public IP that requires reverse DNS

• meeting a third-party service requirement for IP identity validation

• troubleshooting email deliverability or server reputation issues

• verifying that a public IP address identifies itself with the correct hostname

If you only manage website DNS for a domain and do not control the public IP address, you may not be able to create or change the PTR record yourself.

Before requesting a PTR record, make sure you have the correct information available.

• the public IP address that needs reverse DNS

• the exact hostname the PTR record should return

• confirmation that the hostname already has the correct forward DNS record

• confirmation of which provider controls the IP address allocation

• confirmation that the IP is static and assigned to your service

A PTR record should point to a fully qualified hostname that you control or have permission to use. Entering the wrong hostname can cause email or service validation problems.

Unlike many other DNS records, PTR records are not usually edited in the standard DNS zone editor for your domain. They are generally managed by the organisation that controls the IP address range.

This means:

• if Apexhost controls the public IP address, Apexhost may be able to assist with the PTR record

• if your server or service uses a third-party IP address, that provider usually manages the PTR record

• updating DNS for your domain alone will not normally create or update reverse DNS for the IP address

If you are unsure who controls the relevant IP address, check your server or service documentation or contact the provider that assigned the IP.

The exact process varies depending on the provider that controls the public IP address, but it usually follows a similar pattern.

1. Confirm the public IP address that requires the PTR record.

2. Decide which fully qualified hostname the IP address should resolve to.

3. Check that the hostname already has the correct forward DNS record pointing back to the same IP address where required.

4. Identify the provider that manages the IP address block.

5. Submit the PTR record request through that provider’s control panel or support channel.

6. Wait for the reverse DNS change to be applied and propagated.

7. Test the result using a reverse DNS lookup tool or command-line lookup.

[Screenshot: Control panel or provider area used to request reverse DNS or PTR records]

Because many providers restrict PTR changes for security and network integrity reasons, self-service editing may not always be available.

• trying to create a PTR record in the regular DNS zone for the domain instead of through the IP provider

• using a hostname that does not exist in forward DNS

• pointing the PTR record to a generic or incorrect hostname

• assuming a website DNS change also updates reverse DNS

• expecting reverse DNS changes to apply instantly everywhere

• using a PTR record for a dynamic or shared IP where custom reverse DNS is not supported

Likely cause: No PTR record has been configured for the public IP address, or the wrong provider was asked to make the change.

Resolution: Confirm who controls the IP address block and request the PTR record from that provider. Also confirm that the IP address entered is correct.

Likely cause: The sending IP address may not have valid reverse DNS, or the PTR hostname may not match the forward DNS setup.

Resolution: Check the PTR record, then confirm the hostname resolves back to the same IP address with an A record or AAAA record where appropriate. Also review other email-related DNS records such as SPF, DKIM and DMARC if they apply.

Likely cause: DNS caching and propagation delays can affect reverse DNS lookups, just as they can with other DNS changes.

Resolution: Allow more time, test from another network or resolver, and recheck the applied record later.

No. An A record points a hostname to an IPv4 address. A PTR record points an IP address back to a hostname for reverse lookups.

Usually no. PTR records are normally controlled by the provider that manages the public IP address block.

No. PTR records are most important for services such as outbound mail servers and some server validation scenarios. Many standard websites do not require a custom PTR record.

No. Website routing is normally controlled by records such as A, AAAA and CNAME. A PTR record is used for reverse DNS only.

In many cases, yes. Especially for mail servers, the PTR hostname should usually resolve back to the same IP address to help with trust and validation.

What is DNS? (DNS)

A Records (DNS Records)

AAAA Records (DNS Records)

MX Records (DNS Records)

TXT Records (DNS Records)

Need More Help?

If you require further assistance, please contact Apexhost Support at support@apexhost.com.au.