Reverse DNS (an rDNS or PTR record) maps an IP address back to a hostname, the opposite of normal “forward” DNS. You need it most often so that outbound email is accepted: mail providers reject or spam-folder mail from an IP whose PTR is missing or does not match the sending hostname.
You set reverse DNS yourself, for every IPv4 address on every bare-metal server and cloud instance on your account. No ticket, no waiting. The change is written to our authoritative nameservers the moment you save it.
Before you start: forward-confirm first
Set the PTR to a hostname that already resolves forward to the same IP (an A record pointing back at it). This is forward-confirmed reverse DNS (FCrDNS), and it is what mail providers actually check.
Example: to give 203.0.113.10 the PTR mail.example.com:
- First, in your own domain's DNS, create the A record
mail.example.com → 203.0.113.10. - Then set the PTR here:
203.0.113.10 → mail.example.com.
A PTR that points at a hostname which does not resolve back to the IP counts as misconfigured, and your mail may still be rejected.
Method 1: In the portal
- Log in at amoni.app.
- In the left-hand menu, open IP Addresses. Every address on your account is listed, grouped by the server or cloud instance that holds it. Groups are collapsed; click a server name to expand it, or use Expand all at the top right.
- Find the address. The search box filters live on IP, hostname or current rDNS, and the IPv4 / IPv6 pills narrow the list.
- Hover the rDNS / PTR cell on that row and click the pencil icon that appears.
- Type the hostname (for example
mail.example.com) and press Enter, or click the green tick. Esc cancels. - A green rDNS updated confirmation appears and the row shows the new value.


To clear a PTR, open the editor, delete the value and save. New addresses may start with a default PTR (such as ip4-203-0-113-10.rdns.netrouting.net); replace it whenever you like.
Every change is recorded on the Activity page as “Set reverse DNS for 203.0.113.10 to mail.example.com”, with who did it and when.
Method 2: With the API
The same two calls power the portal page. You need an API key with the IPs scope (ips.write): create one under Account → API Keys, tick IPs, and copy the key when it appears. It is shown once. Full reference: api.amoni.app/v1/docs.
1. Find the address id
curl -s https://api.amoni.app/v1/ips \
-H "Authorization: Bearer nr_live_..."
Addresses come grouped by the resource holding them. Note the numeric id of the one you want:
{
"success": true,
"data": {
"servers": [
{
"id": "srv-1042",
"type": "server",
"name": "web1.example.com",
"location": "Amsterdam",
"ips": [
{
"id": 4821,
"address": "203.0.113.10",
"ip_version": 4,
"dns_name": "ip4-203-0-113-10.rdns.netrouting.net",
"is_primary": true,
"prefix_length": 29
}
]
}
],
"total_ips": 1,
"total_servers": 1
}
}
To pick it out in a script with jq:
curl -s https://api.amoni.app/v1/ips -H "Authorization: Bearer nr_live_..." \
| jq '.data.servers[].ips[] | select(.address == "203.0.113.10") | .id'
2. Set the PTR
curl -s -X PUT https://api.amoni.app/v1/ips/4821/rdns \
-H "Authorization: Bearer nr_live_..." \
-H "Content-Type: application/json" \
-d '{"dns_name": "mail.example.com"}'
{ "success": true, "data": { "message": "Reverse DNS updated." } }
The write lands on our authoritative nameservers before the response returns. To clear the PTR, send an empty string: {"dns_name": ""}.
What the API will tell you
| Status | code |
Meaning |
|---|---|---|
| 200 | none | PTR set or cleared. |
| 401 | invalid_api_key |
The key is wrong, expired or revoked. |
| 403 | insufficient_scope |
The key lacks ips.write; required_scope names it. |
| 404 | none | No address with that id is assigned to your account. Body: {"success": false, "error": "Not found"}. |
| 422 | none | dns_name is not a valid hostname (letters, digits, dots and hyphens; 253 characters max): {"message": "The dns name field format is invalid.", "errors": {"dns_name": ["…"]}}. |
| 429 | none | Rate limit: 120 requests a minute per key. Honour Retry-After. |
Branch on the HTTP status and on code. The error text is written for people and may be reworded.
About 422s: a rule the endpoint checks itself (a weak password, a duplicate key, a layout you may not use) answers in the usual envelope. A field that fails basic validation currently answers in the framework's own shape, {"message": "…", "errors": {"field": ["…"]}}, without success or code. Branch on the HTTP status for those; the envelope is being extended to cover them.
Bulk example: set PTRs for a whole server from a file
Given a file ptrs.txt with one address hostname pair per line:
#!/usr/bin/env bash
KEY="nr_live_..."
IPS=$(curl -s https://api.amoni.app/v1/ips -H "Authorization: Bearer $KEY")
while read -r addr name; do
id=$(jq -r --arg a "$addr" '.data.servers[].ips[] | select(.address == $a) | .id' <<< "$IPS")
[ -z "$id" ] && { echo "skip $addr: not on this account"; continue; }
curl -s -X PUT "https://api.amoni.app/v1/ips/$id/rdns" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d "{\"dns_name\": \"$name\"}" | jq -r --arg a "$addr" '"\($a): \(.data.message // .error)"'
done < ptrs.txt
Verify it
Our nameservers answer with the new value immediately. A resolver somewhere else may keep the previous answer until its cached TTL expires, so a mail provider checking your PTR can see the old value for a few minutes. Check from any terminal:
dig -x 203.0.113.10 +short
# or
host 203.0.113.10
You should see the hostname you set. Then confirm the forward side matches:
dig +short mail.example.com
Troubleshooting
- No pencil icon on the row. The address is IPv6. IPv6 PTRs are shown but not yet self-service. Open a ticket with the address and hostname and we set it, or ask for a reverse delegation if you run your own nameservers.
- “Failed to update reverse DNS. Please try again later.” Our nameserver did not accept the write. Nothing was changed on your side; retry in a minute, and open a ticket if it persists.
- Mail is still rejected after setting the PTR. Check the forward record:
dig +short mail.example.commust return the same IP. Then check that your mail server's HELO/EHLO name is the same hostname. - The API answers 404 for an id you can see in the portal. The key belongs to a different account than the one holding the address. Keys act only for the account that created them.
- You lease a whole subnet (a /24 or larger) and want to manage PTRs on your own nameservers: open a ticket with the subnet and the nameserver names and we delegate the reverse zone to you.
Still stuck?
Open a support ticket from the portal with the IP address and the hostname you want, and pick the server in the “related server” field so it lands with the right context.