Multiple A Records - Followup Question

Reindl Harald h.reindl at
Sun Oct 2 22:28:16 UTC 2016

Am 03.10.2016 um 00:08 schrieb David Ford:
> On 2016-10-02 21:22, Reindl Harald wrote:
>> Am 02.10.2016 um 22:42 schrieb David Ford:
>>> On 2016-10-02 12:59, Reindl Harald wrote:
>>>>> IOW, can a given *IP* appear in more than one A record? I realize
>>>>> that this does have the problem that the reverses would resolve to
>>>>> hostX not
>>>>> test
>>>> on IP should only have on PTR - period
>>>> avoid anything else than PTR/A-matching if the machine is supposed to
>>>> send outbound mail
>>> it is very helpful to have multiple PTR records for an IP on a mail
>>> server so anti-spam engines can accurately make fully verified forward
>>> and reverse lookups not just for DNS but also certificate verification.
>> which is *exactly* what you break with *multiple* PTR records for a
>> single IP - seems you don't understand what
>> really means
> no, it exactly doesn't break. it exactly applies to -every- domain
> served by that mail server with each domain serviced having fully
> verified forward and backward reachable chain regardless of how many A
> or PTR (and even CNAME) records exist in RR answers, each having their
> own domain set in their MX record.

no - a mailserver needs exactly *one* IP address with *one* matching PTR 
record since it's not a webserver serving different document roots and 
hence you need only *one* certificate for TLS while without DANE TLS in 
case of smtp is opportunistic anyways

besides that receiveing mail has nothing to do with the senders MX at 
all, really nothing except sender-verifciation in very rare justified 
cases to not make side attacks to the victims of sender-forging

but it's off-topic here

>>> mail servers that can't correctly emit the right EHLO for outbound email
>>> should remain in the 1990s.
>> yes, and your EHLO matches the A record of your IP
>> which of the multiple PTR's should the receiving server use?
>> guess what: it uses a random one
>> one time it matches your EHLO, the next time not
> PTR lookup of returns all RR for,,
>, where each of these also resolves to it is your
> -client- that determines what to do with each RR after it has received
> the answer. if your MTA or milter software cannot iterate all the RR
> records to find the matching hostname, you should get a better MTA or
> milter.
>> congratulations: you are playing lottery
> you're only playing the lottery with MTAs and anti-spam services that
> are too naive to understand that multiple records can exist in a single
> RR answer and it should utilize all the records.

nonsense - when i reject highly suspect and "" is 
another PTR of this IP the sender is a fool, that's it

go ahead, subscribe on the postfix mailing list abnd explain Wietse that 
his implementation is naive because you know better - i am curious how 
far you get....

>> and yes i had cases where we blocked email because
>> check_reverse_client_hostname_access when the mailadmin did request a
>> PTR and the ISP was too dumb to remove the generic one which ended in
>> some mails hit rules and others not
> the notion of a 1-to-1 relationship between A and PTR is a relic of
> history. the internet is always evolving and sharing of IPs to host
> multiple domains has been around for a long time and increasing
> considerably as people try to stretch IPv4 further while waiting for
> their upstream to provide IPv6. there are a considerable number of
> existing servers that use a many-to-many relationship of A and PTR
> records and it's only going to increase as more customers request their
> IPs resolve to all of their hosted domains.


> the cat and mouse game of spam is always ratcheting upward. as mail
> providers get better at blocking half-assed setups due to spam, sending
> providers improve their configuration to rise above the spammers. with
> the simple fully verified FR of IP/PTR/EHLO, i block more than 87% of
> incoming spam right at the edge. i have very very few false positives.

87% is not very impressive

> many-to-many works, and i support it's use. i also support the adoption
> of MTAs and milters capable of handling modern many-to-many instead of
> breaking because they expect a legacy 1-to-1 or 1-to-many RR

so you are happy to play troublemaker - fine yor *your* setups but don't 
recommend not following best practices to others

More information about the bind-users mailing list