PTR records and reverse DNS: who sets the reverse entry?

1. Start with the connection that produced the warning

You use your own .at address for an Austrian business and see a sending error mentioning “reverse DNS” or “PTR”. Before opening your DNS settings, save the exact message and the time with its time zone. Ask the mail service which public sending IP was actually used. Your website’s IP or your laptop’s address is not automatically the relevant one. The domain after @ is also insufficient to identify the affected server. If you use a managed mailbox, its support team is your first contact for the outgoing server. This warning does not require another domain order.

2. Separate the two lookup directions

A forward lookup starts with a hostname and requests an address: A for IPv4 or AAAA for IPv6. A reverse lookup instead starts with an IP address and requests a name through PTR. RFC 1035 describes in-addr.arpa for IPv4, while RFC 3596 defines ip6.arpa for IPv6. These are distinct parts of DNS. A name in your ordinary .at zone and an IP address’s reverse zone therefore involve separate administration. Use the comparison below to place a service’s actual instructions in the right category before requesting a change.

3. Ask who administers the IP’s reverse DNS

Begin with the server or mail service supplying the affected public IP. Ask specifically about reverse-DNS administration or an existing delegation. RFC 2317 describes delegating responsibility for smaller IPv4 address blocks; buying a domain name does not arrange that delegation. With managed mail, the service may handle the entire configuration. Do not independently request that a shared sending IP be changed to your individual domain. First have the service confirm the intended setup and whether you need to request anything at all. Record which team can approve and perform the relevant work.

4. Coordinate the forward and reverse records

If you operate your own mail server, obtain confirmation of its intended full hostname and public IP address. RFC 1912 recommends consistent forward and reverse data: a PTR target should match a valid A record for the relevant IPv4 address rather than merely a CNAME alias. Have the responsible parties check both sides. For IPv6, coordinate the appropriate AAAA resolution and reverse zone separately. Do not use an example IP from a tutorial in your real setup. Record the confirmed name, IP version and responsible contact so that the domain administrator and server team do not receive contradictory requests.

5. A reverse hostname is not proof of domain ownership

A server can provide services for different domains. Its returned hostname is consequently not a complete inventory of websites running there. It also does not establish who holds your .at domain or whether a website’s SSL certificate matches the address being visited. If a checker shows an unfamiliar technical hostname, ask the service what it represents first. Do not replace working website addresses, MX records or nameservers simply because that name differs from your brand. For an actual mail rejection, establish which check the receiving service objected to. A general warning is not yet a complete diagnosis of the failure.

6. Send a short, specific support request

A useful request says, in substance: “This public sending IP was reported for this sending time. This is the sanitised diagnostic message. Do you manage its PTR record, and does it match the intended server configuration?” Include only information obtained from your own service or a confirmed diagnosis. Avoid passwords, complete private messages and unnecessary recipient details. If support then requests a change in your domain zone, ask for the exact hostname, record type and value, plus an explanation of how it addresses the reported error. Preserve the existing values before any approved correction. Keep the request and response together.

• Include the sending time and time zone.
• Identify the public sending IP and specific diagnostic text.
• Confirm the responsible team and proposed change.
• Agree an appropriate result check afterwards.

7. Recheck the original problem after a correction

Ask the responsible team to compare the reverse response with the corresponding forward lookup again. For a sending problem, then arrange one check using your own mailbox or a recipient explicitly designated for that purpose. Keep the new diagnosis with the original report. A configured PTR record does not guarantee inbox placement: other sending rules and the recipient’s handling remain separate questions. Do not change SPF, DKIM or DMARC speculatively as part of the same work. If your domain uses external nameservers, any necessary forward records belong at that DNS service; reverse-DNS responsibility still needs its own confirmation.

8. Budget for the domain and server service separately

A standard new .at domain at atdomain.at currently costs €12.99 total for the first year, with renewal at €15.99 total per additional year. DNS management with our default nameservers and custom nameservers are supported. We do not sell hosting or email mailboxes. Buying a domain therefore does not include an arbitrary server IP or its reverse-DNS administration. On request, we can help with domain and DNS settings within our actual access. For external servers or DNS zones, work with the responsible service. If you need a new name, check availability and the additional services you require before ordering.