In this ~lite episode of Chit Chat Across the Pond, Bart Busschots explains why it’s a good idea to have an email address on your own domain. Then he digs deep into all of the different technologies involved in owning a domain, forwarding email, explains MX and NS records, and how to make sure you’re never caught up in a spam scam. After digging deep, he then brings us up a level and explains the easy things you can do to have email forwarding that might protect you from some problems. I’ve worked my way through all of the technologies that Bart described, but I didn’t understand a lot of it until Bart explained it in this episode of Chit Chat Across the Pond.

mp3 download

Email on Your Own Domain — The Moving Parts

Thanks to Google finally kicking those of us with grand-fathered-in free G-suite accounts on our own domains out, both myself and Allison have recently been on the lookout for a new email provider for email addresses on our own domains. As a general rule, what ever nerd thing I’m spending mental energy one ends up as a Chit Chat Across the Pond, so here we are 🙂

I actually think this is a very important topic though, because if you’re not running your digital life from an email address on a domain you own, I think you’re living more dangerously than you realise, and I urge you to consider getting your own domain for your emails.

Why Bother? What’s Wrong with Free Email Services?

Configuring your own email domain is not hard, but it can be a little fiddly, and it is guaranteed to cost you money. There are also more free email services out there than you can shape a proverbial stick. This begs a very obvious question — why bother?

Simply put — reliable access to the email address(es) we use online is viral to our digital health. We rely heavily on email to secure our online lives — just about every website signup requires an email validation loop, almost all security alerts one of our accounts comes under attack arrive by email, and the vast majority of password resets are via email too. If we lose access to our email, we lose control of our digital selves, so we need to protect ourselves from that eventuality.

If your email address is not on a domain you own, you’re at the mercy of the domain’s owner for continued access. If you pay for a service you’re less likely to run into problems, but ultimately, if the company tells you to go pound sand, you’re powerless. On a spectrum, a free account from an online provider leaves you the most powerless, a paid account on someone else’s domain, e.g. an @icloud.com address is better, and an email address at your own domain is best.

When you own your own domain, you can choose who your email provider is, if a specific provider gives you trouble, you simply point your domain at a different provider and carry on. The worst case scenario becomes losing access to old emails, but you’ll always have the ability to start receiving emails again quickly, getting you back up and running in terms of account validations, security notifications, password resets, and so on. What would otherwise be a catastrophe becomes an annoyance and a bit of faffing around.

How Hard is it to Set Up?

If you’re the kind of person who listens to tech podcasts you’re the kind of person who should be able to get this up and running relatively easily. It’s more complicated than installing an app, but less complicated than installing WordPress on your own domain.

Broadly speaking, these are the steps:

1. Register a domain and arrange the hosting of its DNS records (usually a single step)
2. Purchase an email service (or configure your own server if you’re that kind of nerd)
3. Configure your domain to direct incoming emails to your email service
4. Configure your clients to read emails from your email service

How Does it Work?

Broadly speaking there are five important moving parts to an email service, and some optional extras:

1. Domain Registration
2. DNS Hosting for your domain
3. The MX record for your domain
4. A mail service (usually sold as a single package)
   1. A in-coming mail server that receives incoming email and stores them
   2. A mail service that allows you access to your stored emails
   3. An out-going mail server that allows you to send emails from your domain
5. Email Authentication DNS Records

Registering a Domain

Registering a domain does just two things:

1. it makes you the legal owner of the domain
2. it allows you to specify the DNS servers that will serve out the domain’s records

At the very highest level ICANN control the domain name system, but they delegate that control to appropriate authorities for each top-level domain. Depending on the domain those authorities can be government agencies or private companies. But we don’t need to worry about that, because none of these authorities want to deal with the general public directly, they’ll only deal with vetted intermediaries known as domain registrars. There are literally thousands of domain registrars, but there are a handful of more popular ones like GoDaddy who Allison uses, and Hover who I use.

