It's an imperfect analogy, as SIP/VoIP services are connection-oriented, whereas email is store-and-forward, but you've got the general idea. Internet email predates SIP by almost twenty years — while it's been tweaked a couple of times over the years, the standard we use today was originally published in RFC 822 back in 1982, whereas SIP didn't come along until RFC 2543 in 1999 — but obviously the SIP addressing borrowed from the email standard that had been in use for years before that.
In a nutshell, however, since email is store-and-forward, retrieval and transfers are separate processes, with separate protocols. POP/IMAP don't need to know anything at all about addresses, as they simply download email into a client. They're also generally irrelevant for webmail, since in those cases you're accessing the mailboxes directly. POP/IMAP don't "process" emails per se, they merely facilitate the transfer of emails from a server-side mailbox and a client such as Apple Mail, Thunderbird, or Outlook.
The protocol that really counts for sending emails around the internet is SMTP, or Simple Mail Transfer Protocol. It's another really old one, first defined in RFC 821, which was basically published alongside the aforementioned RFC 822. This is the protocol used when sending messages from a client like Apple Mail, and also the protocol used when sending messages between mail servers on the internet. Here's a quick overview of how this mail flow works:
- You compose an email message in your mail client of choice, from "you@yourdomain.com" addressed to "somebody@somedomain.com"
- If you're using a local mail client like Apple Mail, this message is sent directly to your provider's server ("yourdomain.com") using the SMTP protocol. If you're using webmail, this is handled internally on the server.
- Once your provider's server receives your message, either via SMTP or a webmail submission, it then places it in an outbound queue on the "yourdomain.com" server.
- The SMTP server for "yourdomain.com" will query the Domain Name Servers (DNS) for an "MX" (Mail eXchanger) record for "somedomain.com" to find out which mail server it's supposed to deliver your message to.
- If it finds an MX record, it then makes a connection directly to that mail server and delivers the message.
- The receiving mail server for "somedomain.com" then checks to see if it has a user named "somebody."
- If "somebody" exists on the "somedomain.com" mail server, then the message is written to the "somebody" mailbox, where it can later be retrieved using POP/IMAP or webmail.
- If "somebody" does not exist on the "somedomain.com" mail server, the message is returned to sender ("bounced") as undeliverable.
Also note that step #6 can be handled in a couple different ways, depending on the receiving mail server:
- Some receiving severs look up the user during the SMTP session, and immediately refuse to accept any mail for mailboxes that don't exist. In this case, the sending server ("yourdomain.com") essentially gets "hung up on" with an error message that says the mailbox doesn't exist. An undeliverable message is generated by the server at "yourdomain.com" and sent back to you. This is how most servers work these days, as it's better not to take responsibility for an undeliverable message. This is the analogous to telling the mailman at the door that "this person doesn't live here" before he finishes handing you an undeliverable letter.
- Some servers, however, will still accept all mail for "somedomain.com" and then figure out later whether it can be delivered or not. In this case, "yourdomain.com" succeeds at delivering the message to "somedomain.com" but when "somedomain.com" looks for a mailbox, it can't find one, so it creates an undeliverable message to "you@yourdomain.com" and sends it back by repeating the same steps above — looking for the MX records for "yourdomain.com" and initiating an SMTP session to send the undeliverable reply back. This is analogous to finding a letter in your mailbox addressed to an unknown person and then having to write "Return to sender" on it and put it back in a public mailbox.
If you think of the domain after the "@" sign as the address of a house or apartment building, and the part before the "@" sign as the name of a person in that building, then you've got the general idea. The postal service generally doesn't care about who lives in the house — they deliver all mail addressed to 123 Anywhere Street ("somedomain.com") to that location. It's up to the people who live in that house to figure out whether the envelopes showing up in their mailbox are actually for them or not.
From Apple's point of view (or really, that of any mail hosting provider), it needs to ensure that the iCloud servers will accept mail for "somedomain.com" and also have the necessary individual accounts setup to match the users who are expecting to receive mail to "@somedomain.com" addresses on the iCloud servers. This is all trivial to do from a configuration perspective — most likely Apple will take care of the first step behind the scenes as soon as you set up your domain with iCloud+ Mail, and the second step whenever you configure your addresses and aliases (which is exactly what happens right now with aliases on the icloud.com/me.com/mac.com domains).
Last edited:
