A PTR record (pointer record) is the reverse DNS entry that maps an IP address back to a hostname, the mirror image of the A record that maps a hostname to an IP. For email, it is the record a receiving mail server looks up to answer one question: does the IP that just connected actually claim to be who it says it is? If your sending IP has no PTR record, or the PTR does not line up with forward DNS, mailbox providers like Gmail now treat the connection as untrustworthy and can reject the message outright.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
This matters most for anyone running their own mail server on a static IP, because PTR records live with the owner of the IP address, not in the DNS zone you control for your domain. If you send exclusively through a provider like Google Workspace, Amazon SES, or Mailgun, the PTR is already handled for you on their sending IPs. If you self-host, it is your job to get it right, and as of November 2025 the cost of getting it wrong at Gmail is a permanent bounce.
What reverse DNS actually does
Ordinary (forward) DNS answers "what is the IP for mail.example.com?" by returning an A record (IPv4) or AAAA record (IPv6). Reverse DNS answers the opposite question: "what hostname belongs to 203.0.113.25?" The answer comes from a PTR record.
Reverse DNS uses a special namespace. IPv4 addresses are queried under in-addr.arpa with the octets reversed, so 203.0.113.25 is looked up as 25.113.0.203.in-addr.arpa. IPv6 uses ip6.arpa in nibble-reversed form. You rarely type these by hand, but knowing the format explains why the PTR is delegated to whoever owns the IP block rather than to your domain.
A PTR record for a mail server typically looks like this:
| Lookup | Type | Value |
|---|---|---|
25.113.0.203.in-addr.arpa | PTR | mail.example.com |
mail.example.com | A | 203.0.113.25 |
Notice the two records point at each other. That round trip is the whole point.
Forward-confirmed reverse DNS (FCrDNS)
Mailbox providers do not just check that a PTR record exists. They run forward-confirmed reverse DNS, also called FCrDNS, full-circle reverse DNS, double-reverse DNS, or iprev. It is a two-step trust check:
- Take the connecting IP address and look up its PTR record. Note the hostname it returns.
- Take that hostname and look up its A or AAAA record. Does the result point back to the original IP?
If both directions agree, FCrDNS passes. If the PTR is missing, points to a generic ISP-assigned name (something like 203-0-113-25.dyn.example-isp.net), or the forward lookup does not resolve back to the same IP, FCrDNS fails. A generic PTR that still round-trips will pass the technical check, but it reads as a low-trust residential or dynamic host, which is why a dedicated mail hostname matters.
FCrDNS is deliberately hard to spoof. An attacker can forge a HELO greeting or a From header, but they cannot create a PTR record for an IP block they do not control. That is why receivers weight it so heavily as an identity signal, and why it sits alongside SPF, DKIM, and DMARC in the broader picture of email authentication.
Why mailbox providers require it
For bulk senders, a valid PTR is now a stated requirement rather than a nice-to-have. Google and Yahoo both published sender rules that took effect in February 2024, and Microsoft followed with its own bulk-sender enforcement in 2025. All three expect a sending IP to have valid forward-confirmed reverse DNS. The Google and Yahoo sender requirements list it directly alongside authentication, one-click unsubscribe via RFC 8058, and low spam-complaint rates: Google wants user-reported spam kept under 0.3 percent, and ideally below 0.1 percent, for anyone sending more than 5,000 messages a day.
There is a practical reason behind the rule. Reputation systems track behavior per IP address. A stable, self-identifying hostname on your IP lets receivers attribute reputation to you consistently. An IP with no reverse identity looks like a compromised host, an open relay, or a snowshoe spammer hopping across addresses, so it starts with a trust deficit before the message body is even read.
The Gmail November 2025 tightening
Through 2024 and most of 2025, Gmail largely enforced these rules with warnings and temporary deferrals, so a sender missing a PTR could often still squeak through. That grace period is over. In November 2025 Gmail escalated from soft enforcement to hard rejections, and messages from IPs without valid PTR records now receive a permanent 550 failure instead of a retryable deferral.
The specific bounce you will see is enhanced status code 550 5.7.25, with text indicating the sending IP does not have the required reverse DNS (PTR) record or that it does not resolve. When you get this, the message is not going to be retried into existence; the sending IP itself is the problem, and it has to be fixed at the source.
Where a PTR record lives (and who controls it)
This is the single most common point of confusion, so it is worth stating plainly: you do not set a PTR record in your domain's DNS zone.
- Forward DNS (A, AAAA, MX, TXT, and your SPF and DKIM records) lives with whoever hosts your domain's zone, usually your registrar or DNS provider. If you are unsure who that is, see how to find your DNS host.
- Reverse DNS (the PTR) lives with whoever owns the IP address block. That is your hosting provider, VPS company, cloud platform, or ISP. Reverse DNS for the IP is delegated to them, so only they (or a control panel they expose) can create or change the PTR.
For a VPS or dedicated server, most providers expose a "reverse DNS" or "rDNS" field in their control panel where you enter the hostname yourself. If there is no such field, you open a support ticket and ask them to set the PTR for your IP to your mail hostname. You cannot fix this from your registrar, and no amount of editing your domain zone will produce a PTR.
How to check your PTR record
You can verify reverse DNS from any terminal before you trust it.
dig -x 203.0.113.25 +shortreturns the PTR hostname for an IPv4 address.host 203.0.113.25prints the same thing in a friendlier form.nslookup 203.0.113.25works on systems withoutdig.
To confirm the full circle, take the hostname you got back and run the forward lookup: dig mail.example.com +short. If it returns the same IP you started with, FCrDNS passes. If either command returns nothing, or the two IPs differ, you have a gap to close. Checking your live authentication end to end alongside the PTR is easier with a scanner, and the same signals show up when you read the Authentication-Results header of a delivered message.
How to fix a failing PTR
- Identify your real sending IP. This is the public IP your mail server uses for outbound SMTP, which is not always the same as your inbound or web IP. Check the
Receivedlines of a test message or your server config. - Pick a hostname and set forward DNS first. Create an A record (and AAAA if you send over IPv6) in your domain zone, for example
mail.example.compointing to203.0.113.25. This must exist before the reverse side can round-trip. - Set the PTR at your IP owner. In your host's control panel, set reverse DNS for
203.0.113.25tomail.example.com. If there is no panel option, ask support to do it. - Align your SMTP greeting. Your mail server should announce the same hostname in its
HELO/EHLOgreeting. In Postfix this ismyhostname; other servers call itServerNameor similar. A PTR that does not match the greeting weakens the signal even when FCrDNS technically passes. - Wait for propagation and re-test. Reverse DNS can take from a few minutes to a day. Re-run
dig -xuntil it returns your hostname, then confirm the forward lookup matches.
IPv6 deserves special attention. If your server has an AAAA record and sends over IPv6, that IPv6 address needs its own PTR. Many 550 5.7.25 failures come from an IPv6-enabled server whose IPv4 PTR is correct but whose IPv6 PTR was never set, and Gmail often prefers the IPv6 connection. Either set the IPv6 PTR or disable IPv6 sending.
Frequently asked questions
Do I need a PTR record if I use Google Workspace or a sending service?
No. When you send through Google Workspace, Microsoft 365, Amazon SES, Mailgun, or a similar provider, mail leaves on their IP addresses, and they maintain valid PTR records on those IPs. You only need to worry about PTR when you send directly from a server on an IP you or your host control. Your authentication work in that case is SPF, DKIM, and DMARC, covered in what DNS records do I need for email.
What is the difference between a PTR record and an SPF record?
They validate different things. A PTR record proves the sending IP has a legitimate reverse-DNS identity and lives with the IP owner. SPF is a TXT record in your domain zone that lists which IPs are allowed to send for your domain, and it has its own rules such as a 10 DNS-lookup limit that triggers a PermError when exceeded. You need both; see SPF, DKIM and DMARC explained.
Why does Gmail say my PTR fails when the lookup looks correct?
The usual causes are a mismatch between forward and reverse DNS, a missing IPv6 PTR on a dual-stack server, or DNS that has not finished propagating. Confirm the full circle: dig -x on the IP must return your hostname, and a forward lookup of that hostname must return the same IP. If your server sends over IPv6, check the AAAA address separately, since it needs its own matching PTR.
How long does a PTR record change take to apply?
Most providers apply a reverse DNS change within a few minutes, but it can take up to 24 hours to propagate depending on the TTL on the delegated in-addr.arpa or ip6.arpa zone. Re-run dig -x on your IP periodically until it returns the new hostname, and only then re-test delivery to Gmail.
Reverse DNS is one of the first things a receiver checks and one of the easiest to overlook, because it does not live in your domain zone. Run a free SPFWise scan to confirm your sending setup, from PTR alignment through SPF, DKIM, and DMARC, resolves cleanly before your next campaign leaves the building.