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.

Link

Europe Planning A DNS Infrastructure With Built-In Filtering

Catalin Cimpanu, reporting for The Record, has found that the European Union wants to build a recursive DNS service that will be available to EU institutions and the European public. The reasons for building the service are manifold, including concerns that American DNS providers are not GDPR compliant and worries that much of Europe is dependent on (largely) American-based or -owned infrastructure.

As part of the European system, plans are for it to:

… come with built-in filtering capabilities that will be able to block DNS name resolutions for bad domains, such as those hosting malware, phishing sites, or other cybersecurity threats.

This filtering capability would be built using threat intelligence feeds provided by trusted partners, such as national CERT teams, and could be used to defend organizations across Europe from common malicious threats.

It is unclear if DNS4EU usage would be mandatory for all EU or national government organizations, but if so, it would grant organizations like CERT-EU more power and the agility it needs to block cyber-attacks as soon as they are detected.

In addition, EU officials also want to use DNS4EU’s filtering system to also block access to other types of prohibited content, which they say could be done based on court orders. While officials didn’t go into details, this most likely refers to domains showing child sexual abuse materials and copyright-infringing (pirated) content.1

By integrating censorship/blocking provisions as the policy level of the European DNS, there is a real risk that over time that same system might be used for untoward ends. Consider the rise of anti-LGBTQ laws in Hungary and Poland, and how those governments mights be motivated to block access to ‘prohibited content’ that is identified as such by anti-LGBTQ politicians.

While a reader might hope that the European courts could knock down these kinds of laws, their recurrence alone raises the spectre that content that is deemed socially undesirable by parties in power could be censored, even where there are legitimate human rights grounds that justify accessing the material in question.


  1. Boldface not in original. ↩︎
Link

Finnish Residents Briefly Left in Cold After DDoS Attack

Per Motherboard:

Simo Rounela, CEO of Valtia, a Finnish company that manages the buildings, told Motherboard that the attack hit a DNS service; that is, servers that translate human-readable internet domain names into computer IP addresses.

Shortly after, Valtia received a number of alerts from one of their building’s automation systems, made by a company called Fidelix.

“Remote connection was not working, so went on-site for more inspections,” Rounela explained. The automated system controlling the heating, ventilation and hot water for the homes kept rebooting every 5 minutes. Eventually, it just didn’t boot-up anymore, he said.

We generally don’t understand the full impacts of connecting things to the Internet; it’s a hugely complex system that we can’t easily ‘fault test’ without breaking a lot of different services and systems. The result is that an attack on one aspect of the Internet – such as the DNS infrastructure – can have unexpected impacts around the world. It’s this potential for untold, and cross-national, impacts linked to cyber attacks that makes many of them so risky and dangerous to the general public.

Link

Internet Census 2012

yostivanich:

While playing around with the Nmap Scripting Engine (NSE) we discovered an amazing number of open embedded devices on the Internet. Many of them are based on Linux and allow login to standard BusyBox with empty or default credentials. We used these devices to build a distributed port scanner to scan all IPv4 addresses. These scans include service probes for the most common ports, ICMP ping, reverse DNS and SYN scans. We analyzed some of the data to get an estimation of the IP address usage.

Super interesting research, though incredibly illegal and borderline ethical (at absolute best, and most charitable).

Link

US Internet Imperialism Strikes (Again!)

Wired has run a decent piece surrounding unilateral American seizures of domain names by acting on critical infrastructure governed by US law. A key bit from the article to get you interested:

Bodog.com was registered with a Canadian registrar, a VeriSign subcontractor, but the United States shuttered the site without any intervention from Canadian authorities or companies.

Instead, the feds went straight to VeriSign. It’s a powerful company deeply enmeshed in the backbone operations of the internet, including managing the .com infrastructure and operating root name servers. VeriSign has a cozy relationship with the federal government, and has long had a contract from the U.S. government to help manage the internet’s “root file” that is key to having a unified internet name system.

These domain seizures are a big deal. Despite what some have written, even a .ca address (such as the address country code top level domain linked to this website) could be subjected to a take down that leverages the root file. In effect, US copyright law combined with American control of critical Internet infrastructure is being used to radically extend America’s capability to mediate the speech rights of foreign citizens.

The capacity for the US to unilaterally impact the constitution of the Web is not a small matter: such actions threaten the sovereign right to establish policy and law that governs the lives of citizens living in countries like Canada, Russia, Australia, and Europe generally. Something must be done, and soon, before the Web – and the Internet with it – truly begins to fracture.

Link

Comcast’s Catch-22 Position on SOPA

As noted by the folks over at Techdirt:

Just as NBC Universal and other SOPA supporters continue to insist that DNS redirect is completely compatible with DNSSEC… Comcast (and official SOPA/PIPA supporter) has rolled out DNSSEC, urged others to roll out DNSSEC and turned off its own DNS redirect system, stating clearly that DNS redirect is incompatible with DNSSEC, if you want to keep people secure. In the end, this certainly appears to suggest thatComcast is admitting that it cannot comply with SOPA/PIPA, even as the very same company is advocating for those laws.