As a little bonus extra, the whois terminal command lets you see the regisrary for any domain. The whois command takes one argument, the domain name to look up, and it returns a lot of metadata about the domain. To see just the registary metadata, look for lines starting with Registrar, e.g.:

bart@cc-lap-8re ~ % whois podfeet.com | egrep '^Registrar'  
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: https://www.godaddy.com
Registrar Registration Expiration Date: 2022-09-13T20:47:02Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +1.4806242505
bart@cc-lap-8re ~ %

To register a domain you create an account with a domain registrar, pay them an initial fee to register the domain, and then keep paying them an annual fee for as long as you want to retain your ownership of the domain.

Once you own the domain you can specify the name servers that will host the DNS records for your domain.

DNS Hosting

Before we get started, I need to disambiguate something — there are two completely different things that get referred to as DNS servers. Technical people can infer the difference from the context, but it’s not at all obvious to regular folks that the DNS server you configure in your network settings is in effect the inverse of the DNS server you configure in your domain registration. The DNS server you specify in your network settings is actually a DNS resolver, and it performs DNS queries on your behalf, that is to say, it seeks out answers to DNS questions. So where do DNS resolvers get those answers? They get them from the other kind of DNS server, the ones you configure in your domain registration, which are more correctly referred to as authoritative DNS servers. Authoritative DNS servers host the DNS records DNS resolvers use to answer DNS qestions.

So, within the context of this piece, DNS server is short-hand for authoritative DNS server, that is to say, a publisher of DNS records.

OK, so with that little bit of potential confusion dealt with, lets get back to our domain registration.

At a technical level, what owning a domain gets you is the right to specify the values for the domain’s NS (name server) records. These are DNS records hosted by the DNS servers for your domain’s top-level domain, and they delegate authority for your domain to the DNS servers of your choice.

For your domain to exist on the internet, there must be one or more DNS servers hosting its DNS records.

Let’s break that down with a specific example — the top-level domain for podfeet.com is .com, so the DNS servers for .com host the NS records for podfeet.com. Those NS records specify the servers that host the DNS records for podfeet.com.

Another little terminal bonus — you can see the NS records for a domain with the dig terminal command, e.g.:

bart@cc-lap-8re ~ % dig +short podfeet.com NS
elmo.ns.cloudflare.com.
pat.ns.cloudflare.com.
bart@cc-lap-8re ~ % 

This shows us that Allison has delegated control of her domain to Cloudflare, so it’s their control panel she must use to configure her DNS records.

In one sense Allison’s setup is unusual — she uses GoDaddy as her domain registrar, but CloudFlare as her DNS hosting, but it illustrates an important point, domain registration and the hosting of a domain’s DNS records are two completely different things, and you can use different providers for both.

The reason this is a little unusual is that almost all registrars offer free DNS hosting as part of the package. If you use GoDaddy or Hover to register a domain, by default they’ll set the NS records for that domain to point to their own DNS servers, so by default, it’s their control panels you’ll use to control the domain’s DNS records. But, if you use your registrar’s control panel to specify different DNS servers, then it’s those other DNS servers that are actually responsible for hosting your DNS records, and its their control panel you need to use to manage the records.

Your MX DNS Records

When someone sends you an email their mail client will hand the email to their out-going mail server, and it’s that server’s job to figure out what incoming mail server it needs to deliver the mail to. The way it does that is to split the email addresses at the @ symbol — everything to the right is the recipient’s email domain, and everything to the left is internal addressing information that’s only relevant to the receiving server. So for example, the email address [email protected] (not a real address 😉) is at the mail domain podfeet.com, and waffles+pancakes is only relevant to the incoming mail server for podfeet.com. Assuming that incoming mail server follows conventions, that would mean the mail should be delivered to a mailbox named waffles and either tagged with pancakes or stored in a folder named pancakes.

To determine the correct incoming mail server for a mail domain the sending mail server makes a DNS query for the receiving domain’s MX (Mail eXchanger) DNS records. For redundancy, a domain can have many MX records, and each will have an associated priority — a sending mail server will attempt the servers in priority order until it succeeds or runs out of servers to try. It’s perfectly normal to have multiple MX records with the same priority BTW, they’ll just be tried in a random order.

