Reverse DNS and PTR records
Forward DNS turns a name into an address. Reverse DNS turns an address back into a name, and a surprising amount of the internet refuses to deal with you without it.
Why it matters
Receiving mail servers check that the connecting address has a PTR record, and that the name it returns resolves back to that same address. A missing or generic PTR is one of the strongest spam signals there is, and some large providers reject on it outright before they look at anything else.
It also matters for logs you will read later, for SSH connections that hang while something waits on a lookup, and for being a recognisable neighbour rather than a bare number.
Setting it
Every address we assign you can carry a PTR record, and you set it yourself in the portal — or through the API if you are automating. There is no charge and no ticket needed.
Set it to a name that exists in forward DNS and points back at the same address.
mail.yourdomain.com is right. server1.local,
or a name that resolves nowhere, is worse than useless.
Check your work:
dig -x 192.0.2.50 +short — returns the name
dig mail.yourdomain.com +short — must return 192.0.2.50
Both directions have to agree. One without the other is a half-configured machine.
IPv6
Exactly the same principle, with a longer record name — the reverse zone for v6 is nibble by nibble, which is why it looks alarming. The portal handles the formatting; you give it the address and the name. If your machine sends mail over IPv6, it needs a v6 PTR as well. Receiving servers check whichever protocol you connected over, and a perfect v4 setup does not help a v6 connection.
Delegation for larger blocks
If you hold a routed block and would rather run the reverse zone on your own nameservers, we can delegate it. Send support the nameservers and the block; we set the delegation and the records become yours to manage. This is the usual arrangement for resellers who want their customers' reverse DNS to read as their own.
For your own address space, the reverse zone is already yours at the registry and nothing is needed from us.
Propagation
Changes take effect quickly on our side, but other people's resolvers cache. Allow for the TTL before concluding that something has not worked, and test against an authoritative server rather than your laptop's resolver:
dig -x 192.0.2.50 @ns1.novogara.com
Before you send mail
PTR is one of four things that need to be right. The other three — SPF, DKIM and DMARC — are covered in sending mail from your server, which also explains why you should tell us before you start.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base