iCloud+ Custom Email Domains should be better

I’ve been using custom domains for my email for a couple of years now, in which time I switched between Zoho, Fastmail, Microsoft 365, and Google Workspace.

Apple recently rebranded paid iCloud plans to iCloud+ and introduced support for custom email domains on iCloud Mail. This has been a long awaited feature for me, and one I was excited to try out — with the end goal being switching our family domain from Google Workspace to iCloud.

Here’s what I found.

Table of Contents

Issue #1: No catch-all address support

The way most email services work by default is you explicitly set up which addresses can receive email — and you usually get a different account (aka. inbox) for each of those addresses. Emails sent to non-existent account (determined by the email address) get “bounced”, meaning the sender gets back an automated reply saying the delivery failed because an account for the given address does not exist.

Setting up a catch-all address for a domain means you can get emails sent to any address that hasn’t been explicitly set up routed to an existing account — or even have it copied to multiple accounts.

There are many reasons why having a catch-all set up might be useful to you, but the primary use-case in our family is sharing access to services that don’t support adding multiple people to an account. For example, we use {gas}@{family_domain} to log into our gas provider’s web application and get the latest bill or check up on our gas usage. Any emails the gas company sends us get routed to both my and my SO’s email account — courtesy of the catch-all.

iCloud’s Mail service unfortunately doesn’t support this — you have to explicitly list all address you want people to be able to use. To make matters worse, you also can’t have an address shared between multiple accounts (ie. people) — it’s a strict 1-to-many mapping between accounts and addresses, meaning one account can have multiple addresses but an address exclusively belongs to a single account.

So far, this is the first paid service I’ve encountered that doesn’t support a catch-all. While I can’t be sure why that is, a bit of digging unearthed that iCloud Mail is frontend by Proofpoint — so the catch-all limitation might be a consequence of complexity integrating the custom email domain feature with a relay that has been in place since iCloud’s beginnings.

Not to fret — if you’re an email power user in any capacity, and you arguably are if you’re setting up custom email domains — you could also put in an inbound email relay like ImprovMX or the recently launched Cloudflare Email Routing and set up routing however you want before passing it to an address you set up on iCloud Mail. Well, about that…

Issue #2: Aggressive DNS record validation

The custom email domain setup on iCloud won’t let you finish before your domain’s DNS records exactly match the ones provided in the instructions.

There are four types of DNS records you need to add to get your domain set up:

a TXT record with a validation token so Apple can confirm you have access to the domain’s DNS management
two MX records pointing to mx01.mail.icloud.com and mx02.mail.icloud.com so your email gets routed to iCloud’s servers
a CNAME record for DKIM so Apple can sign the emails you’re sending
a TXT record for SPF so your recipients can validate Apple’s servers are allowed to send emails on the behalf of your domain

Any other email service should ask you to add (at least!) the exact same four record types. Where other services differ, though, is they will let you manage accounts and/or routing as soon as you’re done validating your domain with the TXT record — the first out of the four. They will likely warn you if your MX records are different to theirs, or if your SPF doesn’t allow them to send email on your domain’s behalf, but a warning you can ignore if you know what you’re doing is all you’re going to get.

So, let’s just set it up with the records iCloud wants and swap them out later — right? Well, about that…

Issue #3: No inbound email relay support

Even after you set up your domain for iCloud Mail, it’ll actively prevent any management actions you want to take if any of the records don’t match up with what it’s expecting — ie. ones you were asked to put in during the setup. If you want to add more addresses or set up a new account for the domain, you better be using iCloud’s MX records. This means no support for inbound email relays at any point — which is straight up ridiculous. The only saving grace for Apple is they will continue routing whatever addresses you did manage to set up before causing the unimaginable kerfuffle that is modifying a DNS record.

Speaking of, you’ll know if you’re being prevented from adding an email address because it’s something you did that iCloud’s not happy with, and not an issue on their end? Well, about that…

Issue #4: Opaque error messages

If something goes wrong, you’ll get an error message along the lines of:

There was a problem with adding this email address. Please try again later.

However, if you open your browser’s developer console and inspect the response payload from a POST request going to https://p31-maildomainws.icloud.com/v1/alias/add, you’ll see what’s actually going on:

{
    "success": false,
    "error": {
        "errorCode": "-1001",
        "errorMessage": "mx record not pointing to iCloud",
        "retryAfter": 2
    },
    "timestamp": 1645977991
}

Notice how the user-friendly error message that appears in the UI instead of the errorMessage from the response payload does not provide you with a course of action to resolve the issue — in fact, I would argue it’s pointing you in the direction of it being a temporary issue on iCloud’s end. Now that you’ve figured out what the issue is, good luck finding what any of the records actually need to be after the initial domain setup. Sure, dig MX icloud.com or a query to your favourite search engine will get you the MX records values, but you’re SOL if you accidentally delete the TXT record used for domain validation. Have fun going through the setup all over again, I guess.

Besides the “there was a problem” message, there’s another fun one. Let’s switch the MX records back to iCloud and see what it is.

Issue #5: Coupling with Apple IDs

Another worrying thing about how Apple implemented custom domains for iCloud Mail is some amount of domain address and Apple ID coupling. I hold that these two should be entirely separate. If you control a domain, you’re already able to do whatever you want wrt. where any emails for that domain end up, making any arguments about security a moot point. As of right now, if you try to assign an address that was previously used as an Apple ID, you get an error message:

This email is already in use with another Apple ID.

Much like the previous error message I mentioned, this one is wrong too — it was in use, but it’s not any longer. Inspecting the response payload reveals a different message:

{
    "success": false,
    "error": {
        "errorCode": "-21099",
        "errorMessage": "This email address is not available.  Please try again with a different address.",
        "retryAfter": 2
    },
    "timestamp": 1645979153
}

This is either a deliberately implemented obstacle, or a result of legacy code and assumptions made before custom email domains were implemented. Either way, I hope it’s something Apple is working on resolving. From what I’ve managed to gather so far, it takes a year for an address previously used as an Apple ID to become available again — either as a iCloud Mail address or an address you can use for your Apple ID. Even if the address belonged to your account — making it that much more perplexing.

You could just use an address that hasn’t been used as an Apple ID in the last year, set up other accounts you need (if any), and still handle the address that was used as an Apple ID through an inbound relay — aliasing it in your email client so you can reply back with the same address — right? Well, about that…

Issue #6: Emails sent from addresses without an account get dropped

If you use iCloud’s SMTP server and set the From address to an address you didn’t explicitly add to your account, it gets dropped. This means you can’t use arbitrary aliases to send email from — and I’m pretty sure that’s a direct consequence of iCloud’s outbound relay being a closed system.

I’m not sure if there’s anything Apple can do about it short of making drastic changes to their email system architecture, nor that they should, but it’s a significant hindrance when combined with the Apple ID coupling issue you could run into. On that point, there’s one more coupling issue you should be aware of…

Issue #7: 3rd party clients may leak your Apple ID

If you use email clients other than Apple Mail or the web-based iCloud Mail, you’ll need to log in to them using your Apple ID and an app-specific password, then set up your extra addresses that use custom domains as aliases to be able to send emails from them. Unfortunately, my email client of choice currently sets the Return-Path header of outbound emails to the sign-in address — resulting in leaking my Apple ID no matter which address I choose to send the email from. I suspect plenty of other clients do the same, and while I have reported this issue to the development team, it would be nice if iCloud rewrote this header to protect end users regardless of their email client of choice.

Verdict

I’ll be seeing how this goes for the next few days, and make a decision whether to roll back to Google Workspace from there. Since I won’t have more than five accounts and two or three domains, I can afford to give up account management for a while — in the hopes Apple tones down their DNS record checks — and get around the missing catch-all functionality with an inbound relay. The bigger issue is not being to reply to emails from an address I previously used as my Apple ID — and that’s something I’m not sure I can get past.