A PTR record is the DNS entry that maps an IP address back to a domain name, the reverse of what a normal A record does. It is one of the signals a receiving mail server checks before accepting cold email. Unlike SPF, DKIM and DMARC, covered in our SPF, DKIM and DMARC setup guide, a PTR record is not something you publish in your own domain's DNS at all.
This page covers what a PTR record and reverse DNS mean, what forward-confirmed reverse DNS checks for, why mail receivers care, and the one fact that matters most for cold outreach: who actually controls it.
What is a PTR record in cold email sending?
A PTR record, short for pointer record, resolves an IP address to a domain name, which is the opposite direction of the standard A record that resolves a domain name to an IP address. A mail server with the IP 192.0.2.10 might have a PTR record pointing to mail.example.com, so any server that receives a connection from that IP can look up a name for it.
For cold email specifically, the PTR record belongs to the sending server's IP address, not to your sending domain. That distinction trips up a lot of senders who go looking for a PTR record in their own domain's DNS zone and never find one, because it is not there.
What is reverse DNS and how is it different from a normal DNS lookup for cold email?
Reverse DNS is the general term for looking up a domain name from an IP address, using PTR records published under special zones like in-addr.arpa for IPv4. A normal, "forward" DNS lookup does the opposite: given a domain name, it returns an IP address, which is what A and AAAA records are for.
Mail servers use reverse DNS as a sanity check on an unfamiliar connection. An IP address with no PTR record at all, or one that resolves to something generic like a residential ISP's default hostname, reads very differently to a receiving server than one with a PTR record naming a legitimate mail server.
What is forward-confirmed reverse DNS and why do cold email receivers check it?
Forward-confirmed reverse DNS, usually shortened to FCrDNS, is a two-step check. First, look up the PTR record for an IP to get a hostname. Then look up that hostname's own A record to see if it resolves back to the same IP. If it does, the two records confirm each other, which is a stronger signal than either one alone.
Receiving mail servers check this because a PTR record by itself is cheap to fake convincingly, but making the forward lookup match it back requires actually controlling both the reverse zone and the hostname's forward DNS. A cold email sending server that passes FCrDNS is harder to distinguish from legitimate infrastructure, which is part of why some receivers treat a mismatch as a stronger red flag than a missing PTR record on its own.
Who controls the PTR record for a cold email sending IP?
The owner of the IP address controls the PTR record, not the owner of the sending domain, and this is the single most important fact about PTR records for a cold outreach sender. You cannot add or change a PTR record through your domain registrar or your domain's DNS host, because the record does not live in your domain's zone.
If you run your own mail server on a VPS or dedicated server, the hosting provider controls the reverse zone for the IP block. Most providers offer a panel or support request specifically for setting the PTR record on IPs you are assigned. If you send through a shared platform, the IP, and therefore the PTR record, belongs to that platform.
Who sets up the PTR record when sending cold email from Google Workspace or Microsoft 365?
Google and Microsoft set up and manage the PTR records for their own outbound mail server IPs, and there is nothing for a Google Workspace or Microsoft 365 customer to configure on this front. Reddit threads and community documentation discussing this consistently point the same way: the mailbox provider owns the sending infrastructure's reverse DNS, because the IP addresses themselves belong to Google or Microsoft, not to the customer's domain.
This is one of the practical reasons most cold outreach setups run through mainstream mailbox providers rather than self-hosted mail servers. A self-hosted server puts PTR record setup, among several other infrastructure tasks, on the sender. A Google Workspace or Microsoft 365 mailbox removes it entirely, since the provider's own infrastructure already carries correctly configured, FCrDNS-passing reverse DNS for every sending IP.
How do you check if a sending IP has a correct PTR record for cold email?
You check a PTR record with a reverse DNS lookup tool, comparing the hostname it returns against what you expect for that IP, then confirming the forward lookup matches back. For a cold outreach sender on shared mailbox infrastructure, this check is mostly informational, since you cannot act on a bad result yourself; the value is understanding why a deliverability problem might be happening.
- Run a reverse DNS lookup on the sending IP, for instance through our free MX lookup tool.
- Note the hostname the lookup returns, if any.
- Look up that hostname's own A record and confirm it resolves back to the same IP, which is the FCrDNS check.
- If you control the IP yourself, request a PTR record update through your hosting provider. If the IP belongs to your mailbox provider, there is nothing to change on your end.
If cold emails are bouncing or landing in spam and you suspect a reverse DNS issue, our email header analyzer reads the full header trail of a delivered or bounced message. It often shows exactly what a receiving server saw and rejected.
Does a missing PTR record cause cold emails to bounce?
A missing or mismatched PTR record can contribute to a bounce or spam placement, but on mainstream mailbox infrastructure it is rarely the actual cause, because Google and Microsoft's own sending IPs already carry correct reverse DNS. If a cold email from a Google Workspace or Microsoft 365 mailbox bounces with a message referencing reverse DNS or PTR records, the more likely underlying issue is something else in the delivery chain. A misconfigured custom mail route or a self-hosted relay between the mailbox and the recipient is a far more common culprit.
For a self-hosted mail server, a missing PTR record is a much more direct and common cause of outright rejection, since several major receivers will not accept a connection at all from an IP with no reverse DNS entry.
How does Pipefire handle cold email sending infrastructure so PTR records aren't your problem?
Pipefire sets up real mailboxes for every sending domain it configures, which means the sending IPs and their reverse DNS are already handled by the mailbox provider's own infrastructure rather than something you need to request or verify yourself. There is no self-hosted mail server in the setup where a missing or incorrect PTR record could become your problem to fix.
Our sending domain setup covers what gets configured on a new domain: authentication records, mailbox creation and warm-up, none of which requires touching a reverse DNS zone, because that layer sits with the infrastructure the mailboxes run on.
PTR record cold email FAQ
How do I create a PTR record for my cold email domain?
You cannot create one through your domain's DNS, because a PTR record belongs to the IP address, not the domain. If you control the IP directly, request the PTR record through whoever issued the IP, typically a hosting or cloud provider; if you send cold email through Google Workspace or Microsoft 365, the provider already manages this for you.
Why can't I find a PTR record when I look up my cold email sending domain?
Because a PTR record is indexed by IP address, not domain name, so looking up your domain directly will never return one. You need to look up the sending server's IP address specifically, using a reverse DNS lookup tool, not a standard DNS query against the domain.
Does reverse DNS affect cold email deliverability more than SPF or DKIM?
No. SPF, DKIM and DMARC authenticate the sending domain and are the primary signals receivers weigh for cold outreach; reverse DNS is a secondary, supporting signal that mainstream mailbox providers already handle correctly on their own infrastructure. A broken PTR record matters far more for a self-hosted mail server than for mail sent through Google Workspace or Microsoft 365.
What does "no PTR record found" mean in a cold email bounce message?
It means the receiving server performed a reverse DNS lookup on the connecting IP and found no PTR record at all, which some receivers treat as a reason to reject the connection outright. For mainstream mailbox providers this is uncommon since their sending IPs carry reverse DNS by default; it shows up far more often with self-hosted servers or misconfigured VPS mail setups.
Do I need forward-confirmed reverse DNS for every cold email sending IP?
If you control the sending IP directly, FCrDNS is good practice and some receivers do check it, so matching PTR and forward A records is worth setting up. If you send through Google Workspace or Microsoft 365, the provider's own sending infrastructure already passes this check, and it is not something you configure yourself.