Reverse DNS (PTR) for cold email senders: what it is and when to fix it
PTR records are usually somebody else's problem. Here is when they become yours.
Rejwan Nirob·Feb 22, 2026·4 min readA PTR record (reverse DNS) maps an IP address back to a hostname. Mailbox providers check it as a basic sanity test - if the sending IP has no PTR, or the PTR points at a generic provider hostname, that is a soft negative signal. For shared SaaS-provisioned mailboxes the PTR is set by the provider and you do not need to think about it. For dedicated SMTP, you do.
What a good PTR looks like
The PTR should resolve to a hostname under your sending domain. mail.yourcompany.com is fine. mta-1.outbound.aws.amazonaws.com is not - it is generic and tells the receiver you have not bothered to configure your own infrastructure.
How to check
- Run dig -x <your-sending-IP> +short
- Verify the result resolves to a hostname under your domain
- Verify forward-confirmed reverse DNS - the hostname must point back to the same IP
- For shared SaaS senders this is set by the provider - not your responsibility
Why most cold senders ignore this
Shared SaaS infrastructure handles PTR automatically and correctly. The recipient sees Workspace or M365 hostnames, which are trusted by every receiver. The PTR conversation only becomes interesting when you move to dedicated SMTP - at which point your provider should configure PTR with your domain at provisioning.
Lee SMTP (coming soon) ships dedicated IPs with PTR pointing back to a hostname under your sending domain. Forward-confirmed reverse DNS verified at provisioning.
Join the waitlistFrequently asked
What is a PTR record and why does email need it?
A PTR record (reverse DNS) maps an IP address back to a hostname. Mailbox providers check it as a basic sanity test - if the sending IP has no PTR or it points at a generic provider hostname (mta-1.outbound.aws.amazonaws.com), receivers treat it as a soft negative signal. The PTR should resolve to a hostname under your sending domain.
Do I need to configure PTR for cold email on shared infrastructure?
No. For shared SaaS-provisioned mailboxes (Google Workspace, Microsoft 365), the PTR is set by the provider and you do not need to think about it. Recipients see trusted Workspace or M365 hostnames. The PTR conversation only becomes your problem when you move to dedicated SMTP.
How do I check my PTR record?
Run dig -x <your-sending-IP> +short. Verify the result resolves to a hostname under your domain. Then verify forward-confirmed reverse DNS: the hostname must point back to the same IP. Mismatched FCrDNS is treated almost as badly as no PTR at all.
What is forward-confirmed reverse DNS (FCrDNS)?
FCrDNS is the two-way check: the IP's PTR resolves to a hostname, AND that hostname resolves back to the same IP. Mailbox providers verify both directions. Single-direction PTR (where the hostname does not resolve back to the same IP) gets the same negative reputation signal as missing PTR.