Setting up a custom domain and email address - for beginners, by a beginner

NOT MAGICAL a

I was domainless a few months ago. Being domainless comes with some misunderstandings.
I used to think a custom email address was an automatic perk of owning a domain, since most cool programmers I noticed had an email that seemed to spawn from their website's URL (brad [at] bradwoods.io, joel [at] joelonsoftware.com, jozef [at] legeny.fr, etc). And once I set up a domain / personal website, it was almost magical, like - poof - now I own this web address on the internet, bought with real money, and it should come with an email address for the internet too.

But no free lunch. Well, it can be mostly free, but it still takes work. Here's the steps I took from being domainless to having a custom email address, based around some simple truths that I wish were spelled out to beginners like me. Prepare yourself for lots of records and button finding:

STEPS a

• Buy a domain name from a registrar. I used Google Domains because I knew they would dumb things down to a familiar level. 1
• That registrar now manages your domain records, which are just files on their servers. There will be buttons somewhere on their web interface for modifying these records. You must find these buttons in order to move on.
• * Optional website step: if you want a website at your domain, you need a hosting service. I chose Netlify because they have free hosting and it seemed simple. Now you have two things managed separately, by separate services, on separate servers: domain registration and website content. To connect them, you'll need something like a CNAME domain record. Your hosting service will have an instruction page about this record. You must find these instructions. The record might look something like @ - apex-loadbalancer.netlify.com. You must use the buttons on your registrar's web interface and fill in the details from these instructions. 2
• Choose an email hosting service based on their specs for custom domains. For context: emails are sent, received, and stored by somebody's server. Generally, people will charge you money for using their servers. You might not have noticed until now because there's a lot of free email options (ie. Gmail). But people get stingy when you want to bring a custom domain. You should keep this in mind as you choose an email hosting service. You probably wish you were told this back when a custom domain seemed so magical. I chose Zoho Mail because they offered the most under their free custom domain email plan.
• To connect your domain name servers to your email hosting servers, you need MX records. Your email hosting service will have an instruction page about these records. You're looking for records like @ - mx.zoho.com - 10, @ - mx2.zoho.com - 20, @ - mx3.zoho.com - 50. You'll probably need other records too, like a TXT record to prove you can add more records. You must use the buttons back at your registrar's web interface, or wherever you let your domain records be managed, in order to create these records.

CLOSING THOUGHTS a

That's pretty much it! Not too bad when you realize it's all about choosing services and connecting them with domain records.

...That's the optimistic view. I actually think the experience paralleled many painful parts of software development:

• Digging for specs - Landing page fatigue was real. All I really wanted to know was how much service A charged compared to service B, and with what storage limits, and to what extent I could control my data. I realized all the other content and web design just got in the way.
• Paralysis by analysis - you can spend weeks just mulling over recommendations from sources like HackerNews, which is great for finding quality and authentic and objective info, and great for learning, but not great if you ever need to get out of the rabbit hole.

  I got out after researching ~15 of the most popular email hosting services that showed up in recommendation threads. At some point you just have to pull the trigger and hope you commit to the least flawed or limiting service, and that's tough as a beginner who's heard how other people have been burned and doesn't want his own tender self to get burned. Maybe I research too much.

• Layers of knowledge and abstraction - not too bad like it would be if I was developing software, but still present.

  Big email providers like Gmail make it seem like email is universal and free all the time; you never have to worry about domains or records or servers. Then at some point when you own a domain, you learn about DNS and how records point servers to other servers. You'll need to know about a few main record types - CNAME is for mapping domain to content, MX is for email, TXT is for arbitrary information.

  That's about where I stopped, but that's just the beginning - there's other related topics like DNS resolution, spam filtering, protocols like POP and IMAP and SMTP, HTTPS and SSL (which thankfully was one-click for my site), and so on. Thankfully I shouldn't have to care since my services abstract those away. Maybe POP/IMAP for email forwarding, if I feel like it. I envy the older programmers who grew up with the technology. It's as if they started at technology bedrock and naturally floated along time to the surface. I was born at the surface, trying to balance between drilling down for understanding and still getting work done at the top levels of abstraction. It's tough.

• Managing tradeoffs - some give-and-take between convenience, flexibility, power, and money.

  For example: basic Gmail is convenient and takes little time to understand and use, but having the flexibility of a custom domain takes time and money to set up.

  Or another: you could replace all these services like Netlify and Zoho by self hosting on your servers, but then you'd have to manage it all and fix bugs and think about security and bear whatever other headaches they bring. Now I view most tech services as 'headache bearing as a service', HBaaS, and I'm beginning to realize how much I'll give for them to take my headaches.

FOOTNOTES a

1There's a bunch of tips to learn about choosing domain names and registrars. For example: you might try a clever spin on your nickname jwong, like jw.ong, but it would not be feasible because .ong is for special non-profits, and you would have to prove your non-profit status to someone, somehow.
And jwo.ng may not be great either because .ng is for Nigeria, and you would be subject to the policies of a smaller registrar based in the area, which can apparently include revoking your domain for no good reason, at least according to other people's experience, and so you should probably stick with more common TLDs and registrars.
And so you resort to something less clever, like jwong.com, but that would not work because there you find a quaint little website, and you look up the WHOIS info and see wow it's from 1997 and there's some contact information, but that sounds like a dead-end because surely many other jwongs have tried and failed in these 26 years, and you start to feel a little guilty for coveting this domain because the website appears to be a family memorial page of sorts, although something has been lost in translation, and clearly somebody cares enough to keep renewing the domain, and you're familiar with the taste of defeat at this point, and so you accept that jwong.com is untouchable.

But that's a personal journey of sorts, depending on your domain name. I found registering a domain name to be the easy part. The rest was annoying and confusing and harder to understand.

2** Doubly optional website step: your website host might want to manage your domain records in place of your registrar. They might convince you by using words that sound nice, like deploys and support and CDN. You might be swayed, especially if you weren't impressed by the button-finding experience back at your registrar. If you choose to do this, your host will give you new name servers (NS records) to plug back in to your registrar, like dns1.p01.nsone.net and dns2.p01.nsone.net. This means finding more buttons. The buttons you found back at the registrar will not be useful afterwards. Your hosting service will have their own web interface with buttons for managing your domain records from now on. You must find this interface and its buttons, hidden among all the hosting buttons already crowding in, to move on.