So, your MX record tells sending mail servers where to direct emails destined for your domain.

Again, we can use the dig terminal command to see the MX records for a domain:

bart@cc-lap-8re ~ % dig +short podfeet.com MX
10 mx01.mail.icloud.com.
10 mx02.mail.icloud.com.
bart@cc-lap-8re ~ %

This shows Allison is using iCloud as her incoming mail server, and Apple are running two servers, both with a priority of 10.

Your Mail Service

Generally speaking you’ll purchase mail service an pacakge, but it is useful to undesrtand that you’re actually getting three distinct functionalities as a part of that package:

1. Incoming mail server(s) capable of receiving emails address to your domain.
2. Mail storage infrastructure of some kind providing access to your mailboxes over one or more protocols (usually IMAP, but possibly also POP, and often with an optional web interface).
3. An outgoing mail server allowing you to send emails from your domain.

While it’s most common to get all of these things from one provider, it is possible to split this appart somewhat and get different services from different providers, but it’s not something us regular folk are likely to want to do. What is more common is augmenting the basic services offered by a primary provider with additional services from other providers (more on that later).

Something else that’s very common is getting email services as part of a bigger productivity suite that also includes things like hosted address books, calendars, and cloud storage. Things like Microsoft 365, Google Workspace, or for those looking for something a little cheaper, Zoho.

If you’re just looking for very basic email for one or two you have lots and lots of choice. Many of the domain registrars like GoDaddy and Hover offer basic email packages, so you may well be able to keep everything in a single control panel and combined into a single bill.

If you’re looking for something more robust that can handle more users and offers more storage many domain registrars and hosting companies also offer hosted versions of Microsoft Exchange, or managed Office 365 subscriptions. For example, the Irish domain registrar and hosting company Blacknight offer both Hosted Exchange and Office365.

As well as domain registrars, many hosting companies also offer email solutions, Rackspace Email for example. And finally, there are also some niche dedicdated email providers out there like the privacy-focused ProtonMail.

Email Authentication DNS Records (SPF & DKIM)

When you own your own domain, you’re responsible for managing its spam/bulk mail reputation. You want to be sure no one can abuse your domain to send spam.

Unfortunately, the SMTP protocol which is still used to send emails today is old, so old in fact that it dates back to the innocent early days of the internet where people were just happy stuff worked, and no one ever thought anything online would ever be abused by anyone.

Emails contain SMTP headers, and one of the things those headers specify is the email’s sender, but anyone can put anything they like into that header, and the protocol provides no means of authenticating that value. That means that anyone can send spam with a from address on your domain. If that starts to happen a lot, your domain’s reputation in various spam filters will begin to plummet, and you may even find your domain added to commonly used spam block-lists, meaning your legitimate emails are likely to end up in people’s spam folders, or even be blocked completely!

While the SMTP protocol remains unauthenticated, there are two commonly used DNS-based protocols that allow you to tell the internet which mails really are from you, and which are not. If you configure the needed DNS records, unauthorised uses of your domain will be silently ignored by spam filters, and your domain’s reputation won’t suffer, and your domain won’t appear on block-lists.

Basically — no authentication DNS records means you get blamed for everything, but the presence of records means you only get blamed for mails vouch for.

There are two technologies at your disposal — SPF & DKIM.

SPF

SPF is the Sender Policy Framework, and its designed to allow the owner of a domain instruct spam filters how to treat emails with from addresses on that domain originating from different sources. In effect, you use an SPF record to authorise your chosen email provider to send emails from your domain, and block all other sources.

SPF is implemented as specially formatted DNS TXT records. They have a well defined syntax, and you’ll recognise them because they start with v=spf1.

The syntax is very powerful, but also quite terse, so understanding SPF records take as little work, and composing your own can be fiddly, but thankfully you’re unlikely to need to. Why? Because any mail service provider worth giving your money to will tell you exactly what SPF record you should add to your domain, and unless you use multiple service providers to send email from your domain, you can just blindly copy-and-paste the record they give you. If you do use multiple providers, you’ll need to manually merge the two records into one single record that covers both.

