Missing PTR Record: Why Reverse DNS Matters for Email

What a PTR Record Is

A PTR (Pointer) record maps an IP address to a hostname — the reverse of what an A record does. While an A record answers "what IP address does mail.example.com resolve to?", a PTR record answers "what hostname is associated with IP 203.0.113.10?"

PTR records live in a special reverse DNS zone defined in RFC 1035 Section 3.5. For IPv4, the zones are under in-addr.arpa. The PTR record for 203.0.113.10 is stored at 10.113.0.203.in-addr.arpa (octets reversed). For IPv6, the zones are under ip6.arpa with each nibble reversed per RFC 3596.

Reverse DNS is a fundamental component of internet infrastructure. For email, it serves as a baseline trust signal that receiving servers use to evaluate whether a sending IP is a legitimate mail server.

The short answer: if your sending IP has no PTR record, Gmail, Microsoft 365, and Yahoo are more likely to reject or spam-folder your email. Set up a PTR that matches your mail server hostname and passes forward-confirmed reverse DNS (FCrDNS).

Why PTR Records Matter for Email

Receiver Policies

Most major email providers check the PTR record of every connecting IP as part of their spam evaluation:

Gmail explicitly states in their sender guidelines that sending IPs must have a PTR record. IPs without reverse DNS are more likely to have email rejected or routed to spam.

Microsoft 365 (Exchange Online Protection) factors PTR records into its IP reputation scoring. Missing PTR does not cause an immediate block, but it degrades your reputation and makes other issues (like a minor spam complaint) more likely to trigger a 5.7.708 block.

Yahoo/AOL check PTR records and reject connections from IPs without valid reverse DNS, particularly for high-volume senders.

Anti-spam systems (SpamAssassin, rspamd, and others) assign negative scores to email from IPs without PTR records, increasing the likelihood of spam classification.

Forward-Confirmed Reverse DNS (FCrDNS)

Having a PTR record is not enough on its own. Receiving servers perform a check called forward-confirmed reverse DNS (FCrDNS):

1. Look up the PTR record for the sending IP (e.g., 203.0.113.10 -> mail.example.com)
2. Look up the A record for the returned hostname (e.g., mail.example.com -> 203.0.113.10)
3. Verify that the IP from step 2 matches the original sending IP from step 1

If this round-trip check passes, the reverse DNS is "forward-confirmed." This proves that whoever controls the hostname also controls the IP, establishing a verified relationship between the two.

FCrDNS failure — where the PTR exists but the hostname does not resolve back to the same IP — is treated almost as poorly as having no PTR at all.

What "No PTR Record" Means in Practice

When the mxio PTR Lookup tool reports no PTR record for your IP, it means one of the following:

No reverse DNS entry exists. The IP has no PTR record configured at all. This is common with cloud VPS instances, shared hosting, and newly provisioned servers where reverse DNS was not set up.

The PTR record exists but returns NXDOMAIN. The reverse DNS zone exists, but there is no record for your specific IP within it. This happens if you were assigned an IP from a block where only some IPs have PTR records configured.

The PTR record exists but the hostname does not resolve back. The PTR points to a hostname, but that hostname either has no A record or its A record points to a different IP. This fails FCrDNS validation and is effectively as bad as having no PTR.

In any of these cases, receiving mail servers see your IP as unverified, which harms deliverability.

How to Check Your PTR Record

Run the mxio PTR Lookup tool with your mail server's IP address. The tool:

• Queries the reverse DNS zone for your IP
• Shows the hostname the PTR points to (if any)
• Performs the forward lookup to check FCrDNS
• Reports whether the round-trip validation passes

If you are not sure which IP your mail server uses for outbound connections, check the Received headers on a recent email you sent — the connecting IP is shown in the first external server hop. You can also review your outbound SMTP logs or your email provider's documentation. Note that MX records point to inbound servers, which may use different IPs than your outbound path.

Who Controls PTR Records

This is one of the most common points of confusion in email administration: PTR records are not managed by your DNS provider. They are managed by whoever owns the IP address block — typically your hosting provider or ISP.

Forward DNS (A, MX, TXT records, etc.) is controlled by whoever manages the domain's nameservers. Reverse DNS is controlled by whoever holds the IP allocation from the Regional Internet Registry (ARIN, RIPE, APNIC, etc.). For most organizations, that is your hosting company, cloud provider, or ISP.

