How do I check if the sending IP address matches the IP address of the hostname specified in the Pointer (PTR) record?
Michael Ko
Co-founder & CEO, Suped
Published 8 Jun 2025
Updated 17 Aug 2025
7 min read
Email deliverability relies heavily on proper DNS configuration, and one of the critical aspects is ensuring that your sending IP address correctly matches the hostname specified in your Pointer (PTR) record. This alignment, often referred to as forward-confirmed reverse DNS (FCrDNS), is a key trust signal for receiving mail servers. Without it, your emails might face increased scrutiny, leading to messages being flagged as spam or outright rejected.
The importance of this check has grown significantly with the latest email sender guidelines from major mailbox providers. They are increasingly stringent about email authentication and sender validation. Ensuring your PTR record is correctly configured and aligns with your sending IP is no longer just a best practice, but often a requirement for optimal inbox placement.
In this guide, I will walk you through how to verify this crucial match, covering manual checks, automated tools, and the broader implications for your email program.
Understanding PTR records and forward-confirmed reverse DNS (FCrDNS)
A PTR record, also known as a Pointer record, performs the opposite function of a standard A record. While an A record maps a domain name to an IP address (forward DNS), a PTR record maps an IP address back to a domain name (reverse DNS). This reverse lookup is crucial for email systems to verify the legitimacy of incoming connections.
Forward-confirmed reverse DNS (FCrDNS) is the complete verification process. It requires two steps. First, you perform a reverse DNS lookup on the sending IP address to get its associated hostname via the PTR record. Second, you perform a forward DNS lookup (A record lookup) on that hostname to ensure it resolves back to the original sending IP address. If both lookups match, FCrDNS passes.
Forward DNS (A record)
Purpose: Maps a domain name (e.g., mail.example.com) to an IP address (e.g., 203.0.113.45).
Who sets it: Typically configured by the domain owner in their DNS management panel.
Example:dig mail.example.com
This process helps receiving mail servers ensure the sending server's identity is consistent and not spoofed, a critical factor for email deliverability. Mailbox providers like Google specifically recommend FCrDNS for senders to maintain good reputation.
Reverse DNS (PTR record)
Purpose: Maps an IP address (e.g., 203.0.113.45) back to a domain name (e.g., mail.example.com).
Who sets it: Set by the Internet Service Provider (ISP) or hosting provider that owns the IP address.
To manually check if your sending IP matches the hostname in its PTR record, you will need to perform a two-step DNS lookup. This process is known as a full circle reverse DNS check. First, identify the sending IP address from an email's headers. In Gmail, you can do this by clicking the three dots next to the reply button and selecting 'Show Original.' Look for the 'Received' header that indicates the sending server's IP. The actual hostname of the server is typically seen in the HELO/EHLO command, which is often recorded in the 'Received' header itself. It is not necessary for the PTR hostname to match the domain in your email headers, such as the 'From' address or DKIM signing domain, but it must match the hostname that the IP points to.
Once you have the sending IP, the first step is to perform a reverse DNS lookup. This will tell you the hostname associated with that IP address according to its PTR record. You can use command-line tools like dig (on Linux/macOS) or nslookup (on Windows or Linux) for this. For example, if your sending IP is 192.0.2.100, you would execute the following command:
Reverse DNS lookup using digbash
dig -x 192.0.2.100
The output will show a PTR record, typically under the 'ANSWER SECTION,' mapping the IP back to a hostname, such as 'mail.example.com.' Take note of this hostname.
The second step is to perform a forward DNS lookup (A record lookup) on the hostname you obtained in the previous step. This will tell you what IP address that hostname resolves to. The goal is to see if it resolves back to your original sending IP address. Using dig again, if the PTR record resolved to 'mail.example.com,' you would use:
Forward DNS lookup using digbash
dig mail.example.com
If the IP address returned by this A record lookup is the same as your original sending IP address, then your FCrDNS is correctly configured. This two-way verification confirms that the sending IP address matches the hostname specified in the PTR record.
Tools and approaches for verification
While manual checks using command-line tools are effective, several online tools and scripts can automate this process, especially when managing multiple IP addresses or for quick diagnostics. These tools perform both the reverse and forward lookups for you, providing a straightforward pass/fail result for FCrDNS.
One popular option is MultiRBL.valli.org, which allows you to enter an IP address and select 'FCrDNS' from a dropdown to check the full circle resolution. Another is the Google Admin Toolbox Dig tool, which can also perform PTR lookups. For more automated or batch checks, command-line scripts like Nmap's FCrDNS script or Wordtothewise's roundtrip tool are excellent options for verifying multiple IPs or hostnames.
If you are sending email through an Email Service Provider (ESP), especially on a shared IP address, it's typically the ESP's responsibility to manage the PTR records. However, for dedicated IPs, you or your network administrator may need to coordinate with your hosting provider or ISP to ensure the PTR record is set up correctly and points to the appropriate hostname. Regularly checking this configuration is a vital part of proactive deliverability management.
Method
Description
Pros
Cons
dig -x / nslookup
Command-line tools for manual reverse and forward lookups.
Direct, authoritative results from your local DNS resolver.
Requires technical expertise and is cumbersome for bulk checks.
Scripts like Nmap's FCrDNS or custom tools for batch processing.
Efficient for checking many IPs, can be integrated into monitoring.
Requires scripting knowledge and setup on a server.
Impact of PTR record mismatch on email deliverability
A mismatch between your sending IP and the hostname specified in the PTR record (or a lack of a PTR record altogether) can significantly harm your email deliverability. Receiving mail servers use this check as a fundamental part of their anti-spam filters. If a server cannot confirm that the IP address sending the email legitimately belongs to the declared hostname, it raises a red flag.
This can lead to various negative consequences. Emails may be sent directly to the spam folder, delayed, or even rejected outright with bounce messages indicating PTR issues. Google, for example, explicitly states that the sending IP address must match the IP address of the hostname in the PTR record. Failure to comply can result in emails failing authentication checks and negatively impacting your sender reputation. If your IP is listed on a blocklist (or blacklist), this will only exacerbate deliverability challenges.
The consequence of a PTR mismatch
Receiving mail servers often use FCrDNS as a trust signal. A discrepancy can lead to:
Spam Folder Placement: Emails are more likely to be diverted from the inbox.
Rejection: Some servers may reject emails from non-compliant IPs outright.
Reputation Damage: A consistent PTR mismatch can negatively impact your sender reputation over time.
The importance of PTR records, along with other authentication methods, cannot be overstated for maintaining healthy email deliverability. A correctly configured PTR record and a successful FCrDNS check provide essential validation that your sending server is legitimate, which helps build trust with receiving mail servers and ensures your emails reach their intended recipients' inboxes.
Views from the trenches
Best practices
Always ensure your sending IP's PTR record points to a valid hostname.
Verify that the hostname in the PTR record has an A record that points back to the original sending IP address (FCrDNS).
For dedicated IPs, work closely with your ISP or hosting provider to set up and maintain PTR records.
Common pitfalls
Assuming your PTR record is automatically set up, especially with new IP allocations.
Deleting a PTR record or changing its hostname without updating the corresponding A record.
Not regularly checking FCrDNS, leading to silent deliverability issues.
Expert tips
Automate FCrDNS checks as part of your email monitoring routine to catch issues early.
Prioritize FCrDNS verification for dedicated IPs, as they are more prone to manual configuration errors.
Educate your team on the importance of DNS records, especially for new team members managing infrastructure.
Expert view
Expert from Email Geeks says to start with the hostname, look up the hostname to get an IP address, then look up the IP address to get a hostname. If that matches where you started, you're good.
2023-10-06 - Email Geeks
Marketer view
Marketer from Email Geeks says that if you are on shared IPs, it is safe to assume your ESP manages the PTR setup, but you can verify it by looking at the email header for the IP, for example, in Gmail's 'Show Original'.
2023-10-06 - Email Geeks
Ensuring ongoing compliance
Ensuring that your sending IP address matches the IP address of the hostname specified in your PTR record is a fundamental aspect of email deliverability and sender reputation. This FCrDNS check provides an essential layer of trust, allowing receiving mail servers to verify the authenticity of your outgoing mail.
By understanding how to perform both manual and automated FCrDNS checks, you can proactively identify and resolve potential issues that might otherwise lead to email rejections or spam folder placement. Regular monitoring of these DNS records is crucial for maintaining a strong sender reputation and ensuring your email campaigns achieve optimal inbox placement.
Gmail, you can do this by clicking the three dots next to the reply button and selecting 'Show Original.' Look for the 'Received' header that indicates the sending server's IP. The actual hostname of the server is typically seen in the HELO/EHLO command, which is often recorded in the 'Received' header itself. It is not necessary for the PTR hostname to match the domain in your email headers, such as the 'From' address or DKIM signing domain, but it must match the hostname that the IP points to.
