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. ↩︎
Link

WordPress Supply Chain Attacks

Per Wordfence there are four reasons for supply-chain (i.e. plugin-based) attacks on WordPress installations:

The first reason is simply scale. According to w3techs, WordPress powers 29.2% of all websites – a massive user base to go after. In addition, at the time of this writing there were 53,566 plugins available for download in the official WordPress.org plugin repository. That is a lot to work with on both fronts.

Secondly, the WordPress.org plugin directory is an open, community-driven resource. According to the plugin guidelines page, “It is the sole responsibility of plugin developers to ensure all files within their plugins comply with the guidelines.” This means that while there is a small team tasked with managing the plugin repository and another small team focused on security, ultimately users rely on plugin developers to keep them safe.

Thirdly, most WordPress sites are managed pretty casually. Making a change to a website at a larger company might include code review, testing and a formal change control process. But that’s probably not happening consistently, if at all, on most smaller websites. In addition, many site owners don’t monitor their WordPress sites closely, which means malware can often remain in place for many months without being discovered.

Lastly, the WordPress plugin repository has a huge number of abandoned plugins. When we looked back in May, almost half of the available plugins hadn’t been updated in over two years. This represents a great opportunity for ne’er do wells looking to con unsuspecting plugin authors into selling something they created years ago and have moved on from.

The aforementioned points outline why acquiring and infecting WordPress plugins is a reasonable way of penetrating WordPress installs. However, I think that Wordfence is missing the most important reason that such attacks succeed: few actual users of WordPress are technically component to monitor what, exactly, their plugins are doing. Nor are the shared hosting services particularly good at identifying and alerting technically-illiterate users that their sites are compromised and what the site owners need to do to remediate the intrusion.

Trying to get individual users to more carefully monitor how their plugins work is a fool’s errand. What’s needed is for hosts to provide a community service and actively not just identify hijacked plugins (and sites) but, also, provide meaningful remediation processes. User education and alerts aren’t enough (or even moderately sufficient): companies must guide site owners through the process of cleaning their sites. Otherwise malware campaigns aimed at WordPress will persist and grow over time.