7

I read in some Mail-Relay explanation that emails can be delivered from the sender's MTA to the recipient's MTA via more MTAs. How does it work (I thought, the sender's MTA simply determines the recipient's MTA's IP address by using DNS and directly sends the email to it, so no other MTA is involved) and what is the benefit of doing so?

reetscav
  • 73
  • 3
  • Find how to view e-mail headers on e-mails you received (may be "view headers", "view source" or other such options depending on what client you use). Then check the headers of multiple e-mails, and count the number of lines starting with "Received:". Each one of those lines is a hop through an MTA. You'll realise that there are often quite a few hops. – jcaron Jul 07 '22 at 08:11

2 Answers2

17

It's VERY common for there to be more than 2 MTAs (1 sender, 1 receiver) in an email transaction. Possible reasons include:

  • Edge MTAs in a large environment. (Edge servers handle sending/receiving external email, while one or more internal servers handle mail storage and client connectivity.)
  • Third-party spam/security solutions. (Which then forward the message on to another MTA.)
  • Forwarders. (Which then forward the message on to another MTA.)

I would bet that multiple MTAs are MORE common that just single MTA configurations nowadays.

longneck
  • 23,082
  • 4
  • 52
  • 86
  • 4
    A particular case of Forwarders that was more common in the early days was relaying between networks with different protocols (e.g. from the Internet to UUCP). – Barmar Jul 06 '22 at 16:31
7

In addition to longnecks answer.

Please also take a look at how Wikipedia explains the MX record and the backup MX record.

A senders mail server will deliver to a backup MX whenever a primary MX can't be reached. The backup MX will accept the mail and hold it in the their queue until the messages either expire or until they can be delivered the primary MX.
This removes the burden of queueing undelivered messages away from the sender and makes the queue managed by the recipient.
Nowadays backup MX records are most likely only necessary for planned maintenance and outages, but in the past it was much more common for systems to be online only intermittently. Domains would often make an agreement with the operators of a mail server with much better connectivity to use their server as the backup (when they couldn't operate their own) or their ISP would provide that as a service. Mail would be queued on the backup MX server (for much longer than most senders did) and whenever the primary MX server came online, delivery of all queued messages would be triggered (with the ETRN command). That would allow sites to run their own on-premise mail server, without being online 24x7 (on an expensive dial up connection).

Rob
  • 1,175
  • 1
  • 7