Does FCRDNS need the RDNS to be the same hostname than the first forward query?

allo asked:

Does forward confirmed reverse dns (fcrdns) only lookup ip to hostname and then hostname to ip or does it compare to the first hostname as well (especially in spam filtering)?

Let’s say i have these records:

  • A reverse.somedomain: 127.0.0.1
  • A mail.somedomain: 127.0.0.1
  • A mail.mailserverdomain: 127.0.0.1
  • PTR 127.0.0.1: reverse.somedomain

A MTA tries to verify the RDNS of the host and resolves mail.mailserverdomain to 127.0.0.1, then reverse 127.0.0.1 to reverse.somedomain, and then forward reverse.somedomain to 127.0.0.1. Will this be a valid FCRDNS or does the PTR record need to point to the name given in the HELO command (how the mailserver identifies itself)?

The question boils down to the question, if FCRNDS uses two or three queries, so the sequence is either:

  • Got HELO mail.senderdomain
  • Resolve mail.senderdomain to the IP.
  • Resolve connecting IP to hostname.senderdomain

FAIL: hostname.senderdomain != mail.senderdomain

or

  • Got HELO mail.senderdomain
  • Resolve mail.senderdomain to the IP
  • Resolve IP to hostname.senderdomain
  • Resolve hostname.senderdomain to the same IP

SUCCESS: hostname.senderdomain matches the connecting ip and vice versa.

As a useful check needs to confirm the HELO hostname against the ip (else my mailserver could claim in HELO to be google), there will be a forward lookup, which is compared against the connecting ip.
Then the next step is the reverse lookup, giving a hostname of the connecting ip. Now the shorter sequence would compare the hostnames, while the longer does another forward lookup and compares the ips.

If the first sequence is used, this would mean, that using functional hostnames like mail.domain in the mailserver configuration while using hostnames which identify a host in the rDNS like server123.domain would get your message flagged as possible spam.

My answer:


Actually neither.

FCRDNS stands for “Forward Confirmed Reverse DNS”.

How this works is that, first, the PTR record of the connecting IP address is looked up. If it hasn’t got a PTR record, then the check instantly fails. A mail server with this feature on will then reject the connection, such as this rejection taken from my own mail server:

Sep 18 02:48:10 grummle postfix/smtpd[16577]: NOQUEUE: reject: RCPT from unknown[204.51.178.49]: 450 4.7.1 Client host rejected: cannot find your hostname, [204.51.178.49]; from=<sent19274@eachbuyermail.net> to=<me@example.com> proto=ESMTP helo=<smtp49.rsend1.com>

Because 204.51.178.49 has no PTR record, the reverse DNS check fails.

The second step is to take the hostname that was returned, and look up its IP address. That IP address must match the IP address that made the connection to the server. This is what forward confirmed means. If it does not, then again we reject the connection. (So few make it this far that I don’t even have an example in the last week’s worth of logs.)


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.