Skip to main content

How to Check PTR (Reverse DNS) Record Status in Saleshandy

Written by Yashal Vagadia
Updated this week

Hello there, Saleshandy users! 👋

In this guide, you’ll learn how to check the PTR (Reverse DNS) record status inside Saleshandy and understand what it means for your email deliverability.

Understanding PTR (Reverse DNS) & Its Role in Your Email Setup

PTR, also known as Reverse DNS, is a deliverability signal linked to your sending IP.

Many users assume that once SPF, DKIM, and DMARC are configured, email deliverability is fully optimized. In reality, emails can still land in spam or get rejected if the PTR record is missing.

Saleshandy now shows the PTR status directly inside the platform, so you can identify such risks early.

A PTR record maps:

IP address → Hostname

Example: 192.0.2.10 → mail.domain.com

It is different from SPF, DKIM, and DMARC because:

  • It is not set from your domain DNS zone

  • It is configured by the IP owner, such as your SMTP provider or cloud provider

You might see SPF, DKIM, and DMARC marked as configured and assume your email setup is complete.

However, emails can still land in spam or get rejected if the PTR record linked to your sending IP has issues.

Why Emails Can Still Fail Even If SPF, DKIM, and DMARC Are Set

Even if authentication records are configured, emails can still land in spam or get rejected if the PTR record linked to your sending IP has issues.

This can happen when:

  • Your sending IP does not have a PTR record

  • Your sending IP resolves to a hostname, but that hostname does not resolve back to the same IP

  • The hostname linked to your IP does not align with your sending domain

In simple terms, mailbox providers verify whether your sending IP and domain are properly connected and consistent.

If that connection looks broken, your emails may:

  • Be flagged as suspicious

  • Land in spam

  • Get rejected before delivery

Where to Check Your PTS Status in Saleshandy

You can view PTR status in your Email Accounts screen, in the same row as:

You can also view your PTR status in your Email Setup Score screen:

Another way is to navigate to Inbox Radar, click on email authentication:

A pop-up will appear, and you can now check the PTR status of each domain:

In the same Inbox Radar report, scroll down to the “Placement Insights” section to view the PTR status there as well.

PTR Status Types Explained

Saleshandy automatically detects and displays two PTR status types:

1️⃣ ❌ Missing

What it means:

No PTR (Reverse DNS) record is found for your sending IP. This means your PTR record is not set.

Impact:

This may negatively affect deliverability. Emails can land in spam or get rejected by certain mailbox providers.

What you should do:
Contact your SMTP provider or dedicated IP provider and request that they configure the PTR record for your sending IP.

2️⃣ ✅ Configured

What it means:
A valid PTR record exists for your sending IP.

This includes cases where:

  • You manually configured the domain alignment with your IP provider

  • Your inbox is connected via providers like Google or Microsoft, where PTR is managed automatically by the provider

Impact:
Your reverse DNS setup is properly handled. No action is required.

What Saleshandy Does Not Support

Saleshandy does not:

  • Allow adding or editing PTR records

  • Provide a DNS editor

  • Automatically configure PTR

PTR must always be fixed by the IP owner.

Important Considerations

  • PTR is set by the IP owner, not in your DNS zone

  • It is not equally important for every mailbox

  • For Google or Microsoft OAuth, PTR is not user-managed

  • PTR results are cached for 24 hours to avoid frequent DNS lookups

What Should You Do If PTR Shows an Issue?

If status is missing, you need to contact:

  • Your SMTP provider
    OR

  • Your dedicated IP provider

Saleshandy provides visibility and direction, but configuration must be done on the IP owner side.

By checking PTR alongside SPF, DKIM, and DMARC, you can identify deliverability risks earlier and ensure your sending infrastructure is correctly aligned.

Did this answer your question?