{"id":35156,"date":"2022-03-02T15:52:20","date_gmt":"2022-03-02T20:52:20","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=35156"},"modified":"2022-03-02T15:52:20","modified_gmt":"2022-03-02T20:52:20","slug":"icloud-custom-e-mail-domains","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/03\/02\/icloud-custom-e-mail-domains\/","title":{"rendered":"iCloud+ Custom E-mail Domains"},"content":{"rendered":"

Dominic Lautner<\/a> (via Hacker News<\/a>):<\/p>\n

\n

So far, this is the first paid service I’ve encountered that doesn’t support a catch-all.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

Notice how the user-friendly error message that appears in the UI instead of the errorMessage<\/code> 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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

If you use email clients other than Apple Mail or the web-based iCloud Mail<\/a>, 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<\/code> 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.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n