Use the trace option in dig to debug delegation path from the root nameservers. A couple of re-runs is usually needed to follow different referals.
For example ip-address of serverfault.com:
dig +trace -x 198.252.206.140
There were several stages of grief that had to be worked through in this question. Let's take a look at each. There will be some ups. There will be some downs. With enough hugs, I think we can get through it safely.
Recently my outgoing messages are failing with an error about a
"missing PTR record". I do have a PTR record setup. However, the
forward lookup for the IP address and the PTR record are not the same.
I saw that Gmail wants the forward and reverse lookup to be the same.
That was not the case for my mail server. I changed the PTR record to
be the same as the forward lookup's IP address but I still have the
same problem with Gmail rejecting that server's mail.
First off, many if not most major mail providers will reject email sent from a host that does not have forward and reverse lookups that resolve to the same host/IP address. Or if they don't outright reject it, it is a serious weight in the overall process of determining if the system will accept the email or not.
Once you've changed it, you need to wait between 24 and 72 hours, as a broad recommendation, before doing anything else and firmly stating "This has not worked." I would be surprised if the error is still seen in Gmail's reject messages after 3 days.
I don't believe waiting for TTL is part of the problem. I've come to
realize popular providers such as Gmail do not necessarily respect
TTL.
It's precisely because many providers appear to not honor TTL that you should wait three days. Many do honor it, however there's still an air of suspicion about exactly when and how that honoring is done.
Wait. Three. Days.
My PTR has been setup for a long time the way it is, and it
always worked. So unless Gmail has implemented a new policy in this
regard, TTL should not be the issue.
Doesn't matter. Any service provider can, at their discretion, change their behavior without notice. I've worked in and around cloud service providers and know all too well the tomfoolery that can go on inside that ubiquitous mist. TTL is most likely your issue.
WAIT.
THREE.
DAYS.
This is a very simple problem. Google has told you what they want to see. You've changed it, and now need to wait the generally accepted amount of time. Once you do, I'm 98% sure that it'll be fixed. The other 2% is willing to charge standard consulting fees to figure it out for you.
Best Answer
To answer your new question first: No, PTRs don't tell you anything about the sender's domain. See below for the explanation.
Now back to your original question:
Receiving mail servers check none, one, many or all of the following:
Receiving mail servers that check if the sending server is also the MX server are badly configured and should be eliminated from the Internet.
Edit: The PTR does absolutely prove nothing about the email domain. It is never meant to prove this. There are thousands of domains hosted at Google, Amazon, AOL and others. But none of them match the hostname or PTR of Google, Amazon, AOL and others. They all have the servernames of the providers. And there is nothing bad about that.
The PTR only proves the identity of the server but not the identity of the hosted domains. Point.
2nd Edit: A good example for a working environment would be