Solved: Changed Name Server and Apple Custom Email Domain Stopped Working

Photo by Miguel u00c1. Padriu00f1u00e1n on Pexels.com

I recently moved a self-hosted WordPress website from a shared hosting environment to WordPress.com. The migration was smooth: I had to export the XML for the self-hosted WordPress installation and import it to the WordPress.com CMS, and then fix a few images. The website is functioning well and the transition was smooth.

However, shortly after doing so I started having issues with receiving emails at my custom email which was set up with Apple’s iCloud Custom Email Domain. Not good!

The Problem

I changed the name servers with the domain registrar (e.g., Bluehost or Dreamhost) so that my custom domain (e.g., example.com) would point to the WordPress.com infrastructure. However, in doing so my custom email (user@example.com) that was using Apple’s iCloud Custom Email Domain stopped sending or receiving email.

This problem was surfaced because email could not be sent/received and, also, I could not verify its domain in Apple’s “Custom Email Domain”. Specifically, iCloud presented the dialogue message “Verifying your domain. This usually takes a few minutes but could take up to 24 hours. You’ll be able to continue when verification is complete.” The “Reverify” button, below the dialogue, was greyed out.

Background

When you have registered the domain with a registrar other than WordPress (e.g., Bluehost, Dreamhost, etc) and then host a website with WordPress.com you will have to update the name servers the domain uses. So, you will need to log into your registrar and point the name servers at the registrar to NS1.Wordpress.com, NS2.Wordpress.com, and NS3.Wordpress.com. In doing so, all the custom DNS information you have provided to your registrar, and which has been used to direct email to a third-party email provider such as Apple and iCloud, will cease to work.

The Solution

When transitioning to using WordPress’ nameservers you will need to re-enter custom domain information in WordPress’ domain management tabs. Specifically, you will need to add the relevant CNAME, TXT, and A records.1 This will entail the following:

  1. Log into your WordPress.com website, and navigate to: Upgrades >> Domains
  2. Select the domain for which you want to modify the DNS information
  3. Select “DNS Records” >> Manage
  4. Select “Add Record” (Upper right hand corner)
  5. Enter the information which is provided to you by your email provider

Apple iCloud Custom Domain and WordPress.com

When setting up your custom domain with Apple you will be provided with a set of TXT, MX, and CNAME records to add. Apple also provides the requisite field information in a help document.

While most of these records are self evident, when adding the DKIM (CNAME record-type) record in WordPress.com, the Host listed on Apple’s website is entered in the “Name” field on WordPress’ “Add a Record” page. The “Value” of the DKIM on Apple’s website is entered as the “value” on WordPress’ site.

TypeNameValue
CNAMEsig1._domainkeysig1.dkim.example.com.at.icloudmailadmin.com
Visualization of Adding iCloud CNAME Record for WordPress.com


Note: Apple will generate a new TXT record to verify you control the domain after pointing the name servers to WordPress.com. This record will look something like “apple-domain=[random set of upper/lower case letters and numbers]”. You cannot use the “apple-domain=“ field that was used in setting up your custom email information with your original registrar’s DNS records. You must use the new “apple-domain=“ field information when updating your WordPress.com DNS records.

Once you’ve made the needed changes with WordPress.com, and re-verified your domain with Apple’s iCloud Custom Domains, your email should continue working.

In the Future

It would be great if WordPress actively and clearly communicated to users who are pointing their name servers to WordPress.com that there is a need to immediately also update and add email-related DNS records. I appreciate that not all customers may require this information, but proactively and forcefully sharing this information would ensure that their customers are not trying to fix broken email while simultaneously struggling to identify what problem actuallyy needs to be resolved.


  1. WordPress does have a support page to help users solve this. ↩︎

So You Can’t Verify Your Apple iCloud Custom Domain

Photo by Tim Gouw on Pexels.com

When you set up a custom iCloud email domain you have to modify the DNS records held by your domain’s registrar. On the whole, the information provided by Apple is simple and makes it easy to set up the custom domain.

However, if you change where your domain’s name servers point, such as when you modify the hosting for a website associated with the domain, you must update the DNS records with whomever you are pointing the name servers to. Put differently: if you have configured your Apple iCloud custom email by modifying the DNS information at host X, as soon as you shift to host Y by pointing your name servers at them you will also have to update DNS records with host Y.

