Set reverse DNS on your addresses

Where the record lives

Every address routed to your instance has an editable PTR. The panel lists them under the instance, one row per address. The API exposes the same thing:

curl -s https://paragonvps.com/api/v1/instances/<instance-id>/addresses -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[].ptr'

Setting one:

curl -s -X PUT https://paragonvps.com/api/v1/addresses/<address-id>/ptr -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"ptr":"mail.example.com"}'

The forward record has to exist first

A PTR pointing at a name with no matching A or AAAA is worse than no PTR at all. Receiving mail servers read the mismatch as a signal, and a few refuse the connection on the strength of it. Publish the forward record, confirm it resolves, then set the PTR.

dig +short mail.example.com A
dig +short mail.example.com AAAA

Then check the pair agrees in both directions:

dig +short -x <ipv4>
dig +short -x <ipv6>

dig -x assembles the in-addr.arpa or ip6.arpa name for you, which saves reversing thirty-two nibbles by hand and getting one of them wrong.

Propagation

Our authoritative zones pick up a change within about a minute. What takes longer is the negative cache: any resolver that asked for the PTR before you set it may hold the empty answer for as long as the SOA minimum, which on the reverse zones is an hour. Neither of us can shorten that, and retrying the query only proves it.

IPv6

The routed /64 contains more addresses than you will ever name, and the panel is not going to offer you a text field for each. Two workable approaches:

• Set a PTR on the individual addresses you actually use. Most people need exactly one, for the mail sender.
• Ask for the ip6.arpa zone covering your /64 to be delegated to your own nameservers, after which you generate whatever you like. Delegation is a ticket, takes about a day, and needs two nameservers already answering for the zone.

Mail specifics

Outbound port 25 is closed on new accounts. Ask, say what the instance sends and roughly how much, and we open it. The check exists because open relays are one of the three things the acceptable use policy prohibits outright.

Once it is open, four strings should agree: the sending hostname, the PTR, the HELO name and whatever your SPF record authorises. Making the HELO identical to the PTR removes the most common cause of a soft rejection.

swaks --to [email protected] --server localhost --helo mail.example.com

When it does not take

Three causes, in the order they occur:

1. The forward record is missing, wrong, or has not propagated yet.
2. The address you edited belongs to a different instance than the one sending traffic.
3. Your daemon binds a different address in the /64 than the one you set the PTR on.

The third is easy to miss and easy to check:

ip -brief addr
ss -tlnp

If the source address in an outbound connection is not the one carrying your PTR, bind the daemon explicitly rather than hoping the kernel picks the address you had in mind.