Introduction

Reverse DNS (PTR records) maps an IP address back to a hostname. Forward-confirmed reverse DNS (FCrDNS) requires that a forward lookup of the PTR hostname returns the original IP address. When this loop does not close - the PTR points to mail.example.com but mail.example.com resolves to a different IP - many email servers reject incoming mail, and some services refuse authentication. This is one of the most common causes of email being marked as spam.

Symptoms

  • Email sent from your server is rejected or marked as spam
  • Receiving server logs show PTR record mismatch or reverse DNS failed
  • dig -x <server-ip> returns a hostname that does not match the server's HELO hostname
  • SPF check passes but email still rejected due to PTR mismatch
  • Online tools like mxtoolbox show Reverse DNS does not match

Common Causes

  • PTR record not configured by the ISP/hosting provider (PTR is set by the IP owner, not the domain owner)
  • PTR points to a generic hostname (e.g., host-123.isp.com) instead of your mail server
  • Server hostname changed but PTR record was not updated
  • Forward A record changed but PTR still points to the old hostname
  • Multiple domains sharing an IP with only one having a matching PTR

Step-by-Step Fix

  1. 1.Check the current PTR record:
  2. 2.```bash
  3. 3.dig -x 192.168.1.50 +short
  4. 4.# Output: mail.example.com.

# Verify the forward lookup matches dig mail.example.com A +short # Output: 192.168.1.50 # These must match for FCrDNS to pass ```

  1. 1.Identify who controls the PTR record:
  2. 2.```bash
  3. 3.whois 192.168.1.50 | grep -i "org-name|netname|descr"
  4. 4.# The organization that owns the IP block controls the PTR
  5. 5.# For cloud providers, this is set in their management console
  6. 6.`
  7. 7.Update the PTR record:
  8. 8.```bash
  9. 9.# AWS EC2: Not directly supported - use SES or a verified identity
  10. 10.# Google Cloud: gcloud compute addresses describe
  11. 11.# Azure: Set via Azure portal or CLI
  12. 12.# DigitalOcean: Networking > PTR Records in the control panel
  13. 13.# Traditional hosting: Contact your ISP/hosting provider support
  14. 14.`
  15. 15.For AWS EC2, submit a PTR request:
  16. 16.```bash
  17. 17.# AWS requires an open support case for PTR changes
  18. 18.# Go to AWS Support Center > Create Case > Account and billing
  19. 19.# Request: "Please set PTR record for Elastic IP X.X.X.X to mail.example.com"
  20. 20.`
  21. 21.Verify the fix after PTR update:
  22. 22.```bash
  23. 23.# Check reverse DNS
  24. 24.PTR=$(dig -x 192.168.1.50 +short)
  25. 25.echo "PTR: $PTR"

# Check forward DNS A=$(dig ${PTR%.} A +short) echo "A record: $A"

# Verify they match if [ "$A" = "192.168.1.50" ]; then echo "FCrDNS: PASS" else echo "FCrDNS: FAIL" fi ```

  1. 1.Test email delivery after fixing PTR:
  2. 2.```bash
  3. 3.# Use mail-tester.com or similar service
  4. 4.# Send a test email and check the PTR/FCrDNS score
  5. 5.# Use mxtoolbox.com to verify reverse DNS
  6. 6.`

Prevention

  • Configure PTR records at the same time as setting up mail servers
  • Ensure the server's HELO/EHLO hostname matches the PTR record
  • Use dedicated IPs for mail servers to avoid PTR conflicts with other services
  • Document PTR record ownership and update procedures in mail server runbooks
  • Monitor PTR record status as part of email deliverability monitoring