Now, what if you don’t do this? Eventually as DNS information propagates over the subsequent 6-72 hours you’ll be in a situation where your custom iCloud domain email address will stop sending or receiving information because the routing information is no longer valid. This will cause Apple’s iCloud custom domain system to try and re-verify the domain; it will do this because the DNS information you initially supplied is no longer valid.

Should you run into this issue you might, naturally, first reach out to Apple support. You are, after all, running your email through their servers.

Positively: you will very quickly get a real-live human on the phone to help you. That’s great! Unfortunately, however, there is very little that Apple’s support staff can do to help you. There are very, very few internal help documents pertaining to custom domains. As was explained to me, the sensitivity and complexity of DNS (and the fact that information is non-standardized across registrars) means that the support staff really can’t help much: you’re mostly on your own. This is not communicated when setting up Apple custom email domains.

In a truly worst case scenario you might get a well meaning but ignorant support member who leads you deeply astray in attempting to help troubleshoot and fix the problem. This, unfortunately, was my experience: no matter what is suggested, the solution to this problem is not solved by deleting your custom email accounts hosted by Apple on iCloud. Don’t be convinced this is ever a solution.

Worse, after deleting the email accounts associated with your custom iCloud domain email you can get into a situation where you cannot click the re-verify button on the front end of iCloud’s custom email domain interface. The result is that while you see one thing on the graphical interface—a greyed out option to ‘re-verify’—folks at Apple/server-side do not see the same status. Level 1 and 2 support staff cannot help you at this stage.

As a result, you can (at this point) be in limbo insofar as email cannot be sent or received from your custom domain. Individuals who send you message will get errors that the email identify no longer exists. The only group at Apple who can help you, in this situation, are Apple’s engineering team.

That team apparently does not work weekends.

What does this mean for using custom email domains for iCloud? For many people not a lot: they aren’t moving their hosting around and so it’s very much a ‘set and forget’ situation. However, for anyone who does have an issue the Apple support staff lacks good documentation to determine where the problem lies and, as a result, can (frankly) waste an inordinate amount of time in trying to figure out what is wrong. I would hasten to note that the final Apple support member I worked with, Derek, was amazing in identifying what the issue was, communicating the challenges facing Apple internally, and taking ownership of the problem: Derek rocks. Apple support needs more people like him.

But, in the absence of being able to hire more Dereks, Apple needs better scripts to help their support staff assist users. And, moreover, the fact that Apple lacks a large enough engineering team to also have some people working weekends to solve issues is stunning: yes, hiring is challenging and expensive, but Apple is one of the most profitable companies in the world. Their lack of a true 24/7 support staff is absurd.

What’s the solution if you ever find yourself in this situation, then? Make sure that you’ve done what you can with your new domain settings and, then, just sit back and wait while Apple tries to figure stuff out. I don’t know how, exactly, Apple fixed this problem on their end, though when it is fixed you’ll get an immediate prompt on your iOS devices that you need to update your custom domain information. It’s quick to take the information provided (which will include a new DKIM record that is unique to your new domain) and then get Apple custom iCloud email working with whomever is managing your DNS records.

Ultimately, I’m glad this was fixed for me but, simultaneously, the ability of most of Apple’s support team to provide assistance was minimal. And it meant that for 3-4 days I was entirely without my primary email address, during a busy work period. I’m very, very disappointed in how this was handled irrespective of things ultimately working once again. At a minimum, Apple needs to update its internal scripts so that their frontline staff know the right questions to ask (e.g., did you change information about your website’s DNS information?) to get stuff moving in the right direction.

Aside

2022.4.9

I’ve been doing my own IT for a long while, as well as small tasks for others. But I haven’t had to do an email migration—while ensuring pretty well no downtime—in a long while.

Fortunately the shift from Google Mail (due to the deprecation of grandfathered accounts that offered free custom domain integration) to Apple’s iCloud+ was remarkably smooth and easy. Apple’s instructions were helpful as were those of the host I was dealing with. Downtime was a couple seconds, at most, though there was definitely a brief moment of holding my breath in fear that the transition hadn’t quite taken.

