Your mail server keeps getting flagged as spam, or a security audit just failed because your IP address has no reverse DNS. Both problems trace back to a missing or misconfigured PTR record. Unlike the forward DNS records you set up in a control panel, PTR records live in a part of the DNS tree that most server owners never touch — and getting them wrong silently breaks email delivery, SSH logging, and a surprising number of compliance checks. This guide covers exactly what PTR records are, why they exist, who controls them, and the precise steps to create or fix one today.
What a PTR Record Actually Is
A PTR record (Pointer record) maps an IP address back to a hostname. It is the reverse of an A record. Where an A record says mail.example.com points to 203.0.113.50, a PTR record says 203.0.113.50 resolves to mail.example.com. This reverse mapping is called reverse DNS, or rDNS.
PTR records live in a special DNS zone called the in-addr.arpa domain for IPv4, and ip6.arpa for IPv6. The IP address is written backwards in these zones. So the PTR record for 203.0.113.50 lives at the DNS name 50.113.0.203.in-addr.arpa. For the IPv6 address 2001:db8::1, it lives at 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa — each hex digit reversed and dot-separated.
Forward vs Reverse DNS Zones
Your domain registrar or DNS host manages forward zones. Your IP address owner — almost always your VPS provider, datacenter, or ISP — manages reverse zones. This is a critical distinction that trips up a lot of people. You cannot add a PTR record in Cloudflare, Namecheap, or Route 53 unless they also own your IP block. If you try to add a PTR record in your normal DNS dashboard and it silently disappears or has no effect, this is why.
Why Reverse DNS Matters
Email Delivery
This is the big one. Receiving mail servers perform a PTR lookup on the connecting IP before accepting or scoring a message. If there is no PTR record, many servers will reject the connection outright with a 550 error. If the PTR record exists but does not match the hostname in the SMTP EHLO/HELO greeting, the message gets a significant spam score penalty. Major providers including Gmail, Microsoft 365, and Yahoo use PTR checks as a baseline spam filter.
The forward-confirmed reverse DNS (FCrDNS) check goes even further: the receiving server looks up the PTR for your IP, then does an A record lookup on the resulting hostname to confirm it points back to the same IP. Both lookups must match. So if your PTR says mail.example.com, then mail.example.com must have an A record pointing back to your IP.
Security Logging and Auditing
SSH logs, Apache access logs, and firewall logs all perform reverse lookups to display hostnames instead of raw IP addresses. Without PTR records, every entry shows a bare IP. Security information and event management (SIEM) tools rely heavily on rDNS for correlating events and generating readable reports. Many compliance frameworks (SOC 2, PCI-DSS) flag hosts with no rDNS as a finding.
Reputation and Spam Filtering
Spam reputation services like Spamhaus, Barracuda, and Postmaster Tools at Google factor in whether an IP has a valid PTR record. A missing or generic PTR (something like static-203-0-113-50.yourprovider.net) signals a potentially misconfigured or residential IP and raises the spam score of every message you send.
How to Set Up a PTR Record Step by Step
Step 1 — Identify Who Owns Your IP
Log into your VPS, dedicated server, or cloud instance and find your public IP address. Then check the WHOIS or ARIN/RIPE/APNIC data for that IP to confirm who controls the reverse zone. In practice, just go to your hosting provider's control panel — they will have a field for reverse DNS if they support it.
Common providers and where to set rDNS:
- DigitalOcean — Droplet settings page, under the Networking tab, there is a field labeled PTR record or Set rDNS. Enter the fully qualified hostname.
- Linode / Akamai Cloud — In the Linode Manager, go to your Linode, then Network, then IP Addresses. Click the three-dot menu next to the IP and choose Edit rDNS.
- Vultr — In the server detail page, Settings tab, click the pencil icon next to Reverse DNS under the IP address listing.
- AWS EC2 — EC2 does not allow self-service PTR changes for most instances. You must submit a request to AWS Support with the IP, desired hostname, and a brief justification. Elastic IPs can sometimes be configured via the VPC Console under Elastic IPs > Actions > Update Reverse DNS.
- Google Cloud / GCP — Open the Cloud Console, go to VPC Network > External IP Addresses, find the IP, and there is a DNS PTR record field directly in the row.
- Hetzner — In the Cloud Console, click your server, go to Networking, and click the pencil icon next to the IPv4 or IPv6 address.
- Dedicated servers / colo — Log a ticket with your datacenter or ISP. Provide the IP and the exact hostname you want. Most tier-1 and tier-2 ISPs have a web form or SWIP process for this.
Step 2 — Prepare the Forward Record First
Before setting the PTR, make sure the A record for the hostname already exists and is propagated. Providers often validate that the hostname you submit actually resolves back to the IP. If you request a PTR of mail.example.com for IP 203.0.113.50, your forward zone must have:
Set this in your DNS host's control panel and wait a few minutes before proceeding. You can check it quickly with the DNS Lookup tool to confirm it resolves correctly before you touch the rDNS settings.
Step 3 — Enter the PTR Record at Your Provider
Log into your hosting control panel, find the rDNS or reverse DNS setting for your IP, and enter the fully qualified domain name including the trailing dot (some providers omit the dot, which is fine — just enter the hostname). Use the format:
Do not enter the raw IP or the in-addr.arpa notation yourself — the provider's interface handles that translation automatically. Save the record. Changes typically propagate within 1-4 hours, though some providers apply them within minutes.
Step 4 — Handle IPv6 Reverse DNS
If your server sends mail over IPv6, you need a PTR for the IPv6 address too. The process is the same — go to your provider's interface and find the IPv6 address entry. The hostname can be the same as the IPv4 PTR. Also ensure your forward zone includes:
Many administrators set up IPv4 rDNS and forget IPv6 entirely, then wonder why mail to Outlook.com bounces — Microsoft enforces PTR checks on IPv6 sending addresses strictly.
How to Verify Your PTR Record
After setting the record and waiting for propagation, test it from the command line. On Linux or macOS:
On Windows, open PowerShell or Command Prompt:
The output should return your hostname — for example mail.example.com. Then run the forward lookup to confirm FCrDNS:
Both lookups must match for FCrDNS to pass. If the reverse lookup returns a different hostname, or the forward lookup of that hostname returns a different IP, receiving mail servers will flag you.
Troubleshooting Common PTR Record Problems
The PTR Record Shows Your Provider's Default Hostname
This is the most common situation — you get a VPS and the default PTR is something like 203-0-113-50.somecloud.net. You have not set a custom PTR yet. Follow steps 1-3 above. Until you do, every mail server that checks rDNS will see a generic provider hostname, which is a strong spam signal.
No PTR Record Returns at All
Running dig -x returns NXDOMAIN or SERVFAIL. This means the in-addr.arpa zone for your IP either has no PTR entry or the reverse zone itself is not delegated. Contact your provider's support and confirm they support custom PTR records — some cheap VPS providers do not offer this feature. If they do support it, check that you entered the record correctly in their panel.
The PTR Record Set but Does Not Propagate
Some providers cache the old PTR aggressively. Try querying a specific public resolver directly to bypass your local cache:
If the record shows on one resolver but not another, propagation is still in progress. If none return the correct value an hour after setting it, open a ticket with your provider — the zone update may not have been applied on their authoritative nameservers.
Mail Still Rejected After Fixing PTR
Check that your EHLO/HELO hostname in your mail server configuration matches the PTR exactly. For Postfix, this is the myhostname directive in /etc/postfix/main.cf:
Also verify that the hostname in your PTR is not a CNAME — it must be a literal A or AAAA record. Some receiving servers will reject a PTR that points to a CNAME target rather than directly to an A record.
PTR Records for Home and Small Business Networks
If you run a mail server from a residential or small business connection, your ISP controls the reverse zone. Most consumer ISPs will not set custom PTR records, and many actively block outbound port 25. You have two practical options: use a cloud-hosted VPS with a proper PTR, or relay your mail through your ISP's SMTP relay or a third-party smart host like SendGrid, Mailgun, or Postmark. These services handle PTR configuration on their own sending infrastructure.
For business fiber or dedicated circuits, contact your ISP's business support line and request a PTR record update. You will need to provide the IP address and the hostname. Most business ISPs can complete this within one business day.
Best Practices Going Forward
- Always set the PTR before you start sending mail from a new server — do not wait for bounce reports to tell you it is missing.
- Keep your PTR hostname, EHLO hostname, and the From domain aligned. They do not all need to match, but the PTR and EHLO absolutely should.
- Use a subdomain specifically for your mail server (mail.example.com) rather than setting PTR to your bare domain (example.com). The bare domain is often served by multiple IPs, which complicates FCrDNS.
- Document your PTR records alongside your other DNS records so they do not get forgotten during server migrations. A common failure point is spinning up a new server with a new IP and forgetting to set rDNS until email delivery problems appear days later.
- If you decommission a server and return the IP to your provider, notify them to remove the PTR entry. A dangling PTR pointing to a hostname you no longer control is a minor but real security concern.
Reverse DNS is one of those foundational configurations that the internet's email infrastructure quietly depends on. Getting a PTR record right takes about five minutes once you know where to look, but misunderstanding who controls the reverse zone causes hours of wasted troubleshooting. Identify the IP owner, set the forward A record first, configure the PTR through your provider's panel, and verify with a reverse dig. That sequence covers the vast majority of rDNS setups correctly on the first try.