Resolving “PTR Record Missing” for SMTP Relay

A missing Pointer (PTR) record is one of the most common causes of email rejection when sending mail through an on-premises mail server, network appliance, or local SMTP relay. When your server attempts to deliver an email, the receiving gateway performs a reverse DNS lookup on your connecting IP address. If no PTR record exists to map that IP back to a valid hostname, major email providers will reject the connection or route your mail straight to spam.

Quick Answer

You cannot add a PTR record in your domain’s regular DNS zone. You must request a reverse DNS record through the ISP or cloud hosting provider that owns the public IP address. Set the PTR record to point to your mail server’s fully qualified domain name (FQDN).

---

How Reverse DNS Works in SMTP Transactions

Standard DNS translates human-readable hostnames into IP addresses (Forward DNS, using A or AAAA records). Reverse DNS does the exact opposite: it translates a numeric IP address back into a hostname using a PTR (Pointer) record stored in the special .in-addr.arpa (IPv4) or .ip6.arpa (IPv6) zones.

When an email is sent directly across the internet:

1. Your sending server connects to the recipient’s inbound mail server on port 25.
2. The recipient notes your public IP address (for example, 198.51.100.25).
3. The recipient queries public DNS for the PTR record assigned to that IP.
4. If no PTR record exists, or if the returned hostname does not resolve back to that same IP, the recipient flags the connection as suspicious or drops it.

This verification process is known as Forward-Confirmed Reverse DNS (FCrDNS).

[Sending Server: 198.51.100.25] ──► Connects to Recipient MTA
                                              │
                                              ▼
                             [Recipient Performs Reverse Lookup]
                             Queries PTR for 198.51.100.25
                                              │
                    ┌─────────────────────────┴─────────────────────────┐
                    ▼                                                   ▼
             [PTR Record Found]                               [PTR Missing: NODATA]
       Resolves to: mail.example.com                                    │
                    │                                                   ▼
       Forward lookup on mail.example.com                     [Connection Rejected]
       matches 198.51.100.25?                                 • 550 5.7.1 Access Denied
        ┌───────────┴───────────┐                             • 550 5.7.25 rDNS Failure
       YES                      NO
        │                       │
[FCrDNS Passes]          [FCrDNS Fails]
Connection Accepted      Dropped / Junked

---

Why Workspace and Recipient MTAs Enforce PTR Records

Spammers frequently send unwanted email using infected consumer PCs, compromised IoT devices, and residential broadband lines. These connections rarely have legitimate reverse DNS.

To combat abuse:

• Gmail and Yahoo Enforcement: Both providers require all sending MTAs to have valid PTR records matching their sending hostname. Connecting without a PTR record results in immediate rejection; see “550 5.7.25” IP Address Reverse DNS (rDNS) Failure.
• Outbound Google Workspace SMTP Relay: If your organization uses smtp-relay.gmail.com to route emails from multi-function copiers or internal software without user credentials, Google evaluates your network’s public IP. A missing PTR record can trigger Resolving “5.7.0” Permanent Failure: Access Denied.

---

Diagnostic Steps: Verifying Your PTR Status

Before contacting your provider, confirm whether your outbound IP is actually missing a PTR record.

1. Identify Your Outbound Public IP

From the network or server that sends the email, determine your public WAN IP:

curl -s <https://checkip.amazonaws.com>

2. Query the Reverse Record

Use dig or nslookup to test the PTR resolution:

# Using dig (macOS/Linux)
dig -x 198.51.100.25 +short

# Using nslookup (Windows)
nslookup -type=PTR 198.51.100.25

• If the output is empty or returns NXDOMAIN: Your IP has no PTR record configured.
• If the output returns a generic ISP name (e.g., cpe-198-51-100-25.houston.res.rr.com): You have a residential or unconfigured PTR record that will fail email delivery checks.
• If the output returns your custom mail hostname (e.g., mail.yourdomain.com): The PTR record is active. Now verify that mail.yourdomain.com resolves forward to 198.51.100.25.

---

How to Add a Missing PTR Record

Because PTR records exist in the reverse IP zone, you cannot create them in your standard domain registrar’s DNS panel (unless your ISP has formally delegated the entire subnet to your nameservers). You must configure reverse DNS with the organization that owns the IP block.

Scenario A: Static Business Internet (Comcast, AT&T, Spectrum, Verizon)

1. Log in to your ISP’s business portal or open a support ticket with commercial technical support.
2. Request a Static Reverse DNS (PTR) Record.
3. Provide two pieces of information:
   • Your static public IP address (198.51.100.25).
   • The Fully Qualified Domain Name (FQDN) of your mail server (mail.yourdomain.com).
4. Wait for the ISP to update their ARIN/RIPE records (typically 24 to 48 hours).

Scenario B: Cloud Infrastructure Providers

If your relay runs on a cloud host, you can set up rDNS directly through their management console:

• Amazon Web Services (AWS EC2): In the Amazon EC2 console, go to Network & Security > Elastic IPs. Select your Elastic IP, click Actions, select Update reverse DNS, enter your domain name, and save.
• Microsoft Azure: In the Public IP address resource, select Configuration, check DNS name label, and configure the reverse FQDN.
• Google Cloud Platform (GCP): In the VPC Network section, edit your static external IP address and enable Public DNS (PTR).
• DigitalOcean / Linode: Reverse DNS is automatically set to match the name of your virtual machine (Droplet/Linode). Rename the instance to your mail server’s FQDN (mail.yourdomain.com).

---

Alternative: What If Your ISP Cannot Provide a PTR Record?

If your office uses a dynamic IP, a residential connection, or an ISP that refuses to delegate custom PTR records, you should not send email directly out of that connection.

Instead, route your outbound messages through an authenticated relay service:

1. Configure your copier, scanner, or local application to use Google Workspace SMTP Relay (smtp-relay.gmail.com) over port 587 with TLS and user credentials. Review configuration rules in Troubleshooting SMTP Relay: “550 5.7.1 Relaying Denied”.
2. Alternatively, configure an external transactional mail service (such as SendGrid, Postmark, or Mailgun) as your outbound smarthost. These platforms handle reverse DNS on their own dedicated IP infrastructure.