Aside

2019.9.21

I had plans to publish a short review of the iPhone Pro 11 camera today; I spent the day walking all over Toronto (21km!) and edited up shots on my iPad. It’s a cool and neat and very different iPhone camera system!

But it seems like my iPhone is entirely unable to sync photos with iCloud at the moment. I’ve done all the ‘normal’ things to get sync working but none are working. So I’ll see if syncing resolves overnight and, if not, the continuing failures of iCloud will definitely get their own section in my review.

Camera systems on phones include the cameras, the camera software, and the cloud infrastructure. If one isn’t working, then none of it is truly working.

Aside

2019.7.15

It’s great that Apple is asserting the importance of privacy. But if they’re really, really serious they’ll stop enabling the Chinese government direct access to Chinese users’ iCloud data. And they’ll secure data on iCloud so that government agencies can’t just request Apple to hand over our WhatsApp, iCloud, Notes, and other data that Apple holds the keys to unlocking and turning over to whomever comes with a warrant. I’m not holding my breath on the former, nor the latter.

Link

Apple’s Data Stewardship Questioned, Again

Matt Green has a good writeup of the confusion associated with Apple’s decision to relocate Chinese users’ data to data centres in China. He notes:

Unfortunately, the problem with Apple’s disclosure of its China’s news is, well, really just a version of the same problem that’s existed with Apple’s entire approach to iCloud.

Where Apple provides overwhelming detail about their best security systems (file encryption, iOS, iMessage), they provide distressingly little technical detail about the weaker links like iCloud encryption. We know that Apple can access and even hand over iCloud backups to law enforcement. But what about Apple’s partners? What about keychain data? How is this information protected? Who knows.

This vague approach to security might make it easier for Apple to brush off the security impact of changes like the recent China news (“look, no backdoors!”) But it also confuses the picture, and calls into doubt any future technical security improvements that Apple might be planning to make in the future. For example, this article from 2016 claims that Apple is planning stronger overall encryption for iCloud. Are those plans scrapped? And if not, will those plans fly in the new Chinese version of iCloud? Will there be two technically different versions of iCloud? Who even knows?

And at the end of the day, if Apple can’t trust us enough to explain how their systems work, then maybe we shouldn’t trust them either.

Apple is regarded as providing incredibly secure devices to the public. But as more and more of the data on Apple devices is offloaded to Apple-controlled Cloud services it’s imperative that the company both explain how it is securing data and, moreover, the specific situations under which it can disclose data it is stewarding for its users.

Link

iCloud Keychain isn’t the same as Lightroom!

Jon Brodkin, writing for Ars Technica:

Unfortunately, it’s kind of a mess. iCloud Keychain does accomplish the most basic things you’d expect a password manager to do, but it often does so in an awkward manner. Important functionality is hard enough to find that it may be effectively hidden from the average user, particularly on iPhones and iPads.

Ultimately, iCloud Keychain can be put to good use if you’ve carefully examined what it does well and doesn’t do well. It works best as a complement to a complete service like 1Password or LastPass, but it just isn’t convenient and robust enough to act as a standalone password manager.

I think it’s a bit harsh to call it a “mess”, but Brodkin provides a good overview of what iCloud Keychain does. Complaining that it’s not as full-featured as 1Password is like complaining that iPhoto doesn’t do everything Lightroom or Aperture do.

Comparing iCloud Keychain and Lightroom is a bit odd. One helps to manage the security of one’s online life and is meant to resolve a security problem for anyone who uses the Web. Lightroom is a specialist product that caters to experts in a particular field. The two products may have an overlapping user base (i.e. individuals who want secured usernames and passwords) but otherwise bear little resemblance to one another.

Quote

I still think [Apple] should go back to Dropbox with a blank check and just ask how many zeros they need to put at the end to make it happen.

My friend Dave Zaffrann, practicing the art of Having a Decent Idea while lamenting iCloud’s future (via chartier)

I think that this is on the mark, in the sense that iCloud is gross and Apple needs to do better. I also hope it never comes to be, given how much I use Dropbox on non-Apple devices and products.