5

My understanding is that a typical reverse DNS lookup will compare the SMTP hostname (provided in the EHLO/HELO command) of an incoming connection and verify that it matches the PTR record for the source IP the connection it is coming from. Is that correct?

I've recently heard that it's common for mail providers to require the hostname used in an incoming connection to match an MX entry for the sending domain. This doesn't make sense to me though since the sending organization may have completely different MTAs for outbound.

Mike B
  • 11,871
  • 42
  • 107
  • 168

3 Answers3

6

You're right. It doesn't make sense for exactly the reason you stated. An MX record defines where email goes to, not where it comes from. Anyone using any kind of MX record check to validate incoming email is doing it wrong as far as I'm concerned.

An SPF record defines where email comes from.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
5

I'd argue that it's uncommon for receiving mail systems to check what you're suggesting.

It's not really a case of people requesting a match on the forward and reverse DNS. It's usually a case of checking that there is at least a reverse PTR defined for the source IP address. For instance, AT&T IP addresses don't have any reverse PTR records defined by default.

Beyond that, the DNS lookup is used to discern mail sent from dynamic IP blocks, such as those provisioned by home DSL and broadband providers.

Given the following reverse lookup results:

69.180.133.54
108-80-118-218.lightspeed.sndgca.sbcglobal.net
kiwi.testa.com
  • The first would be blocked more often for not having any defined record.
  • The second would be blocked more often for being associated with a dynamic address assigned by a Broadband provider.
  • The third would work in the majority of cases because its forward and reverse records would be consistent (note, that doesn't mean that it has to have anything to do with the mail domain names).
ewwhite
  • 197,159
  • 92
  • 443
  • 809
3

That's not what it does. It doesn't really care what the hostname is in the HELO/EHLO. Even if this matched a PTR look up, that proves nothing because it could be spoofed (and if you lied in the HELO then you're probably going to lie in your PTR as well, so that would be a doubly useless check.).

What it does do a PTR look up on the client address. It then does an A (or AAAA) look up for the name returned in the PTR record. If this matches then you know that the owner of the DNS zone is also the owner of the IP.

It's then up to the rest of the configuration to act on this status. It's almost never enough to get a blanket OK, but if there is no match it's a good indicator that mail can be refused.

bahamat
  • 6,263
  • 24
  • 28
  • Thanks, this makes sense. I know there's not a hard-set standard available but are there any widely-accepted best practice documentation regarding this? I believe what you're saying but it would be easier for change management purposes if I had some documentation. – Mike B Aug 10 '12 at 23:59
  • Well for one, Postfix has a configuration directive, [reject_unknown_client_hostname](http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname) that outright rejects these mismatches. I'm sure other MTA's do as well. You will be blocked by many mail servers (including mine) if it's not set up right. – bahamat Aug 11 '12 at 00:15