Reverse DNS (PTR) Records

Reverse DNS maps an IP address back to a hostname, the mirror image of the usual name-to-address lookup. It is stored as a PTR record in the zone that belongs to whoever controls the address, which for your NoBull Networks IP is us. Setting it is quick, and if your server sends email it is not optional.

Why it matters#

• Mail deliverability. Receiving mail servers check that your sending IP has a PTR record and that the hostname it points to resolves back to the same IP ("forward-confirmed reverse DNS"). Missing or mismatched records are a fast route to the spam folder or an outright rejection.
• Readable logs. Other people's logs, traceroutes, and monitoring show your hostname instead of a bare address.
• Reputation. A generic or missing PTR is a mild signal of a poorly maintained host; a proper one is a mild signal of the opposite.

Step 1: create the forward record first#

Pick the hostname you want the address to resolve to, for example mail.example.com, and create an A record (and AAAA for IPv6) for it in your domain's DNS pointing at the server's IP. The PTR should point at a name that resolves back to the same address, so do this first and let it propagate.

Step 2: set the PTR record#

1. Open the server in the cloud portal. Sign in at cloud.nobullnetworks.com (see Getting Around the Cloud Portal) and open the Networking tab.
2. Click Add Reverse DNS entry. Choose the IP address (the main address or any additional address on the server), enter the hostname it should resolve to, and click Save. The record is published shortly afterwards.
3. No option, or a colocation prefix? Open a support ticket with the IP address (or addresses) and the exact hostname for each. If we announce your own ARIN or RIPE space, tell us whether you want us to host the reverse zone or delegate it to your nameservers.

Step 3: verify#

dig +short -x 203.0.113.10          # should print mail.example.com.
dig +short A mail.example.com       # should print 203.0.113.10
host 203.0.113.10                   # same check, different tool

Both directions should agree. DNS caches mean a change can take a little while to be visible everywhere; querying a public resolver such as dig @1.1.1.1 -x 203.0.113.10 shows the live answer.

Sending mail? Finish the set#

PTR is one of four records mail receivers expect. Add SPF (which servers may send for your domain), DKIM (a signature on each message), and DMARC (what receivers should do on failure) in your domain's DNS, and make sure the hostname your mail server announces in its HELO matches the PTR. Then read the outbound-mail section of Acceptable Use, Spam, and Abuse Reports: outbound SMTP may be filtered by default, and a relay service is often the pragmatic answer.