Set reverse DNS (PTR records)

Normal DNS turns a name into an address. Reverse DNS does the opposite and answers the question “which hostname belongs to 203.0.113.10?” Mail servers ask it on every incoming connection, and it makes logs and traceroutes readable. Reverse DNS is free for every address on your server.

What a PTR record is

Reverse lookups use dedicated zones. For IPv4, the address is written backwards under in-addr.arpa; for IPv6, each hexadecimal digit is written backwards under ip6.arpa. The record type is PTR:

10.113.0.203.in-addr.arpa.   PTR   mail.example.com.

These zones belong to whoever holds the IP range, which for your server’s addresses is DediJet. That is why you set the PTR in your DediJet dashboard and not at your domain’s DNS provider. The forward records, A and AAAA, stay at your DNS provider.

Why mail servers need forward-confirmed reverse DNS

A receiving mail server checks two things about the IP address that connects to it:

1. The address has a PTR record, for example mail.example.com.
2. That hostname resolves back to the same address through its A or AAAA record.

When both match, the address has forward-confirmed reverse DNS (FCrDNS). Large mailbox providers require it from senders and reject or junk mail without it, and many self-hosted mail servers enforce it too; Postfix does with reject_unknown_client_hostname. Use the same name that your mail server announces in its HELO/EHLO greeting, set by myhostname in Postfix.

Set the PTR record

1. Create the forward record first. At your DNS provider, point mail.example.com to 203.0.113.10 with an A record, plus an AAAA record for the IPv6 address you will send from. Check that it resolves with dig +short mail.example.com A.

2. Set the reverse record. In your dashboard, open the server, then choose Reverse DNS. Select the address and enter the hostname, mail.example.com.

3. Verify it as shown below.

To manage many addresses, or to set PTR records from your provisioning scripts, use the DediJet API: it offers the same reverse DNS settings as the dashboard.

Verify the record

Install the lookup tools if they are missing: apt install -y bind9-dnsutils on Ubuntu and Debian, dnf install -y bind-utils on AlmaLinux and Rocky Linux. Then:

dig -x 203.0.113.10 +short
host 203.0.113.10
dig +short mail.example.com A

The first two commands should return mail.example.com (dig prints it with a final dot), the third 203.0.113.10. When both directions agree, the record is forward-confirmed.

Propagation and caching

Once a change is published, resolvers that already looked up the old value keep returning it until its TTL (time to live) expires. The TTL is the number in the second column of a full answer:

dig -x 203.0.113.10 +noall +answer

10.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.

In this example the TTL is 3600 seconds, so a resolver that cached the old answer may serve it for up to an hour. To see the current value without any cache in the way, follow the delegation from the root servers with dig +trace -x 203.0.113.10.

Reverse DNS for IPv6

Each IPv6 address has its own PTR record, and nobody fills a whole /64. Set records for the addresses you actually use, at least the one your mail server sends from. dig -x builds the long ip6.arpa name for you:

dig -x 2001:db8:1234:5678::25 +short

IPv6 matters for mail even if you never planned for it: when both sides support IPv6, your mail server may deliver over it, and the receiving server then checks the IPv6 address. Either give that address a PTR and a matching AAAA record, pinned in Postfix with smtp_bind_address6, or make the mail server use IPv4 only with inet_protocols = ipv4. See Configure your /64 IPv6 subnet for adding a dedicated address.

Common mistakes

• No matching forward record. The PTR points to a name without an A or AAAA record, or to one that resolves to another address, and FCrDNS fails.
• Using the bare domain. example.com usually points to your website, often hosted elsewhere. Use a dedicated host name such as mail.example.com.
• A greeting that does not match. The mail server introduces itself as localhost or under another name than the PTR.
• Mail leaving from another address. The PTR is set on the main IP, but mail goes out from an IPv6 address or an additional IPv4 address. Check the source address in your mail logs.
• Expecting more from reverse DNS. It does not affect websites or search rankings, and it does not replace SPF, DKIM or DMARC.

SPF, DKIM and DMARC in brief

Reverse DNS identifies the server. Three more DNS records, set at your DNS provider, authenticate the mail of your domain:

• SPF lists the addresses allowed to send for the domain, as a TXT record on example.com: v=spf1 ip4:203.0.113.10 ip6:2001:db8:1234:5678::25 -all.
• DKIM signs each message. Your mail software (OpenDKIM, Rspamd and others) generates the key pair; the public key goes in a TXT record at selector._domainkey.example.com.
• DMARC tells receivers what to do when SPF and DKIM checks fail, and where to send reports. Start with a TXT record at _dmarc.example.com containing v=DMARC1; p=none; rua=mailto:dmarc@example.com, then move to quarantine or reject once the reports look clean.

Running a mail server also means keeping it closed to strangers: open relays are not allowed under the acceptable use policy.

Still stuck?

If the dashboard does not accept your hostname, or the new record still does not show after the TTL has passed, open a ticket from Support with the address, the hostname and the output of dig -x.