Reverse DNS is one of the infrastructure checks that can determine whether your email server is trusted by receiving mail systems. If your sending IP address has no valid PTR record, or its reverse DNS hostname does not resolve back to the original IP, receiving servers may reject or distrust your messages before evaluating their content.
For businesses running their own SMTP servers, VPS-based mail infrastructure, or dedicated sending IPs, configuring reverse DNS correctly is an important part of email server administration. It is also an area that creates confusion for Google Workspace and Microsoft 365 users, who do not directly control the outbound IP addresses used by those platforms.
This guide explains what a PTR record does, how reverse DNS works, how to check forward-confirmed reverse DNS (FCrDNS), where to configure PTR records, and how to troubleshoot common problems in 2026
What Is Reverse DNS (PTR) in Email?
Reverse DNS (rDNS) is a DNS lookup process that maps an IP address back to a hostname. It uses a PTR (Pointer) record to identify the hostname associated with an IP address.
Regular DNS performs a forward lookup:
Domain:
mail.example.comIP address:
203.0.113.25
Reverse DNS performs the opposite lookup:
IP address:
203.0.113.25Hostname:
mail.example.com
When a receiving mail server receives an SMTP connection, it can examine the sending IP address and perform a reverse DNS lookup. This helps establish whether the connecting server has a properly configured network identity.
A valid PTR record is particularly important for organizations operating their own mail servers or dedicated sending IPs.
PTR Record vs. A Record
Although both records are part of DNS, they perform different functions.
DNS Record | Purpose | Example |
|---|---|---|
A record | Maps a hostname to an IPv4 address |
|
AAAA record | Maps a hostname to an IPv6 address |
|
PTR record | Maps an IP address back to a hostname |
|
A records and AAAA records are configured in the forward DNS zone. PTR records are configured in the reverse DNS zone controlled by the owner of the IP address block.
This distinction is important: changing your domain's DNS settings does not automatically change the PTR record associated with your sending IP.
Why Does Reverse DNS Matter for Email Deliverability?
Receiving mail servers use several signals to assess incoming messages. These include IP reputation, domain authentication, reverse DNS, sending patterns and message characteristics.
A correctly configured PTR record helps identify the server responsible for an incoming SMTP connection.
Here are four reasons reverse DNS matters.
1. It Establishes a Consistent Server Identity
A sending IP should resolve to a recognizable hostname. A missing or inconsistent reverse DNS configuration can make it harder for receiving systems to establish the identity of the connecting server.
2. It Supports Forward-Confirmed Reverse DNS
Receiving systems can verify that the hostname returned by a PTR lookup resolves back to the original sending IP. This is called forward-confirmed reverse DNS.
3. It Helps Meet Mailbox Provider Requirements
Google's published sender guidelines require sending IP addresses to have valid PTR records. The hostname returned by the PTR lookup must also resolve to the same sending IP through an A or AAAA record.
Microsoft 365 also uses forward-confirmed reverse DNS for its outbound sending IP infrastructure.
4. It Helps Diagnose SMTP Rejections
If an SMTP connection is rejected because of a reverse DNS problem, checking the PTR record can help identify the underlying infrastructure issue.
Important: A valid PTR record does not guarantee inbox placement. It does not replace SPF, DKIM, DMARC, a healthy sending reputation or responsible sending practices.
How Forward-Confirmed Reverse DNS (FCrDNS) Works
Forward-confirmed reverse DNS, commonly called FCrDNS, verifies that forward and reverse DNS records agree.
It involves two main checks.
Step 1: Reverse lookup
A receiving server checks the PTR record of the sending IP address.
203.0.113.25 → mail.example.com
Step 2: Forward lookup
The receiving server checks whether the returned hostname resolves to the original IP address.
mail.example.com → 203.0.113.25
If both lookups agree, forward-confirmed reverse DNS passes.
Example of a Correct FCrDNS Configuration
Check | Expected result |
|---|---|
Sending IP |
|
PTR hostname |
|
Forward A record |
|
FCrDNS result | Pass |
Example of an Incorrect Configuration
Check | Result |
|---|---|
Sending IP |
|
PTR hostname |
|
Forward A record |
|
FCrDNS result | Fail |
The PTR hostname resolves to a different IP address, so the two records do not match.
For an IPv6 sending address, the forward confirmation uses an AAAA record instead of an A record.
How to Check a PTR Record
You can check reverse DNS using command-line tools without changing any DNS settings.
The following examples use documentation-only IP addresses. Replace them with your actual sending IP address when performing a real check.
Method 1: Check PTR Using dig
On Linux or macOS, open Terminal and run:
A successful lookup might return:
This confirms that a PTR record exists for the example IP.
If the command returns no result, the reverse DNS record may be missing or unavailable.
Method 2: Verify the Forward DNS Record
Now check whether the returned hostname resolves to the original IP:
Expected result:
For an IPv6 hostname, use:
The returned address must match the original IPv6 sending address.
Method 3: Use nslookup
If you prefer a simpler command, use:
The output should identify the hostname associated with the IP address.
You can also perform a forward lookup:
Compare the returned IP address with your sending server's actual IP.
Method 4: Check PTR Using Windows
Windows administrators can use Command Prompt or PowerShell.
Open Command Prompt and enter:
To check the forward record:
Both results should agree.
Quick PTR Verification Checklist
Before sending production email from a self-managed IP, confirm the following:
A PTR record exists for the sending IP.
The PTR returns the intended fully qualified hostname.
The hostname resolves back to the original IP.
The correct address family is configured for IPv4 or IPv6.
The SMTP HELO/EHLO hostname is consistent with the server's identity.
Your email authentication records are configured correctly.
How to Configure a PTR Record: Step-by-Step Guide
Configuring a PTR record requires access to the provider responsible for your sending IP address.
You generally cannot configure it through your domain registrar unless you also control the relevant reverse DNS zone.
Step 1: Identify Your Sending IP Address
First, identify the public IP address that actually establishes outbound SMTP connections.
On a Linux server, you can use:
For IPv6:
If your server uses an SMTP relay, load balancer or third-party sending service, the connecting IP may belong to that provider rather than your own server.
Use actual SMTP connection logs or message headers to identify the correct IP.
Step 2: Choose a Hostname
Choose a fully qualified hostname under a domain you control.
For example:
mail.example.com
or
mta1.example.com
The hostname should be stable and appropriate for your mail server.
Step 3: Create the Forward DNS Record
Open your domain's DNS management panel and create an A record.
Example:
Field | Value |
|---|---|
Type | A |
Host | |
Value | 203.0.113.25 |
TTL | Provider default |
For IPv6, configure the corresponding AAAA record.
Verify that the hostname resolves to the intended IP before requesting the PTR record.
Step 4: Configure the PTR Through Your IP Provider
Log in to the control panel of your VPS, cloud or hosting provider.
Look for an option labelled:
Reverse DNS
rDNS
PTR Record
Reverse Hostname
Enter your selected hostname and save the configuration.
If your provider does not offer a self-service option, open a support ticket and request the PTR record.
Step 5: Align Your SMTP HELO/EHLO Hostname
Your SMTP server identifies itself using the HELO or EHLO command during an SMTP session.
For a self-managed mail server, configure its announced hostname consistently with the PTR hostname.
For example, in Postfix:
After changing the configuration, validate it and reload Postfix according to your server's operating procedures.
If you use a hosted email service, you generally cannot change its underlying SMTP server identity yourself.
Step 6: Verify the Configuration
Run both checks again:
Confirm that the hostname and IP match.
You should also send a test message and inspect its Received headers to understand which server and IP handled the connection.
If your mail server can send through IPv6, verify that the actual outbound IPv6 address has an appropriate PTR record and that the returned hostname resolves back through AAAA.
A common troubleshooting mistake is checking only IPv4 while the server establishes an SMTP connection over IPv6.
If your provider cannot configure IPv6 reverse DNS, discuss the appropriate alternative with its support team before enabling IPv6 outbound email.
PTR Records and Google Workspace or Microsoft 365
This is one of the most important distinctions for businesses using hosted business email.
If you operate a self-hosted SMTP server, you may control the sending IP and request its PTR record from your hosting provider.
However, Google Workspace and Microsoft 365 use their own outbound mail infrastructure.
When messages leave through Google or Microsoft servers, the receiving server sees the provider's outbound sending IP, not necessarily an IP assigned to your domain.
That means:
You manage your own domain's SPF, DKIM and DMARC records.
Google manages reverse DNS for Google's outbound sending infrastructure.
Microsoft manages reverse DNS for Microsoft's outbound sending infrastructure.
You should contact the relevant provider if its outbound infrastructure produces a PTR-related rejection.
Adding a PTR record for your own domain in Cloudflare will not change the PTR of Google's or Microsoft's sending IP.
This is also why checking the actual outbound connection matters more than checking an unrelated IP address associated with your website or DNS hosting.
How to Maintain Healthy Email Infrastructure in 2026
Configuring PTR is not the end of email infrastructure management.
Businesses should regularly review their DNS records, sending configuration and authentication results.
Follow these practices:
Verify reverse DNS after IP changes: A new IP may require a new PTR record.
Monitor IPv4 and IPv6 separately: Do not assume both address families are configured.
Check HELO/EHLO consistency: Keep your self-managed SMTP server's announced hostname aligned with its intended identity.
Review SPF, DKIM and DMARC: Ensure that your domain authentication remains valid.
Monitor SMTP errors: Investigate actual bounce codes instead of assuming every delivery problem is DNS-related.
Document infrastructure ownership: Know which provider controls your IP addresses, DNS zones and mailboxes.
For businesses managing multiple sending accounts, maintaining this information centrally makes troubleshooting and infrastructure changes easier.
Common PTR Record Problems and How to Fix Them
Problem | Possible cause | Recommended action |
|---|---|---|
No PTR record found | Reverse DNS has not been configured | Contact the IP provider |
PTR resolves to the wrong hostname | Incorrect reverse DNS entry | Request a correction |
FCrDNS fails | Forward A/AAAA record does not match | Correct the forward record |
IPv4 works but IPv6 fails | Missing IPv6 PTR | Configure IPv6 reverse DNS |
PTR works but SMTP rejects | Another authentication or reputation issue | Inspect the full SMTP response |
Cannot edit PTR in Cloudflare | PTR zone belongs to IP provider | Contact your hosting provider |
PTR changed but old result appears | DNS caching or propagation | Recheck after the provider's stated update period |
A PTR problem should not automatically be blamed for every email rejection. Check the actual SMTP response and authentication results before changing your infrastructure.
PTR vs SPF, DKIM and DMARC: Understanding the Difference
PTR is only one part of a properly configured email infrastructure.
SPF, DKIM and DMARC perform different authentication functions.
Component | What it verifies |
|---|---|
PTR / Reverse DNS | Maps a sending IP address back to a hostname |
SPF | Identifies servers authorized to send for a domain |
DKIM | Verifies a cryptographic signature attached to a message |
DMARC | Defines domain alignment and handling policies for authentication failures |
These technologies complement one another.
A properly configured PTR record does not mean SPF, DKIM and DMARC are automatically correct.
If you need help configuring the three main authentication records, read LiteMail's SPF, DKIM and DMARC Setup Guide.
For a broader infrastructure overview, see our Cold Email Infrastructure Guide.
How LiteMail Helps Simplify Cold Email Infrastructure
Managing email infrastructure involves more than purchasing mailboxes. Businesses also need properly configured domains, authentication records, mailbox administration and connections to their preferred sending platforms.
LiteMail provides Google Workspace and Microsoft 365 business inbox options, automated DNS configuration, SPF, DKIM and DMARC setup, and OAuth connectivity with supported cold email platforms.
Instead of manually configuring every mailbox, businesses can manage their email infrastructure through one platform.
An important distinction: LiteMail's automated domain authentication setup does not mean customers can independently change Google's or Microsoft's outbound PTR records. Those records remain under the control of the provider operating the actual sending IP.
Explore LiteMail's Cold Email Infrastructure to learn more about its inbox and infrastructure options.
Frequently Asked Questions
1. What is a PTR record in email?
A PTR record maps an IP address back to a hostname through reverse DNS. Receiving mail servers can use it to identify the sending server and verify its network identity.
2. How do I check a PTR record?
Run dig -x YOUR_IP +short on Linux or macOS, or use nslookup YOUR_IP on Windows. The result should return the hostname associated with the IP address.
3. Can I create a PTR record in Cloudflare?
Usually, no. Cloudflare manages your forward DNS zone, while the PTR record belongs to the reverse DNS zone controlled by the IP address owner. You need to contact your hosting or cloud provider.
4. What is forward-confirmed reverse DNS (FCrDNS)?
FCrDNS is a two-way verification process. First, the IP address resolves to a hostname through PTR. Then, that hostname resolves back to the same IP through A or AAAA.
5. Does Google Workspace manage its own PTR records?
Google manages the reverse DNS configuration for its outbound sending infrastructure. Google Workspace customers manage their domain authentication records, but they do not independently configure PTR records for Google's sending IP addresses.
6. Does a PTR record guarantee email inbox placement?
No. PTR is an infrastructure identity check, not a guarantee of inbox placement. SPF, DKIM, DMARC, IP and domain reputation, recipient engagement and sending practices also influence delivery.
7. Do I need a separate PTR record for every sending domain?
Not necessarily. A PTR record is associated with an IP address, not each sending domain. A server can send for multiple authenticated domains using the same IP and PTR hostname.
8. Do IPv6 email servers need PTR records?
Yes. If your server sends email through IPv6, the outbound IPv6 address should have valid reverse DNS, with the returned hostname resolving back to that IPv6 address through AAAA.
Final Takeaway
Reverse DNS is an important part of email server identity and SMTP infrastructure. A correct PTR record, matching forward DNS and consistent SMTP hostname help establish a properly configured sending environment.
If you manage your own SMTP server or dedicated sending IP, verify reverse DNS before sending production email. If you use Google Workspace, Microsoft 365 or another hosted email service, understand which provider controls the actual outbound IP and contact it when a PTR-related issue occurs.
Good email infrastructure starts with knowing which parts you control, which parts your provider manages and how to verify that everything works together.