You cannot set a PTR record in Cloudflare, GoDaddy, Namecheap, or any domain DNS provider for an IP you do not own the reverse zone for. The request must go to whoever controls the IP block.

How to Set Up a PTR Record

Step 1: Determine Your Mail Server's Outbound IP

This is the IP address that receiving servers see when your mail server connects to them. It may differ from the IP your website uses, especially if you are behind a NAT gateway or using a separate outbound IP for SMTP.

Step 2: Choose the Hostname

The PTR record should point to a hostname that:

• Is under a domain you control (e.g., mail.yourdomain.com, not a generic ISP hostname)
• Has an A record pointing back to the same IP (for FCrDNS)
• Looks like a legitimate mail server (not host-203-0-113-10.residential.isp.net)

A good PTR hostname: mail.yourdomain.com or smtp.yourdomain.com.

Step 3: Create the Forward A Record

Before requesting the PTR, create an A record for the hostname you have chosen:

mail.yourdomain.com  A  203.0.113.10

This must be in place before (or at the same time as) the PTR, so that FCrDNS validation passes immediately.

Step 4: Request the PTR Record

Contact your hosting provider or ISP and request that they set the PTR record for your IP to your chosen hostname. The process varies by provider:

AWS EC2: Submit a reverse DNS request through the AWS support console. You must first assign an Elastic IP and set up forward DNS before requesting the PTR.

DigitalOcean: Configure reverse DNS in the Networking section of your Droplet's settings. Set the PTR to your mail server's hostname (e.g., mail.yourdomain.com).

Linode/Akamai: Set the reverse DNS in the Linode Manager under the Networking tab for your Linode.

Vultr: Set reverse DNS in the server settings panel under the IPv4 section.

Traditional hosting/ISP: Open a support ticket requesting the PTR record. Provide the IP address and the hostname you want it to point to.

Step 5: Verify

After the PTR is created, run the mxio PTR Lookup tool to confirm:

• The PTR record returns your chosen hostname
• The hostname resolves back to the same IP (FCrDNS passes)

Allow up to 24-48 hours for reverse DNS changes to propagate, though most updates take effect within a few hours.

Best Practices

Use a Meaningful Hostname

Your PTR hostname should clearly identify the server as a legitimate mail server under your domain. Avoid:

• Generic ISP hostnames (pool-1-2-3-4.res.isp.com) — these signal residential or unmanaged connections
• IP-based hostnames (ip-203-0-113-10.example.com) — these look auto-generated and do not build trust
• Hostnames under someone else's domain — the PTR should point to a name you control

One PTR Per IP

Each IP address should have exactly one PTR record. Multiple PTR records for a single IP are technically valid in DNS but cause confusion and unpredictable behavior with FCrDNS validation. Stick to one hostname per IP.

Match Your EHLO/HELO Hostname

Your mail server announces itself with a hostname in the SMTP EHLO greeting. RFC 5321 Section 4.1.4 requires the EHLO argument to be a valid fully-qualified domain name. Ideally, the EHLO hostname, the PTR record, and the A record should all agree:

IP 203.0.113.10
  -> PTR: mail.yourdomain.com
  -> A record for mail.yourdomain.com: 203.0.113.10
  -> EHLO greeting: mail.yourdomain.com

This three-way consistency is the strongest signal to receiving servers that your IP is a legitimate, properly configured mail server.

Keep Records in Sync

If you change your mail server's IP (e.g., migrating to new infrastructure), update both the A record and the PTR record. Stale PTR records pointing to old hostnames that no longer resolve are a common cause of FCrDNS failures after migrations.

Prevention and Ongoing Monitoring

PTR records are stable infrastructure — they rarely change on purpose. But they break during IP migrations, hosting provider changes, and cloud instance re-provisioning. The problem is silent: you will not know your PTR is missing until email starts bouncing or landing in spam.

Set up domain health monitoring to track your sending IP's reverse DNS alongside your SPF, DKIM, and DMARC records. Continuous monitoring catches PTR issues the moment they appear — before they erode your sending reputation.

Related Issues

• How to Check If You're Blacklisted and Get Delisted — Missing PTR records contribute to blacklistings
• IP Blocked by Microsoft 365 (5.7.708) — EOP checks PTR as part of IP reputation
• Emails Going to Spam — PTR records are one factor in spam filtering decisions
• Bulk Sender Requirements — PTR records are required for high-volume senders
• Email Bounce Codes — Understanding delivery failure codes