I think it's best they have their own MX record. The only reason I can think of is if one of the A records in a shared MX record is experiencing issues, the second A record on that MX record may not be tried for a while due to caching.
Regards Paul On 1 March 2015 at 22:01, Leon Weber <[email protected]> wrote: > Hi, > > I’m planning to move my mail setup from one primary and one backup MX to > two MXes with equal priority, and one backup MX. > > To achieve that, I have of course two options available for setting up > my MX records: > > (1) example.com. MX 23 primary.example.com. > example.com. MX 42 backup.example.com. > backup.example.com. A/AAAA <address of server a> > backup.example.com. A/AAAA <address of server b> > > (2) example.com. MX 23 primary-a.example.com. > example.com. MX 23 primary-b.example.com. > example.com. MX 42 backup.example.com. > > Now I know both of these setups are possible and should lead to load > distribution between servers a and b, and fallback to the other server if > one is unavailable, or to the backup server if both primary servers are > unavailable. > > I wonder, however, if either option has particular advantages from an > operational perspective, or if they are indeed equal. > > I’ve tried both options in a test environment and played around with > various scenarios (one, two servers being unreachable, etc). With both > options I’ve seen good fallback and load distribution behaviour from > incoming mail servers after having attracted some test traffic. > > Naturally though, my test traffic is a bit limited, so I’d be interested > to hear if you guys have any operational experience that would recommend > either of the options over the other, e.g. if there are broken > implementations out there that will work better with one of the options, > or anything else. Note that although load distribution is nice, I’m > mostly looking for high availability, so I’m most interested to know if > fallback mechanisms work as nice in reality as they do in my test setup. > > Regards, > > -- Leon. > > _______________________________________________ > mailop mailing list > [email protected] > http://chilli.nosignal.org/mailman/listinfo/mailop > _______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop
