Search for TLSA RRs at rname and failing that qname, use whichever
was found as the TLSA base domain for certificate matching.

When we find a DNSSEC validated MX RRset, and the initial next-hop
domain is a CNAME, include both the initial and final (the one with
the actual MX RRs) domains in the list of valid server certificate
names.

When we find no MX records, then the initial next-hop domain is
obtained securely from the recipient domain or transport next-hop.
Without MX records, this is a destination hostname, so we should
generally do a TLSA lookup.  If however the address lookup yields
an insecure result, and its rname is equal to its qname (no CNAMEs),
we reasonably assume that the its child "_port._tcp" sub-domain is
likewise insecure (security here would require DLV just for this
sub-domain).  This allows us to skip futile TLSA queries for most
non-MX destinations (those that are in insecure zones and are not
CNAMEs).  This heuristic can be disabled by setting the new main.cf
parameter smtp_tls_force_insecure_host_tlsa_lookup to "yes", the
default is "no".

Finally, with MX hostnames, if the MX RRset is secure, we look for
TLSA RRs at the qname only when the MX host is an alias with an
insecure rname.  If both the qname and the rname are secure, as
before we prefer the rname, but when nothing is found there, fall
back to the qname.
Documentation rebuild