MTA senders (not) respecting MX order

Let's see three examples of MX backups.
A)

dig mx +short +noquestion +noauthority +noqr +nostats +nocmd moreira.dnsalias.net
10 faztek.org.uk.
5 moreira.dnsalias.net.

B)

dig mx +short +noquestion +noauthority +noqr +nostats +nocmd rtp.pt
10 relay.rtp.pt.

C)

dig mx +short +noquestion +noauthority +noqr +nostats +nocmd google.com
10 smtp4.google.com.
10 smtp1.google.com.
10 smtp2.google.com.
10 smtp3.google.com.

In all cases we are using the well known dig command (a powerful utility that superseeds the old-fashioned nslookup, for querying name services -- aka A records, MX backups, NS, SOA, etc). The multiple options adopted allow a tidy, simplified output.
For each host, A B or C, we are querying the MX-backups, or just the respective host MX'es.
There should be no prefix www.

In one email, say man@some-domain.xyz, the domain is identified exactly by 'some-domain.xyz', though it's home page is given by the HTTP URL http://www.some-domain.xyz. The www prefix is given usually for URLs, not for the CNAME of the servers hosting email servers.

In the first case (A): we can see in the first line the value 10, and the given host CNAME. Note all CNAMEs end with exactly one dot. Strictly speaking, the top-level domain is given by this dot. Anyhow, the second line shows the value 5 and another host CNAME. This second host is known usually as the MX-backup, or in other words, the MX server with lowest priority.

In the second case (B): only one value and a CNAME. This means the domain rtp.pt has a single MX server.

In the latter case (C): we see multiple MXes for the same domain, all with same priority.
If you make another query of this well known domain, you will see a different ordering.
That is intended. The well behaved MTAs choose the first in the list if all MXes have the same priority. By rotating the result (round-robin fashion), the name-services provided by this SOA (dns-admin.google.com) are naturally weighting the throughput of email arriving to the referred MXes.

The spammers usually follow opposite rules: in the case of a lower MX, they adopt the lower MX to flood garbage -- presumably the lower MX is more fragile -- so the attackers usually adopt the lower MX in the list. Those are arguments some administrators follow: by choosing a single point of failure (a single MX), eventually with internal immediate service restoring.