How to Verify and Troubleshoot rDNS (Reverse DNS) for SendGrid Dedicated IPs

 

Objective

This article explains how to check and verify reverse DNS (rDNS) records for SendGrid dedicated IP addresses using the dig terminal command. It is designed to help agents confirm correct rDNS setup for a customer's sending domain, matching the PTR (reverse DNS) record and the corresponding A record, as customers may ask why their email deliverability or authentication (SPF, DKIM, DMARC) is being affected. Keywords: rDNS, PTR, dedicated IP, email authentication.

 

Product

Twilio SendGrid (Email API, Dedicated IPs)

 

User Account Permission/Role(s) Required 

Support agents with access to Kasi

 

Procedure 

  1. Identify the Dedicated IP Find the customer's dedicated IP address assigned for their SendGrid sending.
     

  2. Perform a PTR (Reverse DNS) Lookup In a terminal, run:

    dig -x <dedicated-ip> +short

    Example:

    dig -x 159.183.127.184 +short

    Expected result:

    o1.ptr1234.yourdomain.com.

    This command returns the PTR (reverse DNS) record associated with the customer's dedicated IP address. The returned value should be the PTR hostname created by SendGrid—usually in the format o#.ptr###.yourdomain.com or a similar custom subdomain chosen by the customer. An example of a customer's custom subdomain for the PTR record format would be o#.mail.yourdomain.com. This hostname represents the PTR record assigned to the customer's dedicated IP.
     

  3. Check the Matching A Record Now run an A record lookup on the hostname returned by the PTR record:

    dig A <hostname-from-PTR> +short

    Example:

    dig A o1.ptr1234.yourdomain.com +short

    Expected result:

    159.183.127.184

    The returned IP address should exactly match the dedicated IP from step 1.
     

  4. Verify Results Match A correct rDNS configuration exists when:

    • The PTR lookup of the dedicated IP returns the expected hostname.
    • The A record lookup of that hostname returns the same dedicated IP.

    If these do not match, or either side is missing/unexpected, this indicates a DNS misconfiguration that can cause authentication issues or affect deliverability.
     

  5. Troubleshooting
    • If recent DNS changes were made, inform the customer DNS propagation may take up to 24-48 hours.
    • If misalignment persists, advise the customer (or their DNS admin) to update their DNS records so the PTR and A record both point to and from the dedicated IP and its assigned hostname.

 

Most Common Customer Error: Gmail/Yahoo Sender Requirement

Since Gmail and Yahoo tightened sender requirements in 2024, customers may encounter this common error when rDNS is not correctly set:

 

Reason
421 4.7.23 [IP Address here] The IP address sending this message does not have a PTR record, or the corresponding forward DNS entry does not match the sending IP. To protect our users from spam, mail has been temporarily rate limited. To learn more about IP address requirements for sending to Gmail, visit https://support.google.com/a?p=sender-guidelines-ip To learn more about Gmail requirements for bulk senders, visit https://support.google.com/a?p=sender-guidelines.

 

What this means:

  • Gmail (and increasingly, other major ISPs) require that:
    • The sending IP has a valid PTR (reverse DNS) record.
    • The PTR record’s hostname must resolve back to the same sending IP (forward-confirmed rDNS).
  • A failure in rDNS configuration can lead to temporary deferrals, rate limiting, or even delivery rejection.

 

Resolution: Follow the procedure above to ensure PTR and A records are correctly aligned. Advise customers to wait for DNS propagation after any changes, and to retest after 24–48 hours.

If the problem persists once DNS is corrected, review the official Gmail sender guidelines:

 

Additional Information 

 

Have more questions? Submit a request