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.

Solved: Set A Default Email Address in Apple Contacts

I figured out how to set a default email address for a contact in Apple Contacts, where the contact has multiple email addresses associated with them.

The Problem

Apple support claims that Siri is capable of learning which email address to use when someone you are contacting has multiple email addresses associated with them in your contact book. In my experience this is hit and miss. The result is that you need to check, each time, to ensure that an email is being sent to the correct email address.

The Solution

For the contact in question you must ensure that the email you want to most regularly contact them is the first email in the list of emails. Thus, if you had a set of emails ordered as such:

  • example1@email.me
  • example2@email.me
  • example3@email.me

and wanted ‘example 3@email.me’ to be the default email that you send message to, you would:

  1. Open Contacts and the individual’s card, and then click ‘Edit’
  2. Copy the email that you want to remove as the current default (e.g., example1@email.me)
  3. Create a new email record by clicking the field beside ‘Other’ at the bottom of the list and paste the email address you copied at 2
  4. In the top email field (i.e., example1@email.me) replace it with the preferred default email (e.g. example3@email.me)
  5. Delete the now-duplicated example3@email.me
  6. Click ‘done’

At the conclusion of this reordering, your email order list would appear as:

  • example3@email.me
  • example2@email.me
  • example1@email.me

The result of the reordering is that you should, by default, now send email to the contact’s example3@email.me. I hope this helps anyone else who’s running into this problem!

Aside

2018.1.17

Blew away over 10K emails that were collecting dust in one of my main accounts. My goal over the next few months is to remove the mass majority of old email that serves no purpose. Doing so will both free up some space (not that I really need it) while also cutting down on the possible deleterious effects of having the account in question getting hacked and contents selectively modified and/or leaked.

Contemporary Email is a Threat to Us All

Per researchers:

Companies and other organizations are even more vulnerable than individuals. One person needs only to worry about his or her own clicking, but each worker in an organization is a separate point of weakness. It’s a matter of simple math: If every worker has that same 1 percent chance of falling for a phishing scam, the combined risk to the company as a whole is much higher. In fact, companies with 70 or more employees have a greater than 50 percent chance that someone will be hoodwinked. Companies should look very critically at webmail providers who offer them worse security odds than they’d get from a coin toss.

As technologists, we have long since come to terms with the fact that some technology is just a bad idea, even if it looks exciting. Society needs to do the same. Security-conscious users must demand that their email providers offer a plain-text option. Unfortunately, such options are few and far between, but they are a key to stemming the webmail insecurity epidemic.

Mail providers that refuse to do so should be avoided, just like back alleys that are bad places to conduct business. Those online back alleys may look eye-pleasing, with ads, images and animations, but they are not safe.

The problem is that few people appreciate the dangers of email; their understanding of phishing tends to be centred around the garbage that gets caught by most SPAM filters, when they have any clue what phishing is in the first place. Further, it’s not enough to personally avoid the ‘back alleys’ of the Internet email crowd: you need to excise all email that is received by such providers. And that means the problem is one of herd protection and immunity, which is challenging at best to overcome. Who’s going to unilaterally ban email from all the major email providers in the world today?

Link

More Thoughts on the Yahoo Scan

Macy Wheeler:

To sum up: ex-Yahoo employees want this story to be about the technical recklessness of the request and Yahoo’s bureaucratic implementation of it. Government lawyers and spooks are happy to explain this was a traditional FISA order, but want to downplay the intrusiveness and recklessness of this by claiming it just involved adapting an existing scan. And intelligence committee members mistakenly believed this scan happened under Section 702, and wanted to make it a 702 renewal fight issue, but since appear to have learned differently.

This is the definitive summarization of what Yahoo! (likely) did when they monitored all of their customers’ emails for the US government. Well worth the read for its content and, also, to see what goes into a critical media evaluation of an unfolding intelligence-related series of news stories.

Link

Yahoo May Have Exposed Rogers Customer Emails to US Spies

Motherboard:

“Any program that scans all the mail that Yahoo has access to would have scanned this email,” Gillmor wrote me in a message.

“If Yahoo chose to segment their scanning by limiting it only to mails that have ‘@yahoo.com’ email addresses [and omitted those sent from @rogers.com], of course, then they would have chosen to exclude this email from the scan,” Gillmor continued. “It’s not clear to me whether any such constraint was in place, though.”

“I’d imagine that, yes, the program would have applied to Rogers customer emails, unless Yahoo elected to specifically exclude them,” wrote Marczak in an email.

Yahoo declined to comment on whether the alleged system filtered out emails from Rogers customers.

Tobi Cohen, a spokesperson for the Office of the Privacy Commissioner, confirmed that Rogers consulted the office in the wake of the Yahoo hack. But as far as the possibility that Rogers customer emails had been siphoned into a surveillance dragnet goes, “Given we don’t have detailed information about the matter, we are not in a position to comment,” Cohen wrote.

When asked if Rogers was aware of the allegations against Yahoo or if the company is concerned that a backdoor could have affected its customers, spokesperson Garas referred me to Yahoo’s statement and wrote that “as such, we believe this matter is closed.”

Great to know that Rogers thinks it shouldn’t (or, worse, doesn’t have to) explain how one of its contracted service providers may have grossly violated the privacy of Rogers’ customers.

Link

What’s the big deal about Hillary using her personal email at work?

What’s the big deal about Hillary using her personal email at work?

Christopher Parsons, a Toronto-based cybersecurity expert with the think tank Citizen Lab, explained the security difference between a personal and official government email.

“The core security advantage is that the U.S. government will be attuned to the risk of her communications being deliberately targeted and, as such, would have a chance to maximize protections afforded to her communications,” Parsons said. “Moreover, data sent and received in U.S. government systems could be protected according to the sensitivity of the communications. So when sending classified or secret documents, a higher standard of care could have been provided.”

I would note that I don’t work at a think tank: I work at the University of Toronto, within the Munk School of Global Affairs.

Quote

Shaw email customers are scrambling after an interruption of Shaw’s email services Thursday led to millions of emails being deleted.

About 70 per cent of Shaw’s email customers were affected when the company was troubleshooting an unrelated email delay problem and an attempted solution caused incoming emails to be deleted, a spokesman told The Sunday Province.

Shaw has about 1.9 million Internet subscribers across Canada, with the majority in Western Canada.

Emails were deleted for a 10-hour period between 7:45 a.m. and 6:15 p.m. Thursday, although customers did not learn about the problem until Friday, and only then by calling customer service or accessing an online forum for Shaw Internet subscribers.

Shaw promised to email affected customers some time over the weekend with a list of deleted messages and details such as sender, subject and time sent. The actual content of the emails, however, is unrecoverable.

Count this amongst the many reasons I just don’t trust ISPs to host my email. It’s great that Shaw does this, really, given how it generally interferes with ports used for email: not only are they screwing consumers in how they treat email protocols (you can pay a monthly fee for full port access) but they’re also screwing them by not properly managing their email systems. I bet that Shaw customers don’t receive any restitution beyond an apology.