Reverse DNS (PTR Records): Why Missing rDNS Hurts Email Deliverability and Security

What is reverse DNS?

Forward DNS translates a hostname to an IP address: mail.yourcompany.com resolves to 203.0.113.25. Reverse DNS (rDNS) does the opposite: it translates an IP address back to a hostname using PTR (Pointer) records.

# Forward lookup
dig A mail.yourcompany.com +short
# 203.0.113.25

# Reverse lookup
dig -x 203.0.113.25 +short
# mail.yourcompany.com.

Reverse DNS is stored in a special zone under the in-addr.arpa domain. The IP address 203.0.113.25 becomes a PTR query for 25.113.0.203.in-addr.arpa.

Why reverse DNS matters

Email deliverability

This is the primary reason most organisations care about rDNS. Major email providers (Gmail, Microsoft 365, Yahoo) check the reverse DNS of connecting mail servers. If your mail server's IP address does not have a PTR record, or if the PTR record does not match the server's hostname, your email is far more likely to be:

• Rejected outright (5xx error)
• Delivered to the spam folder
• Scored as suspicious by spam filters

Many mail servers follow a process called Forward-Confirmed reverse DNS (FCrDNS):

1. Look up the PTR record for the connecting IP (e.g., 203.0.113.25 resolves to mail.yourcompany.com)
2. Look up the A record for that hostname (e.g., mail.yourcompany.com resolves to 203.0.113.25)
3. If the IP from step 2 matches the original IP, the check passes

If either step fails, the sending server looks untrustworthy.

Security auditing and logging

When reviewing firewall logs, intrusion detection alerts, or access logs, IP addresses alone are hard to work with. Reverse DNS gives context:

• 203.0.113.25 connected to your server -- who is that?
• mail.partner-company.com connected to your server -- now you know

Without PTR records on your own infrastructure, other organisations cannot identify your servers in their logs.

Compliance and professional reputation

Missing rDNS is a signal of poorly managed infrastructure. Security auditors, business partners, and email providers all interpret it as a red flag. It suggests the IP owner has not taken basic steps to configure their network properly.

How to check your reverse DNS

Using dig

# Check rDNS for a specific IP
dig -x 203.0.113.25 +short

# Check rDNS for your mail server
dig -x $(dig A mail.yourcompany.com +short) +short

Using host

host 203.0.113.25

Using nslookup

nslookup 203.0.113.25

Using MXToolbox

MXToolbox Reverse Lookup provides a web-based check with additional context about the IP.

Checking FCrDNS (forward-confirmed reverse DNS)

#!/bin/bash
IP="203.0.113.25"
PTR=$(dig -x "$IP" +short)
echo "PTR for $IP: $PTR"

if [ -n "$PTR" ]; then
  FORWARD=$(dig A "$PTR" +short)
  echo "A record for $PTR: $FORWARD"
  if [ "$FORWARD" = "$IP" ]; then
    echo "FCrDNS: PASS"
  else
    echo "FCrDNS: FAIL (mismatch)"
  fi
else
  echo "FCrDNS: FAIL (no PTR record)"
fi

Common reverse DNS issues

No PTR record at all

The IP address has no reverse DNS entry. This is the most common issue, especially on cloud-hosted servers where PTR records must be configured separately.

PTR record does not match the server's hostname

The PTR record exists but points to a generic hostname like ec2-203-0-113-25.compute.amazonaws.com instead of mail.yourcompany.com. While this is technically valid, it does not pass FCrDNS checks when your mail server identifies itself as mail.yourcompany.com in the SMTP HELO/EHLO greeting.

Multiple IPs, same PTR

If you have multiple mail servers on different IPs, each IP needs its own PTR record pointing to a hostname that resolves back to that specific IP. Sharing PTR records across IPs breaks FCrDNS.

PTR record points to a hostname that does not resolve

The PTR record exists, but the hostname it points to has no A record. This is a broken configuration that fails both FCrDNS and basic validation.

How to configure reverse DNS

PTR records are managed by whoever controls the IP address block -- typically your hosting provider or ISP, not your DNS registrar. This is a common point of confusion.

AWS (EC2 / Elastic IP)

For Elastic IP addresses, AWS allows you to set rDNS:

1. Open the AWS Management Console
2. Go to EC2 > Elastic IPs
3. Select the Elastic IP
4. Actions > Update Reverse DNS
5. Enter the hostname (e.g., mail.yourcompany.com)

The hostname must already have an A record pointing to the Elastic IP before AWS will accept it.

Google Cloud

Request PTR records through the Google Cloud Console:

1. Go to VPC Network > External IP addresses
2. Click the IP address
3. Set the reverse DNS entry

Azure

For Azure public IPs:

az network public-ip update \
  --resource-group your-rg \
  --name your-ip \
  --reverse-fqdn mail.yourcompany.com.

Dedicated server or colocation

Contact your hosting provider or ISP. They manage the reverse DNS zone for the IP block they have assigned to you. You will typically need to submit a support ticket requesting the PTR record.

Self-managed IP block

If you own the IP block (allocated directly by a regional internet registry), you manage your own reverse DNS zone. Add a PTR record in your reverse zone file:

25.113.0.203.in-addr.arpa.  IN  PTR  mail.yourcompany.com.

Ensuring consistency with forward DNS

After configuring rDNS, verify the full chain is consistent:

1. Your MX record points to mx1.mail-provider.com
2. mx1.mail-provider.com resolves to 203.0.113.25
3. 203.0.113.25 has a PTR record pointing to mx1.mail-provider.com
4. Your SPF record authorises 203.0.113.25

If you manage your own mail servers (not using a hosted provider like Google Workspace or Microsoft 365), each server's IP must have a correctly configured PTR record.

Managed email providers

If you use Google Workspace, Microsoft 365, or another hosted email provider, they manage the PTR records for their mail servers. You do not need to configure rDNS for their IPs. However, if you send email through your own servers (transactional email, marketing email, SMTP relay), those servers need PTR records.

Reverse DNS and email authentication

Reverse DNS is one layer in the email authentication stack. It works alongside:

• SPF -- authorises which IPs can send email for your domain
• DKIM -- cryptographically signs email content
• DMARC -- ties SPF and DKIM together with a policy

All four layers -- rDNS, SPF, DKIM, and DMARC -- contribute to your domain's email reputation. Missing any one weakens the overall stack and increases the chance of deliverability problems. For the full picture, see our email spoofing prevention guide.

How SurfaceScan helps

SurfaceScan checks reverse DNS for every IP address and mail server in your attack surface. It detects missing PTR records, FCrDNS mismatches, and inconsistencies between your MX records and the rDNS of the mail servers they point to. Findings appear in the Email Security and DNS sections, so you can fix deliverability issues before they result in bounced email or damaged sender reputation.