Office 365: Custom Domain Configuration for Email

If there's one commonality between my original work with Office 365 last year and my more recent do-over, it's that setting up a custom, or personalized, domain has been the trickiest part of initial configuration. This isn't completely Microsoft's fault, and much of the blame lies with the bizarre and arcane world of Internet domain registration. But it should be easier, and in some cases Microsoft's own documentation is incorrect or at least incomplete.

As a backgrounder, I'm sure there are some people out there who "get" the domain registration and configuration process, just as some are inherently good at computer programming, quantum physics, or other topics that befuddle most normal people. But as far as I'm concerned, this stuff is black magic, and the fact that it's the glue that makes the Internet work sends a shudder down my spine when I think about it too much. I'm not good at it, and that makes me nervous.

Making things worse, many domain registrars--the companies that are allowed to sell and manage top-level domain names--are, in my experience, pretty lousy and are often so on purpose. They exist to sell added, unnecessary services to confused domain name purchasers, a practice I find deplorable. And as I found while experimenting with Office 365 custom domains, some make the process of moving a domain from registrar-to-registrar painful and time consuming. Again, on purpose.

In any event, whether you represent a company (of any size), a small group or very small business, or yourself as an individual, one of the most basic tasks you'll want to do when signing up for Office 365 is configure it to use a custom domain for email purposes. That is, while Microsoft does allow you to use an onmicrosoft.com domain (like paulthurrott.onmicrosoft.com) with which you could add accounts and access email (via addresses like [email protected]) and other services, you won't typically want to do so.

This alone makes Office 365 quite different from, say, consumer-oriented services like Hotmail and Gmail, where users are generally expected to use the top-level domain of the service itself (as in hotmail.com or live.com for Hotmail, or gmail.com for Gmail). That said, both Hotmail and Gmail do offer custom domain support as well, though in the case of those services, that's the exception not the rule. 

Oddly enough, I had much less difficulty configuring custom domains on both Hotmail and Gmail, which suggests that those services are probably better choices for individuals and groups than is Office 365, especially when you combine this with the fact that Hotmail and Gmail are both free. I'll explore this topic further in a future article in this series.

For now, let's assume that the [whatever].onmicrosoft.com account that Microsoft initially configures is not what you're looking for, since that will be the case for virtually all Office 365 users. Once you've established your account, you can log on and access the web-based Office 365 admin console, which provides a number of useful configuration options. And one of the more important, right up front, is the ability to associate your own top-level domain with the service. So instead of using onmicrosoft.com, you can use your domain of choice (mydomain.com or whatever).

To do so, navigate to Admin and then Domains (the latter of which is under Management in the left-hand Admin Overview pane). On the Domains page, click Add a domain.

First, you'll be asked to specify the domain you want to use. This is, of course, where things get interesting.

You must have first registered this domain with a domain name registrar such as Enom, Go Daddy, Hover, Melbourne IT, Network Solutions, Register.com, or whichever registrar you prefer. Over the years, I've registered many domain names, and have stupidly spread them out to various registrars. I have two accounts with Melbourne IT, for example, one for each of my Hotmail accounts, because Microsoft recommended them for use with Windows Live Domains, the company's custom domain service for Hotmail. I have other domains on Go Daddy and others elsewhere.

As part of this year's tech consolidation work, I'm starting to consolidate my own domains on namecheap.com, which was recommended to me by Rafael Rivera, my Windows Secrets co-author. But this recommendation came only after I reached out for help after my initial troubles configuring a domain with Office 365. This was, of course, accompanied by a sense of deja vu, since I had previously encountered exactly the same problems, last year, but with a different registrar.

Here's how it's supposed to work. You have whatever domain housed on whichever registrar. Stepping through the Office 365 Add a domain wizard, when you're asked to "verify the domain," what you're really doing is specifying which registrar you're using to configure your domain and then Office 365 will provide you with registrar-specific instructions. You can choose from a list that includes all of the above-listed registrars, or "general instructions" if your registrar is not on the list.

My custom domain was originally housed on Melbourne IT. As a Microsoft partner, this registrar should provide a fairly seamless experience, or so I thought. So I chose Melbourne IT. Examining the instructions, I compared it to what the Melbourne IT web site had. And the instructions did not match up at all. Not even close.

