Normally in a email client you need to configure an SMTP server to use to send mails. When you send a mail, your configured SMTP server simply resolve the domain after the @at in the email address of the recipient with a DNS request of type MX. The DNS will answer with the address of the mail exchanger SMTP server of the recipient's mail provider, and your SMTP server will forward your mail to it.

My question is: why this is not done directly by the mail client? It is nothing special: it is just a DNS mx request and the protocol do deal directly with the mail exchanger of the recipient provider is alaways SMTP.

If it were so, the mail could go directly to the right server: it should be faster and avoid useless traffic.

May this be due to the fact that maybe the recipient's SMTP server could be down for some reason or too busy to process the mail when you send it, and that therefore the advantage of use our personal SMTP server is that it takes care to try again to send the mail at regular intervals?

This is the only reason I see: actually it would be not so practical if this would be responsibility of the mail client, since maybe the user close it or shutdown the computer.

If this is the only reason: does it happen so often that an SMTP server is unable to process an email immediately?

  • 1
    Why because its faster to have the actual server that is sending the email to forward the data to the recipient's server.
    – Ramhound
    May 15, 2014 at 13:00
  • 1
    Why faster? You are adding an hop, a possible bottleneck, in the best case the time required is the same, but adding a hop in the route of the mail in my opinion is very likely to require an higher amount of time
    – WoDoSc
    May 15, 2014 at 13:02
  • Besides you dynamic IP address is likely to be blacklisted for SPAM. So the target SMTP server (if properly configure) is going to reject your mail.
    – drkblog
    May 15, 2014 at 13:22
  • 1
    @drk.com.ar Ok I See your point, but if your IP is in a black list, 'conceptually' it should be rejected by any server, i.e. including your SMTP server and not only by the recipient SMTP, so this is a related problem but I don't see that is the main reason.
    – WoDoSc
    May 15, 2014 at 13:26
  • 1
    Usually you have authentication in your SMTP server. And typically you are going to use submission port 587 instead of 25 for sending mail.
    – drkblog
    May 15, 2014 at 13:44

4 Answers 4


One possible reason is that the sender might simply be unable to reach the recipient's mail server directly.

In the early days of email & SMTP, you had more than just Internet – you had Bitnet; UUCPnet/Usenet; Berknet; MILNET; DECnet; etc. all using incompatible protocols. A domain like sri-unix.uucp might not have had an IP address in DNS – only a MX record pointing to a gateway (a SMTP server that also had UUCP links).

These days, a similar situation is with communications between IPv4-only and IPv6-only hosts (even though the latter are somewhat rare).

Besides, the networks weren't exactly reliable (and still aren't) – you wouldn't want to stare at a "Recipient's mail server is unreachable, please wait" for half an hour, when you could just give the message to a sendmail running 24/7 on the same computer that you were composing the message on, and continue with work.

Bonus: some really weird "From:" addresses I've seen on OldUse.Net:

  • UCBVAX.@[email protected]@RAND-RELAY

  • farber%udel-eecis1.udeecis@[email protected]

  • notes@CSvax:Pucc-H:pur-phy.UUCP

  • utzoo!linus!security!genrad!decvax!harpo!floyd!whuxlb!pyuxll!abnjh!u1100a!pyuxn!pyuxi!mhuxm!mhuxd!mhuxa!houxm!hocda!spanky!burl!akgua!emory!sb6!sb1!ll1!otuxa!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!mcewan

  • I am hardly an email/SMTP expert, but I also think the idea is when you send a mail to [email protected], you are trying to send it to the mail server responsible for the whole domain, i.e. the one in its DNS MX records. So then that mail server can route according to the account name or simply everyone in the domain can use that domain-wide mail server. This allows accounts to be made and checked without each account needing to be associated to a machine or unique domain name, supporting mobile use and all that.
    – LawrenceC
    May 15, 2014 at 14:28

drk.com.ar in the comments has it right.

If you have a static IP from your ISP you can host your own SMTP locally however you like and have that process mail, thats fine. Then if you abuse it spamhause and co will blacklist you and you'll be totally ignored.

With dynamic IPs this doesnt work, they cant block your IP as you can change it within 60 seconds or so. So in this case your ISP has the responsibility to filter your outbound mail. You forward all mail to their SMTP server which then routes it, and if you start abusing it their lease records will know exactly who it came from and can react accordingly.

Interestingly, we had a problem with this a few months back where our ISPs parent company Cello didnt manage their SMTP server properly and some of the cluster got blocked as spammers leading to intermittent spamblocks on the receiving end.

Hope this helps.

  • I don't see: basically you are saying that the use of your provider SMTP (instead of directly the recipient SMTP) is to try to block spammers, but spammers actually CAN use the recipient SMTP (and maybe actually they do), and if the IP is blacklisted then they can easily change it. Even worst this kind of infrastructure (route an email through different SMTP) can be used to spam even more, because if a spammer has or find an SMTP which accept its mail, it can be used as a 'proxy' (if the SMTP hide the original IP address) to spam mail to another SMTP that instead has blocked the IP.
    – WoDoSc
    May 15, 2014 at 13:59
  • I dont know enough to say for sure here but AFAIK mosts ISPs SMTP servers are connectable from external IPs but will refuse to send unauthenticated mail from IPs that arent their own. Sure there are probably loads of "open" SMTP servers that'll take mail from any host but they'll get blacklisted very quickly and at that point the problem stops being the ISPs responsibility.
    – Linef4ult
    May 15, 2014 at 14:43
  • There are 'open' SMTP (that accept mail from any IP) and others that requires authentication with user/pass or that works only with IP they own, as you said. But anyway, an SMTP server MUST ALWAYS accept mail from ANY IP, if the mail recipient is one of its customer. Otherwise it does not make sense, noboy would be able to receive any mail.
    – WoDoSc
    May 15, 2014 at 14:47
  • They accept mail from any Mailserver, not any client. I dont know the ins and outs of SMTP here, its all MTAs but Im assuming there is a difference in client to server and server to sever. If you run a local mailsever and your ISP doesnt block 25 it should work just fine AFAIK.
    – Linef4ult
    May 15, 2014 at 15:16
  • I'm not sure but the protocol between client-server and server-server should be always SMTP, so the same. And even in case they it is not perfectly the same protocol, I don't see any problem to implement the same functionality inside the mail client, instead to run a local smtp. Anyway, directly with the client, or with a local SMTP the question does not change, why involve another additional external SMTP server.
    – WoDoSc
    May 15, 2014 at 15:21

If this is the only reason: does it happen so often that an SMTP server is unable to process an email immediately?

It happens, especially when the SMTP server is maintained by a small organization.

But besides being truly unable to process the incoming mail, sometimes it could but doesn't want to. Two examples that come to mind:

  1. The servers that use Grey Listing reject the first attempts from unknown senders with 4xx errors in a systematic way, on purpose, as a technique against spammers.

  2. Some mail providers use throttling against their own customers, responding with 4xx errors when too many mails are sent per unit of time from the same IP address or account. This can prevent the customer to spam, whether intentionally (small business sending its newsletter) or not (as a victim of an infection). I've recently seen GMail doing this for not even one hundred messages per day and from a paying account, the SMTP message being ...mail sent from your IP address has been temporarily rate limited...

There is also the case of a transient DNS failure for the target MX.

It's more practical to have a first SMTP hop to deal with all this, rather than leaving it to the mail client.


The actual server might be down. So you need your server for retrying.

That is why sometimes you get "This email did not reach the recipient. Will retry shortly. There is nothing you need to do about this."

And eventually you get "Did not reach recipient. This failure is permanent."

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .