A PTR record (reverse DNS) maps a sending IP address back to a hostname. Gmail, Microsoft, and Yahoo all require valid PTR records for bulk senders in 2026, and missing or misconfigured records are one of the single most common causes of legitimate email being rejected at the SMTP layer. PTR records are managed by whoever owns the IP block, which is typically your VPS or cloud provider, not your domain registrar.
In mid-2025, Google added SMTP rejection reporting to DMARC aggregate reports. When deliverability analysts reviewed this data at scale, they found something striking: a significant percentage of legitimate business email was being rejected because sending infrastructure had misconfigured or missing reverse DNS records. Emails that passed SPF, had valid DKIM signatures, and carried aligned DMARC policies were still bouncing at the connection layer, before any content filtering even started.
If you are reading this because your email is bouncing mysteriously, this is probably why. PTR records sit below every other layer of email authentication in the stack. When they break, nothing else matters.
What Is a PTR Record and Why It Matters
A PTR (pointer) record, also called a reverse DNS record, maps an IP address back to a hostname. Forward DNS answers the question "what IP address hosts this domain?" Reverse DNS answers the opposite: "what domain owns this IP?"
When a receiving mail server sees an incoming SMTP connection, one of the first things it does is look at the sending IP address and perform a reverse DNS lookup. If no PTR record exists, or if the PTR record resolves to something generic like ec2-203-0-113-50.compute-1.amazonaws.com, the receiving server treats the sender with suspicion. If the PTR record exists and maps cleanly to a hostname that itself resolves back to the same IP (a match called Forward-Confirmed Reverse DNS, or FCrDNS), the receiver treats the sender as a legitimate, accountable operator of that IP.
The check happens in milliseconds, silently, on every inbound connection. Most senders never think about it until something breaks.
Approximately 80% of production spam filters perform reverse DNS checks before any content analysis. Without a valid PTR record, your email is evaluated as "probably spam" before your subject line is ever read.
Why Gmail, Microsoft, and Yahoo Now Require It
PTR records have always mattered, but enforcement has dramatically tightened. Here is the current state across the three major mailbox providers.
Gmail has required valid forward and reverse DNS for all senders since February 2024, and enforcement escalated in November 2025 from spam foldering to outright SMTP rejection. Gmail's published rejection codes include 421 4.7.0 and 550 5.7.1 with messages that explicitly reference rDNS failures.
Microsoft joined in May 2025 with similar requirements for Outlook.com and Hotmail, reaching substantially tightened enforcement by late 2025. Microsoft also retired legacy authentication during this period, compounding the disruption for unprepared senders.
Yahoo requires meaningful, non-generic PTR records for all sending IPs as part of its bulk sender policy. Yahoo specifically notes that generic provider-assigned hostnames (like default cloud provider naming patterns) do not satisfy the requirement.
The shift from "recommended best practice" to "mandatory at enforcement" happened quietly enough that many senders did not notice. The result is the email deliverability crisis of 2026: legitimate business mail failing at scale while technically sophisticated phishing campaigns slip through filters.
How Reverse DNS Actually Works
Understanding PTR requires a short detour through how DNS is structured. Forward DNS records live in your domain's zone (for example, mail.example.com has an A record in the example.com zone). Reverse DNS records live in a completely different namespace under in-addr.arpa (for IPv4) or ip6.arpa (for IPv6).
When a receiver looks up the PTR for 203.0.113.50, it actually queries 50.113.0.203.in-addr.arpa (the octets reversed and appended to the ARPA zone). Whoever controls that reverse zone controls the PTR record. Crucially, that is almost never the owner of the domain being sent from.
Who Owns the PTR Record
PTR records are tied to IP ownership, not domain ownership. The entity that owns the IP address block controls the reverse zone. In practice this means:
- If you run mail from a VPS (DigitalOcean, Vultr, Hetzner, Linode): Your VPS provider controls the PTR, and most offer a self-service panel to set it.
- If you run mail from AWS: You need an Elastic IP and then a support request to configure the PTR (or a PowerShell cmdlet for Azure-assigned IPs).
- If you run mail from a shared host: The PTR is pre-set to the host's generic hostname and you cannot change it.
- If you use an ESP: Your ESP controls the PTR for its sending IPs. You inherit whatever they configure.
This split between domain ownership and IP ownership is the source of most PTR misconfiguration. Domain administrators assume PTR is "in DNS" and try to add it to their zone. It does not work, the record never resolves, and mail continues to bounce.
Forward-Confirmed Reverse DNS (FCrDNS)
A valid PTR record alone is not enough. Receivers perform Forward-Confirmed Reverse DNS, which means they check that the PTR and forward A record agree.
The sequence is:
- Receiving server sees an inbound connection from IP
203.0.113.50. - Server queries the PTR for that IP and gets back
mail.example.com. - Server then queries the A record for
mail.example.comand expects to get back203.0.113.50. - If both resolve to each other, FCrDNS passes. If not, the mail is flagged as suspicious or rejected.
Both directions must match. Setting a PTR without creating the corresponding A record, or setting an A record without updating the PTR, both cause FCrDNS failures. The HELO/EHLO hostname your mail server advertises should also match the PTR for consistency. This is why HELO/EHLO configuration matters so much for deliverability.
How to Set Up PTR Records: Step by Step
Step 1: Identify Your Sending IP
From the server that will send email, run:
curl ifconfig.meOr:
dig +short myip.opendns.com @resolver1.opendns.comRecord this IP. If you are using a cloud provider, make sure this is a static/elastic IP. Dynamic IPs cannot have stable PTR records and are not suitable for email sending.
Step 2: Create the Forward A Record
In your domain's DNS, create an A record that points your chosen mail hostname at your sending IP. A common convention is mail.example.com:
mail.example.com. IN A 203.0.113.50Wait for propagation. Verify with:
dig +short mail.example.com
; should return 203.0.113.50Step 3: Create the Reverse PTR Record
This step varies by provider. Common paths:
- DigitalOcean: The PTR is automatically set from the droplet name. Rename the droplet to
mail.example.comand wait for propagation. - Vultr: Control Panel > Instance > Settings > IPv4 > Reverse DNS. Enter your hostname.
- Hetzner: Cloud Console > Server > Networking > Reverse DNS. Enter your hostname.
- Linode: Linodes > Network > Reverse DNS. Enter your hostname.
- AWS EC2: Allocate an Elastic IP, associate it, then submit a support request to set the reverse DNS. Alternatively use the AWS CLI:
aws ec2 modify-address-attribute --allocation-id eipalloc-xxx --domain-name mail.example.com - Azure: Use the PowerShell cmdlet
Set-AzPublicIpAddresswith the-ReverseFqdnparameter. - Google Cloud: Cloud Console > VPC Network > External IP > Edit > Public DNS PTR record.
Important: Some cloud providers require that your forward A record already resolves to the IP before they will let you set the PTR. Always complete Step 2 and wait for propagation before attempting Step 3.
Step 4: Verify FCrDNS
Confirm both directions resolve correctly:
dig +short mail.example.com
; returns 203.0.113.50
dig -x 203.0.113.50 +short
; returns mail.example.com.If either side is wrong, fix it before sending any production mail. You can also use our reverse DNS checker tool to verify externally.
Step 5: Align Your SMTP HELO/EHLO
Configure your mail server (Postfix, Exim, Sendmail, or your ESP's settings) to advertise mail.example.com in its HELO/EHLO banner. If your server says "HELO localhost" or "HELO someinternalname" but your PTR says mail.example.com, some receivers will flag the inconsistency.
In Postfix, this is the myhostname and smtp_helo_name directive:
myhostname = mail.example.com
smtp_helo_name = mail.example.comCommon PTR Mistakes That Break Deliverability
Leaving the Generic Provider Hostname
This is the single most common mistake. Your VPS boots with a PTR like ec2-203-0-113-50.compute-1.amazonaws.com or v2202301123456789.megasrv.de. These are technically valid PTR records, and FCrDNS may even pass, but Yahoo and many other receivers specifically penalize generic provider hostnames. Gmail accepts them but ranks them lower. Always replace with a meaningful hostname under your own domain.
Forward and Reverse Disagreeing
A PTR that points to mail.example.com but no A record pointing mail.example.com back to the IP. Or an A record that was updated when the server moved but the PTR was never changed. FCrDNS fails and your mail gets deferred or rejected. Always check both directions after any infrastructure change.
Multiple PTR Records for One IP
Adding multiple PTR records for a single IP does not make you look more credible. Instead, the receiver may get a random one on each query, the A record may not match that random result, and FCrDNS will fail intermittently. Each IP should have exactly one PTR.
Missing IPv6 PTR Records
If your mail server sends over IPv6 (many modern servers do by default), you need a separate PTR record in the ip6.arpa zone for your IPv6 address. Gmail in particular rejects IPv6 mail without a valid IPv6 PTR. Many senders configure IPv4 reverse DNS correctly, never touch IPv6, and then see mysterious rejections from Gmail only. The fix is either to disable IPv6 outbound or to configure proper IPv6 PTR records with your provider.
Not all VPS providers delegate IPv6 reverse zones to customers, and some do not populate PTR records for assigned IPv6 ranges at all. If your provider cannot give you IPv6 PTR control, disable IPv6 on outbound SMTP with the Postfix directive inet_protocols = ipv4 rather than sending with broken IPv6 reverse DNS.
Troubleshooting PTR Issues
If mail is bouncing and you suspect PTR is the cause, work through these checks in order:
- Check the bounce message. Gmail rejections include references to rDNS failures in the message body. If you see "IP not in DNS," "no PTR record," or "does not have any rDNS entries," PTR is definitively the cause.
- Verify PTR resolves at all.
dig -x YOUR_IP +short. If the output is empty, no PTR exists. - Verify forward A record resolves.
dig +short PTR_HOSTNAME. Should match the sending IP. - Test from multiple resolvers.
dig -x YOUR_IP @8.8.8.8 +shortanddig -x YOUR_IP @1.1.1.1 +shortshould agree. Inconsistent results indicate zone delegation problems. - Check DNS propagation. PTR changes can take several hours to propagate globally. Wait before concluding that a change did not take effect.
- Check your ESP if you use one. Your ESP controls the PTR for its sending IPs. If you are on a shared IP and one of the pool's PTRs is broken, you need to contact support.
PTR on Shared vs Dedicated IPs
On a shared IP at a reputable ESP, PTR is already configured and you cannot (and should not try to) change it. The ESP maintains the PTR, ensures it matches their naming convention, and handles IPv6 configuration. Your job is simply to pick an ESP that does this competently.
On a dedicated IP, whether from an ESP or self-hosted, you typically get some control over the PTR. At an ESP, you usually specify the hostname you want and they configure it. Self-hosted requires the steps above. Custom PTR on a dedicated IP is one of the small but real reasons to pay for a dedicated IP: you can brand the hostname (mail.yourdomain.com rather than dedicatedip-123.espname.com), which improves trust signals.
Ongoing Monitoring
PTR is not set-and-forget. DNS can be accidentally changed during infrastructure migrations, zone delegations can expire, and cloud providers occasionally reassign IPs. Monitor FCrDNS continuously and alert on failures.
Simple monitoring approaches:
- A cron job that runs
dig -xanddigagainst your sending IP every hour and alerts if they stop matching. - A deliverability monitoring service that includes PTR/FCrDNS checks in its regular scans.
- Subscription to DMARC aggregate reports so you can see receiver-side SMTP rejection data. Google added this in mid-2025 and it is the fastest way to catch PTR problems from the receiver's perspective.
Frequently Asked Questions
No. PTR records are controlled by the owner of the IP address block, which is your VPS provider, cloud provider, or ISP, not your domain registrar. Your registrar manages forward DNS for your domain, which is different. This is the most common misconception that causes PTR setup to fail.
Technically yes, but in 2026 your deliverability will be catastrophic. Gmail, Microsoft, and Yahoo all reject or heavily penalize mail from IPs without valid PTR records. Even if your mail is technically delivered, it will land in spam folders and damage your Sender Reputation over time.
They are essentially the same thing. rDNS (reverse DNS) is the process of looking up a hostname from an IP address. A PTR (pointer) record is the specific DNS record type that makes reverse DNS possible. When people say "set up reverse DNS," they mean "create a PTR record."
PTR propagation typically takes 1-4 hours but can take up to 24-48 hours depending on your provider and the TTL of existing records. Always wait for full propagation before testing mail delivery, and check from multiple external resolvers before concluding that a change has fully taken effect.
Yes, but the ESP handles it for you. Your ESP controls the PTR for its own sending IPs, and reputable providers keep these configured correctly. You do not need to do anything manually. However, if you are on a dedicated IP, you can often request a branded PTR hostname under your own domain for stronger trust signals.