You can list all the TXT records on a domain with the dig terminal command, and the SPF record will be the one starting with v=spf1

For example:

bart@cc-lap-8re ~ % dig +short podfeet.com TXT
"apple-domain=NZDLYeUbxtC1ONZ5"
"v=spf1 redirect=icloud.com"
bart@cc-lap-8re ~ %

As you can see Allison has two TXT records on the podfeet.com domain, it’s the second one that’s the SPF record. This is an interesting example because the record simply tells spam filters to go fetch the SPF record for icloud.com and use it for podfeet.com. So, let’s check that record:

bart@cc-lap-8re ~ % dig +short icloud.com TXT 
"google-site-verification=knAEOH4QxR29I4gjRkpkvmUmP2AA7WrDk8Kq0wu9g9o"
"v=spf1 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.110.0.0/15 ip4:17.142.0.0/15 ip4:17.162.0.0/15 ip4:17.164.0.0/16 ip4:17.171.37.0/24 ip4:17.172.0.0/16 ip4:17.179.168.0/23 ip4:144.178.36.0/24 ip4:144.178.38.0/24" " ip4:112.19.199.64/29 ip4:112.19.242.64/29 ip4:222.73.195.64/29 ip4:157.255.1.64/29 ip4:106.39.212.64/29 ip4:123.126.78.64/29 ip4:183.240.219.64/29 ip4:39.156.163.64/29 ip4:17.57.155.0/24 ip4:17.57.156.0/24 ~all"
bart@cc-lap-8re ~ % 

Again, Apple’s SPF record is the second TXT record on their domain, and this time it lists many authorised IP address ranges, and it ends with an entry telling spam filters to mark mails from every other source as spam (~all). Apple are being kinder to spammers than I expected, because they could also have chosen to end their record with -all which would instruct spam filters to silently drop mails from unauthorised sources.

It’s really important your have an SPF record on your domain, so make sure your mail service provider gives you one, and be sure to add it to your domain using your DNS control panel.

DKIM

DKIM, or DomainKeys Identified Mail is a mechanism for publishing public keys that match private keys your mail service will use to digitally sign the emails you send.

DKIM is much more complicated than SPF, and it generally requires multiple DNS records. If your mail service supports DKIM, they will provide the DNS records you need to add to your domain.

DMARC

SPF and DKIM are two different mechanisms for authorising emails, both were developed independently, and they’re not fully compatible with each other. Imagine your domain uses SPF to list trusted senders, and specifies that emails from all un-listed sources should be silently dropped. Imagine your domain also publishes a DKIM public key. Now, an email arrives at a spam filter that is correctly signed with DKIM, but from a source not listed in your SPF record. SPF says to silently drop, DKIM says to accept, what should a confused spam filter do?

To address the fact that we have two competing anti-spam DNS standards the internet community developed a third anti-spam DNS standard — DMARC, or Domain-based Message Authentication, Reporting and Conformance. Like SPF, DMARC records take the form of DNS TXT records, but you’ll recognise these because they start with v=DMARC1.

I consider DMARC an advanced feature, and entirely optional. I add DMARC records to domains that have just a single mail service provider that explicitly provides me with suggested DMARC records to add, and don’t bother on my other domains. On domains where I do more complicated things I prefer to stick to just SPF which is by far the must human-friendly of the three mail authorisation protocols.

Mail Filtering (An Optional Extra)

If you opt for a large bells-and-whistles mail service provider like Microsoft, Google, or Zoho, you’ll get good spam filtering as part of the service, but if you go for a simpler cheaper option you may not.

If you want to layer on spam filtering from another provider you can! The key here is your MX DNS record, instead of pointing it at your actual mail provider, you point it at your mail filtering service, and you configure that service to forward just the good mails to your actual email service provider.

