If Apple partners with a company will whomever makes the decision have more intelligence and savvy than the one who chose Goldman Sachs for the Apple Card operation? 
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iCloud+ to Let iCloud Mail Users Personalize Their Email Domain Name
- Thread starter MacRumors
- Start date
- Sort by reaction score
Microsoft partnered with GoDaddy for about two years to offer custom domain names for Outlook.com Premium users, however they forced users to register their domains through GoDaddy to provide this service. Several people tried to hack around it, with mixed results, but in the grand scheme of things, it was just a big mess. You can read about it more in this big thread on Microsoft's Community forums.
It was Microsoft's attempt to make things simple, but in typical Microsoft fashion, it just made things a lot more complicated than they needed to be. It was a weird and convoluted partnership with GoDaddy as well, as you couldn't just simply use an existing GoDaddy domain — you had to register it and tie it to your Microsoft Live account in such a way as to guarantee that Microsoft could validate it directly — not just by looking at the MX records, but effectively guaranteeing that you couldn't easily change them and break things.
The good news is that it paints a really great picture of what not to do — although I don't imagine Apple would make the same mistakes that Microsoft made in the first place.
Yeah, I'm sure we're all only going on anecdotal information from our own circles, but I can't think of anybody I know who cares enough about a custom domain to have already jumped through the hoops of setting one up who doesn't also want more flexibility when it comes to things like aliases and more advanced filtering.
I'm not saying that there aren't more people who would like custom domains, just that it's traditionally been so difficult to deal with that most non-technical people don't bother, and most technical people consider iCloud to be inadequate.
This is why I think what Apple is doing here is a great thing, but also why I think that Apple will provide it as a simple turnkey solution that's accessible to the majority of iCloud users, not just the tech-savvy ones.
Yeah, and that's why I use Fastmail — and generally avoid its web interface. It works flawlessly with Apple's Mail apps on both macOS and iOS, and even supports full push notifications far more effectively than iCloud does.
Likewise, Fastmail allows for hundreds of aliases, iCloud Mail allows for three — although the new Hide My Email feature may take care of what many people need aliases for.
That said, Apple may very well be putting more into iCloud+ Mail. The beta iCloud site already shows that they've refreshed the design of the web interface, and while the Rules section is missing entirely right now, I'm sure that will make a return, and may even be a sign that more advanced rules are on their way.
Jesus. Ok. That sounds like exactly the sort of thing I mean that would keep the majority of the potential user base for this feature, from using it.
This bit I don't quite get. I use literally one alias, and combine that with the + operator to create unique addresses.
I don't quite understand the use case for tens or hundreds of specifically configured aliases?
I can see a theoretical benefit to better filtering/actions/rules. Stuff that you can manage from a real app, but have it applied to the mailbox on the server would be nice I guess, but even then - I long ago (even when using a client provided gmail account) gave up on automating stuff in that fashion.
The one thing I'd probably actually use that I don't have now, is smart mailboxes that sync to iPhone/iPad.
Yeah, I do the same — if even that — in terms of simply separating addresses. That said, I do use aliases for a few other things that are a bit more unique or advanced that most would want. For instance, I've set up an alias for "(mydaughter'sname)parents@mydomain.com" that goes to both me and her mother. This makes it easier to handle communications from school, medical/dental appointments, and extra-curricular activities.
Forwarding rules could handle this, of course, but that gets messier — especially since it seems that, while plus addresses work great for things like newsletters and other online services, they confuse many normal humans.
Heh, I'm mostly in the same boat there. At one time I had crafted a sophisticated set of Sieve rules on Fastmail that would filter all sorts of low-priority things into subfolders, but honestly I prefer that almost everything land in my inbox these days. It's easier than hopping between multiple folders.
That said, one thing that iCloud Mail currently lacks is an ability to flag a message based on a rule. Apple Mail can do that on the Mac, of course, but the lack of any rule support on the iPhone and iPad makes that a non-starter since I use a MacBook, which won't necessary be sitting on at home all the time. It also lacks more advanced filtering criteria like searching the body of a message or identifying attachments.
I've never liked how opaque the spam filtering is in iCloud Mail. I haven't used it as a primary email address in years, so maybe it's gotten better, but in the past it always seemed to be a bit off, and there was never an easy way to figure out exactly why.
So I can use any domain name that I want? And Apple will make it work somehow? What if the domain name is already taken? Can I, for example, make my e-mail address iphoneguy@9to5Mac.com?
The short answer is no. An entire domain is registered to a person or organization, so you would have to find one that's not already owned by somebody else and register it for yourself. At that point, you "own" the domain, so anything that ends in "@yourdomain.com" gets delivered to whatever mail servers you choose for your domain. At that point, it's up to the mail server to decide what to do with it.
In the case of what seems like it might be happening with iCloud Mail (and to be fair, we don't know for sure yet), you would buy a domain of your choice — much like buying a vanity license plate for your car — and then you'd point the whole thing to Apple's iCloud servers, and assign it to your iCloud account. Any and all mail sent to anybody at "@yourpersonaldomain.com" would be delivered to Apple's iCloud servers, but anything that's doesn't match your iCloud account name would be rejected as undeliverable.
In the same manner, if you sent an email to iphoneguy@9to5Mac.com, that would be delivered to mail servers assigned by 9to5Mac. If they had an account there named "iphoneguy" that person would get the email. Otherwise it would be bounced as undeliverable.
Good question. From a DNS resolution perspective, the domain is the key wan routing element. To the left of that (routable) domain allows quite a bit of freedom. the limitation is down to the quantity of the alphanumeric characters and delimiters(a period or @ sign). Example: (Who_I_am_whetever_i_want.
[@ or .]<this is the sub domain name>.<this is the domain.com>)
The @ indicates a URI (such as mail user or SIP user) while the . indicates essentially an FQDN. The @ delimiter will put more limits to what you can do to the left of it.
How that long winded explanation applies whatsoever to POP/other mail server protocols? I don’t know 😀.
Last edited:
This is an excellent point. Having a single ID(uri) that is used for all logins is A+ for ‘ease of use’.
I’m looking forward to see what can be done with personalizing the domain (and with the VPN feature). Hopefully it’s a good roll out.
I just secured a new domain name for myself in anticipation of this Apple news. I didn’t sign up for any hosting of web or email or anything. Just the Domain. How does one "point the whole thing" as you say to Apple? Or do you think Apple would do this for us folks that don’t have a clue?
One would expect Apple will provide us with easy to follow instructions but if it is anything like the communications about the lossless and Atmos features, it could be a real mess.
A couple of years ago I created a domain with a local firm and then tied it to my ProtonMail account. Proton's instructions were very easy to follow.
We don’t yet know what will be required for apples setup.
Im sure once Apple release it, there’ll be dozens of threads here about how to set it up, each one of them half full of incorrect or misleading instructions.
Okay, so what it seems like is that we would have to pay for the domain separately? That's not included in iCloud+. Apple isn't registering the domain for you with your iCloud storage payment?
At this point in time, nobody around here knows. The best thing to do is wait until we get more information from the mothership.
it’s essentially a guarantee, yes. Domain prices are not fixed, and while relatively cheap for most TLD’s they’re not $0 so there will be an additional cost of some kind, over the iCloud subscription cost, yes.
It doesn't, really. POP and IMAP are essentially mail retrieval protocols, so they have nothing to do with email delivery. Most providers use a full email address as the login name for the mailbox just out of convenience — it's guaranteed to be unique, after all — but even this isn't a requirement.
To answer the bigger question, however, there is no technical limitation that would prevent users from having both an iCloud and personal domain on the same mailbox, receiving emails at both and choosing which one to send from at any given time. It's simply up to Apple whether it will allow that as a matter of policy.
As others have pointed out, in the very least Apple will definitely provide detailed instructions once this launches. They will also likely work with some domain providers to allow for a simplified "one-click" type setup so you don't have to do anything manually.
From a technical perspective, however, this involves two steps:
Firstly, you'll need to create one or more (usually two) "MX" (Mail eXchanger) records in your domain. This is normally done wherever your domain name was purchased — domain hosting companies will generally provide you with online tools to set up at least a few basic records.
The MX entries are how every other mail server on the internet knows where to send all mail for "(anything)@yourdomain.com". For iCloud, you will point these to whatever servers Apple tells you to point them to.
The second step will be specific to how Apple implements this. We don't know anything about that yet, as all of this is based on one paragraph on Apple's iOS 15 Preview Page. Basically, however, Apple will need to provide some way for you to assign "yourdomain.com" to your account so that its iCloud servers know that they're supposed to receive mail for it.
Because this is a somewhat technical process, however, I fully expect Apple to do everything it can to make this as simple as possible — by providing detailed step-by-step instructions or partnering with a few domain providers to create a turnkey solution. Even Google Workspace already has a list of domain providers that can automatically setup all of the records in one or two clicks, and that's a business solution.
The short answer is yes — you'll have to pay for it separately.
Firstly, it's probably fair to say that most iCloud users aren't going to take advantage of this, so it makes no sense to include it in the price. It's most definitely an add-on.
However, the only way Apple could register the domain for you is if it actually set itself up as a domain registrar, and for reasons which have been mentioned earlier in this thread, that seems extremely implausible.
You'll likely be required to purchase your domain somewhere else — Apple will probably have a couple of recommended partners, but you should be able to really go just about anywhere — and then follow some steps that Apple provides to tie that domain to your iCloud account.
There's a slight possibility that Apple might partner with another company to provide a completely turnkey solution for purchasing, registering, and setting up a new domain all in one fell swoop, and I wouldn't even put it past Apple to handle the billing in that case (and take a 30% cut 😏), but you'd still be paying for it separately, and it would be more like a third-party in-app subscription than part of your iCloud plan.
One reason the + thing doesn't work for me is that I don't want anyone to be able to infer my "master" email address from any of my aliases (to me aliases are a privacy tool used to segregate email contacts in specific groups).
For example, I have an alias which I use for once-off online orders/contacts and delete once a year to create a new one (Apple's new privacy address feature would actually cover that need for me). This is because I don't want contacts in that group to retain my email details long term, i.e. it essentially is a disposable address which gets flushed regularly. Using a "+" address based on my master email account wouldn't make sense for this as I would essentially be giving them my "forever" address.
Another example: one of my aliases used to register on websites was caught in a data leak and is now included in lists used by spammers and hackers trying to impersonate people to gain access to online services. If it had been a "+" address, spammers would still be spamming me, and hackers would have my master email. With an actual alias, I can just create a new alias, update it on all online services for which I used the leaked email address to register, delete the old alias, and forget about it (and since this alias is only used to register with online services, I don't need to update any of my actual human contacts with a new address).
I don't need hundreds of aliases though. 5 or 6 are plenty for my different contact categories.
Last edited:
I understand that theoretically thats a problem. In reality, anyone paying the slightest bit of care about mail addressing, won't do that.
From a remote point of view (i.e. not someone in control of the mail server hosting the mailboxes for <domain.com>) you cannot make assumptions about the local part (the bit before "@").
Also, to be clear, I'm not suggesting so much that you would use + instead of any aliases.
I'm saying that I use one alias, and combine that alias with the + operator.
So, for example, my alias' local part is `srspam`. I then combine that with + and some description. So, for this site, it's `srspam+macrumors@<blah>`. None of that relates at all to the actual mailbox.
For what it's worth, iCloud does support 3 aliases. I don't recall seeing anything about how that'll be impacted (if at all) by the new auto-generated aliases - but presumably the difference is that the generated ones are for incoming mail only, you won't be able to send using them..
Yes sorry I had misunderstood this in your original message. Makes sense altough personally I feel it is better for my use case to have separate aliases for safety and privacy.
I actually have an alias specifically for my Apple ID as I use iCloud for most of my data (except emails for now) and to me this is *the* service I don't want to be hacked. I see the specific alias as a security measure: if some of my personal information (name, email address, DOB, phone number, etc) is leaked by another website, hackers who might want to try to use the leaked data to gain access to accounts on popular cloud services won't be able to trivially identify which Apple ID relates to the rest of my information*.
* I am not saying that if they decide to put some efforts in targeting me in particular they won't find their way, but at least it makes it harder to automate and if they are mass processing a large list of leaked information it should be good enough.
I actually go one step further than this, as I use Fastmail and it supports subdomain addressing, which basically lets me omit the plus, eliminating many of the clues
For example, instead of using "spamalias+sketchycompany@mydomain.com" I can use "sketchycompany@spamalias.mydomain.com." Avoids some of the confusion around using plus addresses, and makes it far less obvious that there's any special about the address (assuming I don't use addresses like the ones shown in the example above 😏).
Thanks for the info JH.
So, essentially, this works like a SIP registrar/VoIP. If a device is registered to it(email client is pointed to it), the POP/IMAP server can process any ID it receives provided it is configured to recognize the ID@domain.
So Apple or any other provider has a lot of latitude to accept custom email IDs (provided it’s unique)
About right?