Reverse DNS and PTR Records, Explained

The message looked fine. It left your server the way ten thousand messages had left before it: a subject line, a signature, one ordinary sentence about a meeting on Thursday. And then, a second later, it came back. Not delivered. Rejected. And the reason was a string of numbers almost nobody outside a mail room ever reads:

You check the obvious things first. The password is right. The content is clean. Your SPF record is published, your DKIM signature validates. Everything you built is exactly where you left it. And still the mail bounces. Here is the strange part, the part that catches even experienced administrators flat-footed: the thing that rejected your email is a DNS record you have almost certainly never edited. And, stranger still, one you probably don't even control.

“550-5.7.25 The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not match the sending IP. As a policy, Gmail does not accept messages from IPs with missing PTR records.”

— Help! I'm seeing 550-5.7.25 errors at Gmail!, Spam Resource (Al Iverson), December 2025

The Phone Book, Read Backwards

Almost everything you know about DNS runs in one direction. You type a name, and DNS hands back a number: example.com becomes 192.0.2.123. Name in, address out. That is what an A record does, and it is the entire mental model most of us carry around.

But there is a second phone book, and it runs the other way. Number in, name out. Give it 192.0.2.123 and it hands back mail.example.com. This is reverse DNS, and the record that makes it work is the PTR, the “pointer” record, DNS type code 12, described in the foundational specification of the domain name system back in 1987.

That one terse line, from RFC 1035, is where the whole thing begins. The same document explains what these records are for, and it is unusually blunt about it:

“PTR records cause no additional section processing. These RRs are used in special domains to point to some other location in the domain space.”

— RFC 1035, Section 3.3.12, RFC Editor / IETF, 1987

A “special domain.” That is the trick. To look up a name by its address, the designers did something that feels almost like a magician's misdirection: they turned the IP address into a name, wrote it backwards, and stapled it onto a reserved zone called in-addr.arpa. Watch what happens to a single address.

“Host addresses are represented by domain names that have all four labels specified. Thus data for Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR.ARPA.”

— RFC 1035, Section 3.5, RFC Editor / IETF, 1987

Read that address again: 10.2.0.52 becomes 52.0.2.10.in-addr.arpa. The octets are simply reversed and the whole thing is treated like any other hostname. Why backwards? Because DNS names get more specific from right to left (mail.example.com narrows from the com registry down to one host) and IP addresses get more specific from left to right. Flip the address, and the two systems finally point the same way. It is a small, almost invisible piece of cleverness, and the entire edifice of email reputation now rests on it.

Why a Mail Server Trusts a Record You Didn't Write

So why does Gmail care? The answer is a quiet piece of logic that has become one of the most important gatekeepers on the internet. A spammer can forge almost anything: a from-address, a display name, a plausible subject. What a spammer usually cannot forge is the reverse DNS of the machine they are sending from, because that record lives with whoever owns the IP address, not with whoever is renting the bot. So mail servers started asking a deceptively simple question: does this IP admit to being who it claims to be?

Google made the requirement explicit. Their sender guidelines do not hedge:

“The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname.”

— Email sender guidelines, Google

But a PTR record alone is not enough. Google wants the loop to close. The hostname in the PTR must, in turn, have its own forward record pointing back to the very IP that started the conversation. In Google's words, “the sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record,” and “the same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server.” For bulk senders (anyone pushing more than 5,000 messages a day to Gmail), this is not advice. It is the door.

This round-trip check has a name, and it is worth knowing, because it explains almost every reverse-DNS bounce you will ever see. It is called forward-confirmed reverse DNS.

“Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other.”

— Forward-confirmed reverse DNS, Wikipedia

The formal version of the test even has an equation behind it. The email-authentication standard RFC 8601 calls it the “iprev” method, and describes it with the precision of a proof: take the client's IP address, look up the name (or names) it maps to, then look those names back up as addresses.

“If the client peer's IP address is I, the list of names to which I maps (after a 'PTR' query) is the set N, and the union of IP addresses to which each member of N maps (after corresponding 'A' and 'AAAA' queries) is L, then this test is successful if I is an element of L.”

— RFC 8601, Section 3, RFC Editor / IETF, 2019

Strip away the set notation and it is beautifully simple. The address must be able to name itself, and the name must be able to find its way home. Miss either leg, a missing PTR or a forward record that points somewhere else, and you are the 550-5.7.25 at the top of this page.

IPv6: The Same Trick, Thirty-Two Times Over

Everything above was IPv4. IPv6 does exactly the same thing, in exactly the same spirit, but with a lot more digits. Instead of in-addr.arpa, IPv6 reverse lookups live under ip6.arpa, defined in RFC 3596 in October 2003 (it retired the earlier RFC 1886). And instead of reversing four octets, you reverse all thirty-two nibbles (a nibble being a single hexadecimal digit).

“The sequence of nibbles is encoded in reverse order, i.e., the low-order nibble is encoded first, followed by the next low-order nibble and so on.”

— RFC 3596, Section 2.5, RFC Editor / IETF, 2003

The RFC's own worked example shows just how long the resulting name gets. The address 4321:0:1:2:3:4:567:89ab becomes:

Thirty-two single-digit labels, each one a nibble, all in reverse. It looks absurd, but it is the same idea as 52.0.2.10.in-addr.arpa, just stretched to fit a 128-bit address. There is one practical consequence worth filing away: IPv4 reverse zones are delegated on octet (8-bit) boundaries, while IPv6 reverse zones split on nibble (4-bit) boundaries. If you run IPv6 mail, this is where you check that your AAAA record and your PTR agree.

The Record You Request, Not the Record You Set

Now for the reversal that trips up almost everyone. You are used to logging into your DNS host and adding records: an A record here, a TXT record for verification there. So you go looking for the place to add your PTR record, and it isn't there. It isn't there because it was never yours to add.

“Setting up a PTR record is not something you do through your domain registrar. You need to go through the organization that controls your IP address, which is typically your hosting provider, VPS provider, or ISP.”

— What Are Reverse DNS Lookups and PTR Records?, DNSimple

This is the heart of it. Forward DNS (your A, MX, TXT records) belongs to whoever runs your domain's zone. Reverse DNS belongs to whoever owns the block of IP addresses, and that in-addr.arpa zone is delegated down from the regional registries to your ISP or cloud provider. You do not add a PTR the way you add an SPF record; you request one, usually through a provider console or a support ticket. There is, in practice, one authoritative PTR per address, and the person holding the keys is rarely you.

The oldest operational guidance in DNS spelled out the rules of the road decades ago. RFC 1912 is unambiguous:

“For every IP address, there should be a matching PTR record in the in-addr.arpa domain.”

— RFC 1912, Section 2.1, RFC Editor / IETF, 1996

And it anticipated two mistakes people still make. If your server answers on more than one address, the same document warns to “make sure that all IP addresses have a corresponding PTR record (not just the first one).” And whatever the PTR points to had better be a real hostname: PTR records, it says, “must point back to a valid A record, not a alias defined by a CNAME.” A PTR aimed at a CNAME is a classic silent failure.

There is even a workaround for the awkward case where you control fewer than 256 addresses (a block smaller than a /24) and so cannot be handed a clean octet boundary to manage. RFC 2317 describes a way to do “IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses,” using CNAMEs that point into a specially named child zone. It is the exception that proves how rigid the normal rules are.

How to Check Your Reverse DNS

Before you send another byte, look your own IP up the way a mail server will. The commands take seconds.

An Honest Word About What This Proves

It is tempting, once you understand the round trip, to treat it as a stamp of authenticity. It isn't, and the people who built the check are the first to say so. Reverse DNS is a reputation and sanity signal, not cryptographic proof of identity. As the Wikipedia summary puts it, the authentication is “weak,” yet “strong enough that it can be used for whitelisting purposes because spammers and phishers cannot usually by-pass this verification when they use zombie computers for email spoofing.” Even RFC 8601, which formalizes the iprev test, points to guidance recommending that applications avoid leaning on it as a means of authentication or security on its own.

So keep reverse DNS in its proper place. It sits alongside — not instead of — the cryptographic and policy layers of email: SPF, DKIM, and DMARC. Those prove that a message is authorized and unaltered. Reverse DNS just proves that the machine sending it is willing to say its own name out loud, and say it the same way twice. On the modern internet, that turns out to be a surprisingly high bar, high enough that Gmail will slam the door on anyone who can't clear it.

The Bounce, Revisited

Go back to that rejected message. You now know that the 550-5.7.25 was never really about your email at all. It was about a record in a backwards phone book, in a zone your provider controls, that either didn't exist or didn't point home. The fix is rarely in your mail server. It is a request to whoever owns your sending IP: give me a PTR record, point it at a real hostname, and make that hostname resolve back to me. Close the loop. Then the message about Thursday's meeting goes through, and it was never the content that was the problem. It was the address, learning to say its own name.

Sources

1. RFC 1035 — Domain Names: Implementation and Specification — RFC Editor / IETF, 1987. https://www.rfc-editor.org/rfc/rfc1035
2. RFC 1912 — Common DNS Operational and Configuration Errors — RFC Editor / IETF, 1996. https://www.rfc-editor.org/rfc/rfc1912
3. RFC 2317 — Classless IN-ADDR.ARPA delegation — RFC Editor / IETF, 1998. https://www.rfc-editor.org/rfc/rfc2317.html
4. RFC 3596 — DNS Extensions to Support IP Version 6 — RFC Editor / IETF, 2003. https://www.rfc-editor.org/rfc/rfc3596
5. RFC 8601 — Message Header Field for Indicating Message Authentication Status — RFC Editor / IETF, 2019. https://datatracker.ietf.org/doc/html/rfc8601
6. Email sender guidelines — Google. https://support.google.com/a/answer/81126?hl=en
7. Help! I'm seeing 550-5.7.25 errors at Gmail! — Spam Resource (Al Iverson), December 2025. https://www.spamresource.com/2025/12/help-im-seeing-550-5725-errors-at-gmail.html
8. Forward-confirmed reverse DNS — Wikipedia. https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS
9. What Are Reverse DNS Lookups and PTR Records? — DNSimple. https://support.dnsimple.com/articles/reverse-dns-ptr-records/

Related Articles

• A Records in DNS — What They Are and How They Work
• AAAA Records — IPv6 DNS Mapping
• MX Records — Email Routing
• SPF Records — Authorizing Your Senders
• DKIM — Cryptographic Email Signing
• DMARC — Email Authentication Policy