[avilt]

Does the MX preference distance improve the efficiency of email routing?

In the following example, if I increae the preference value of Host3 to 700 instead of 30, am I going to get any benefit if my objective is to get emails via Host1/Host2 and not Host3.

Current:
-----------------------------------------------
Host1 with MX value 10
Host2 with MX value 20
Host3 with MX value 30

New:
-----------------------------------------------
Host1 with MX value 10
Host2 with MX value 20
Host3 with MX value 700

[tehcamel]

Mx is weighted.
It will try to go to the lowest priority first.
If it can't reach that, it'll go to the next one.

It doesn't really round robin. Increasing the weight to 700 won't make much difference - it'll go to 10, then 20, then go straight to 700

it should already be going to 10 or 20 first anyway...

[cruachan]

I'm sure I've seen posts in the Exchange forum suggesting that MX weighting is not reliable, might be worth a search?

[wullieb1]

Please read this http://en.wikipedia.org/wiki/MX_record with specific reference to this

The preference debate
The SMTP RFC[3] is ambiguous about exactly what kinds of delivery failure must result in re-attempting delivery via more distant MX records (those with higher preference values).
For example, sometimes servers indicate temporary failures, either by explicitly sending a 4xx error or by ending the connection unexpectedly (which must be treated as a 451 error, according to Section 3.8 of the RFC). If there is a temporary failure, should a more distant MX record be attempted, or should the server wait and retry later? According to Section 4.5.4.1:
The sender MUST delay retrying a particular destination after one
attempt has failed.
But when the sender retries later, the RFC is silent about whether the sender should retry the same server that gave the previous temporary error or a more distant MX record. It does say, in Section 5.1:
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds.
It is not specific about what should cause the sender to use a higher-preference MX record, merely that the sender must be able to use higher-preference MX records. Some servers (such as Sendmail and Postfix 2.1 or later[4]) will attempt the next-furthest MX server after some types of temporary delivery failures, such as greeting failures.[5] Other servers (such as qmail and Postfix 2.0 or earlier) will only use more distant MX records if the servers specified in the shortest-distance MX records could not be contacted at all.
Both behaviors are valid, since the RFC is not specific. Re-attempting with more distant MX records makes a lot of sense if the primary MX's failure is considered non-authoritative; that is, if there is an expectation that the message may yet be delivered by the backup MX servers. This is often phrased as "if the alternative is giving up and not delivering the mail, why not try the higher-preference MXs?"[6] However, if the primary MX's failure is considered authoritative (i.e. it is the primary server for a non-arbitrary reason), attempting to deliver to secondary MX servers is not only a waste of time but potentially a waste of expensive resources, depending on the reason why the secondary servers have higher preference values.
The different MX-handling behaviors of email servers (MTAs) often comes up in discussions of nolisting and similar anti-spam strategies that rely on manipulating the MX order and exercising MTA failure handling mechanisms.
Regardless of how one interprets the RFCs there is an advantage to choosing to deliver to higher numbered MX records when receiving a 4xx error from a primary mail server. If the primary server is overloaded or experiencing some other temporary failure the backup server can accept the email and process it. This means the email is delivered faster than waiting to retry the primary server until it recovers. Some front end spam filtering services apply gray listing techniques on only the primary server to discourage spam bot email. Sending servers that retry the higher MX records will be able to deliver their outgoing mail immediately, while servers like qmail will be delayed typically for an hour till the primary server allows it. So servers that retry higher numbered MX records gain a performance advantage.

[Lior_S]

Originally Posted by tehcamel

It doesn't really round robin. Increasing the weight to 700 won't make much difference - it'll go to 10, then 20, then go straight to 700

If you want some kind of round robin, make the priority the same, but increasing the distance in numbers makes no difference..

Host1 with MX value 10
Host2 with MX value 10
Host3 with MX value 30 (700)

Also some spam tactics will go to the highest MX first anyway

[justintoxicated]

I agree with the comments that the distance does not make much difference. I do a lot of domain research and just about every result I've gotten from my main online tool has had priorities of 10 20 30 etc.

Feel free to confirm yourself. There must be a reason a majority of people use this method.

unlocktheinbox.com/dnslookup/mx/