A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP
In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to deliver a message addressed to A.EXAMPLE.ORG. From the answer to its query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.ORG is not one of the MX RRs and all three MXs support SMTP mail (determined from the WKS entries), so none of the MXs are eliminated. The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but is not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not responding, it can try C.EXAMPLE.ORG.
In the second example, the mailer is on B.EXAMPLE.ORG, and is again trying to deliver a message addressed to A.EXAMPLE.ORG. There are once again three MX RRs for A.EXAMPLE.ORG, but in this case the mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG, and can only try delivery to A.EXAMPLE.ORG.
In the third example, consider a mailer on A.EXAMPLE.ORG trying to deliver a message to D.EXAMPLE.ORG. In this case there are only two MX RRs, both with the same preference value. Either MX will accept messages for D.EXAMPLE.ORG. The mailer should try one MX first (which one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable), and if that delivery fails should try the other MX (e.g. C.EXAMPLE.ORG).