I am reading about setting up SMTP server and almost all articles suggest to ensure that the SMTP server's name has a matching reverse lookup (PTR) entry in DNS. However, When I casually checked the gmail settings, none of its smtp servers have a matching reverse lookup.

$ dig +short gmail.com MX
20 alt2.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.

$ dig +short alt2.gmail-smtp-in.l.google.com.
$ dig +short gmail-smtp-in.l.google.com.
$ dig +short alt4.gmail-smtp-in.l.google.com.
$ dig +short alt1.gmail-smtp-in.l.google.com.
$ dig +short alt3.gmail-smtp-in.l.google.com.
$ dig -x +short

$ dig -x +short
$ dig -x +short
$ dig -x +short
$ dig -x +short
$ dig -x +short

So I am bit confused. Could someone help me understand how reverse lookup is used in SMTP. Certainly I am missing this concept whle I am looking at gmail's settings.


After reading @Jacob's Answer, Here is what I found:

Below lines are from an email metadata that was received from gmail.com:

Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [])
    by mx0a-00273201.pphosted.com with ESMTP id 2edpusg15b-1
    (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)

The PTR records match perfectly:

$ dig +short mail-qt0-f179.google.com
$ dig -x +short

So, as I understand, I was looking at the "MX" record which is not the correct one to check for outgoing. Thanks @HBruijn for detailed explanation.

Also, I find that the email was sent from XXXX@gmail.com email address. However, the outgoing SMTP server is mail-qt0-f179.google.com which is under google.com domain (I was expecting the Outgoing SMTP server should also be in the xxxxx.gmail.com domain).


They do match, google (and most large providers) have an abstraction for load balancing, the destination/ip of gmail-smtp-in.l.google.com. changes depending on your requesting ip, the health of the network, the load, etc.

however the IP address has a forwarder && reverse dns (FCrDNS)

dig gmail-smtp-in.l.google.com. +short 15995 IN     PTR     qg-in-f26.1e100.net.

dig qg-in-f26.1e100.net. +short

However, none of this "matters" for Inbound MX Records, only sending IPs.


MX records are used to direct incoming e-mail to the correct SMTP servers for a certain domain.

There is no requirement for those to have matching reverse DNS records to ensure reliable delivery of incoming email, as far as I know.

The incoming mail servers also need not have any relation to the outgoing SMTP servers that a domain uses to transmit e-mail messages.

It is only for sending email that reliable delivery requires that the hostname used by the server to identify itself with should have matching forward and reverse DNS records.


One of the reasons why having proper PTR records as recommended by RFC 2505 and many other documents is to reduce the likelihood of mail going out through your SMTP server be flagged as SPAM.

Most of the receiving MTAs will use all sort of antispam measures, and one of them is checking if the mail they are receiving comes from an IP address that matches the hostname, and that hostname matches the email receiving host for that domain.

So, lets say your SMTP server is sending an email which has From: user@domain.com in its headers and is addressed to anotheruser@partner.co.uk, when your server connects to the MX host receiving for partner.co.uk it will --among other things-- perform a lookup of the PTR record of the IP address that is connecting to it (your server in this case). If the PTR record of your server resolves properly to mail.domain.com, the lookup for the A record matches also the IP and the MX record for domain.com points also mail.domain.com, chances are the receiving server will whitelist your IP and will not see it as potential SPAM.

In reality, they use much more rules to weight the chances an incoming connection is from a spammer (DNSBLs, Bayesian rules on the content, etc). But this best practice, called Forward confirmed reverse DNS is a good start.

With spammers always finding ways to overcome antispam measures, and the fact that email usage scaled up a lot, companies may have many dynamic servers legitimally handling email for multiple domains. So newer methods of authenticating a valid SMTP transfer are in use now. Take a look at SPF, DKIM, DomainKeys, SenderID, etc.

Going back to your question, the reason Google can somehow break that original rule is that they are using ALL the newer methods, so this old best practice is kind of a minor issue.

Hope this helps!

  • Google cannot break this rule, it's a difference of receiving vs sending. – Jacob Evans Nov 22 '17 at 18:42

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.