I’ve never used a service like this, so I don’t feel comfortable making any suggestions, let alone recommendations! Remember, any company doing filtering for you simply has to be reading your emails or they wouldn’t be able to do the filtering, so make sure it’s a company you trust, and is not giving you this service for “free”. That’s freepi.

Bulk Mail Sending (Optional Extra)

If you’re using your domain to power a business or other organisation that needs to send out a lot of email, perhaps from a website you operate, or perhaps in the form of a news letter or even marketing blasts, you could find yourself running into rate limits imposed by your email service provider. In these situations that best value for money is often to be had by purchasing a dedicated bulk email service and connecting it to your domain as a second authorised sender.

There are lots of popular services out there specifically designed to send large quantities of email in a non-spammy way and abiding by industry best practices. This is how companies like Apple can send millions of notifications from their app store without being block-listed as spammers!

Personally, I have good experiences with SendGrid), but there are lots of quality offering available.

Legitimate bulk mail services will almost certainly require you to both update your SPF with additional entries to authorise their servers and add DKIM entries for the public key matching the private key they’ll use to sign all the emails they’ll send on your behalf. This means you’ll need to take a little time to actually understand your SPF record to make intelligent edits. If that seems like hard work, I have a very simple tip — send the emails from a sub-domain on your domain, that way you can add an entirely separate SPF record to the sub domain and leave the record on your primary domain well enough alone 🙂

A Cheaper Alternative — Mail Forwarding

If you only want to solve the problems described in the justification earlier, and if you’re OK only being able to receive emails on your own domain and not send them, then you can save yourself some money by using a mail forwarding service instead of a full mail service.

You would either sign up for a free forwarding service you trust, or pay for a commercial one, and point your MX record at that service. The service’s control panel would allow you to configure which addresses on your domain get forwarded where. This would allow you to keep your email in free accounts from the likes of Google or Yahoo, but still be able to sign up to services online with an email address you fully control that can’t be arbitrarily taken away from you.

The only forwarder I have had good experiences with is Forward Email — they’re a freemium service that respects your privacy, even on their free tier.

As Simple or as Complicated as you Like (and Changeable any Time)

Understanding all the moving parts is very helpful IMO, regardless of the solution you choose. On one end of the spectrum you can use a single provider for everything, on the other, you could use different providers for each part, and there’s a whole spectrum in between.

You could go to a registrar that offers email services like GoDaddy or Hover today and register a domain, add a mail service, and configure your DNS records all from within a single web interface, and all combined into a single monthly or annual bill.

Or, you could use different providers for each like Allison does — podfeet.com is registered with GoDaddy, the DNS is hosted by Cloudflare, and Apple are providing email services.

More importantly though, when you own your own domain you can change your provider for each part independently, and any time you wish.

Changing Email Service Provider

The mostly likely change you’ll want to make is your mail service provider, so it’s worth looking at that a little more closely.

The big-picture steps would be:

1. Open an account with a new provider
2. Add your account with the new provider into your mail client(s)
3. Update your MX record based on instructions from your new provider — this will start routing all new email to your new provider, effectively putting it live
4. Update your SPF/DKIM/DMARC records so your new provider is authorised to send emails from your domain
5. Optionally migrate your emails from your old provider to your new provider — that could be a manual drag-and-drop in your mail client, or, your new provider may offer a migration tool.
6. Terminate your account with your old provider
7. Remove your old account with your old provider from your mail client(s)

The mostly likely pain point will be migrating your existing emails from your old provider to your new provider. You could of course choose to use the move as an excuse to do a little spring cleaning and fight back against the hoarding mind-set by simply letting all those emails go, but like me, you probably won’t 🙂

Final Thoughts

To really be secure online you need your email address to be at a domain you own. It’s not zero effort to do that, but it can be both cheap and simple if you’re happy with just a basic service. But, once you do own your own domain, the world is your oyster, and you can migrate to more advanced setups any time you like without ever needing to change your email address.

If you don’t already have your own email domain, I hope I’ve inspired you to at least consider the possibility!