Office 365 has two ways in which you can "connect" the service to your domain, and this is where the black magic of the domain name registrar system comes into play. You can do so via a so-called TXT record, which I understand to be a generic text file that contains some value that will be meaningful to the connecting service and proves you own the domain (because you can configure it). Or you can use an old-school MX record, which is "a mail exchanger record, or type of resource record in the Domain Name System that specifies a mail server responsible for accepting email messages." Microsoft prefers you use the TXT record, but supplies MX instructions if you can't get the former to work.

I couldn't get either to work. Ah, that old deja vu.

After pounding my head repeatedly into the keyboard--no, this didn't work either--I discussed the problem with Rafael. He had had similar issues configuring Office 365, as it turns out, but after checking the instructions, he verified what I had found: The instructions didn't match what I was seeing on Melbourne IT's web site. That is, Microsoft was specifying certain settings names (and associated values to apply) that I needed to configure on the registrar's site. These were:

Alias or host name

Destination

Address TTL

The instructions hint, oddly enough, that Melbourne describes these values differently. Parsing the instructions, the aforementioned three settings names were:

TXT

Fully Qualified Domain Name (FQDN) or Points To

TTL

Forgetting for a moment that the values I needed to configure don't match up in any way, no combination of supplied values would work. (And a note about adding a period ['.'] to the end of the FQDN only confused matters; Melbourne IT wouldn't even accept a value of that kind.)

Sigh.

After a lot of futzing around, I caved to Rafael's recommendation to move the domain to NameCheap, as he had successfully configured an Office 365 custom domain using that registrar. So I did so. And this is where the silliness reached newly ridiculous levels.

Domain registrars, go figure, don't like to see you go. So when you attempt to transfer a domain from them to a new registrar, you meet some resistance. I mean, they have to let you go. But they don't go down without a fight. (Domain transfers are initiated from the new registrar. So I did that after signing up for an account with namecheap.com.)

Melbourne IT emailed me, noting that I had requested a transfer to another domain name registrar. It helpfully provided a hyperlink if I wished to REJECT this transfer. But only the following note if the request was, in fact, what I meant to do: "If you do not reject within 4 calendar days(inclusive of today) of this email, the transfer will be automatically approved in accordance with ICANN policies." In other words, I could reject the request immediately. But if I actually wanted to perform the transfer, I could do so. It would just take up to four days.

Which it did. Melbourne IT held on to that domain for exactly four more days. It didn't release it until it had to. So much for Microsoft's domain partner.

During this wait, I decided to see how a different registrar would react to a similar request. So I initiated a second domain transfer, this time from Go Daddy. You may know that Go Daddy doesn't have a particularly good reputation, not just for its terrible TV ads, but for the convoluted nature of its horrible web site and its over-selling of unnecessary additional (and costly) services to customers. How would Go Daddy react to an identical request?

Go Daddy, like Melbourne IT, immediately emailed me to alert me that it had received a transfer request. And Go Daddy, like Melbourne IT, also provided a handy hyperlink in case I wanted to reject that request.   But Go Daddy surprised me by also providing a hyperlink for accepting the transfer. And it went through within minutes once I clicked on it. So much for that firm's reputation.

After four days had elapsed and Melbourne IT had begrudgingly coughed up my domain, I once again ran through Office 365's Add a domain wizard. This time, of course, I used the general instructions. Looking at NameCheap's domain configuration, I was able to add the TXT record and, within minutes, continue the wizard to complete the domain switch on Office 365.

There's more to be done, actually. After making this conversion, you'll also want/need to convert your whatever.onmicrosoft.com accounts (and email addresses) to the new domain. By default, Office 365 will assign the same user names from whatever.onmicrosoft.com to the new domain. So if you chose poorly as I did, with [email protected], you'll need to go in after the fact and change the account name. Fortunately, this is actually pretty easy assuming you know where to look: Management, Users, [user name], and then Details. From this screen, you can change the account's user name.

Test the sending and receiving of email and ... voila! You're done.

But what's the point of all this? Well, your own experience configuring a custom domain on Office 365 is going to vary, perhaps wildly, based on two things: Which domain registrar you've used to purchase and configure your own custom, personalized domain, and whether Office 365's instructions have been updated to match. Normally, I'd say that you're better off using a registrar that's explicitly supported by Office 365, but that wasn't the case for me, and it was a source of frustration.

And then there's the fact that setting up a custom domain like this only applies to email. If you're interested in using this custom domain--or a subdomain like docs.yourdomain.com or whatever--for SharePoint Online's internal site and/or public web site, well, you've got more work to do.

But I'll leave that for a future article, given how much ground this has already covered. Correctly configuring SharePoint Online, as you'll discover, is a whole new set of pain to deal with.

More soon.