Leon Mika

There are growing concerns, in the circles that I travel in, about the use of “free” email services like Gmail, that lock you into a service that may not have your whole interest in mind. The remedy for this is to use an email address with a domain that you control. Setting one up can seem a little daunting for those have haven’t done this: thanks to the wild west that is email, a hodgepodge of technologies have grown up in an attempt to stop the occurrences of spam and impersonations. The result is a series of DNS records that have to be set up for each email domain; each one that needs to be done correctly, lest your emails get rejected or your domain gets blacklisted.

I say this as someone that has experienced this myself: not only for my own domain, but also for a bunch of other domains that I was responsible for. As such, I had to have some understanding as to what each of these record types actually were. After a bit of experience doing this a few times, along with reading up on what these records are actually for, it felt right to put together this tour for anyone else looking to do the same.

This is by no means a complete how-to for setting up a new email domain, but rather a guide of the types of domain records that you will be dealing with. It is assumed that you, dear reader, are setting up a new email domain for use with an online email service, such as FastMail, Protomail or Hey.com. These services should have the tools and documentation detailing the specifics on how to setup a domain for their service. Each service might have slightly different requirements, so it’s always a good idea to read their instructions carefully, and give it a test before sharing your new email address around. Those setting up their own mail server fall beyond the scope of this post, although the general aspects will probably be applicable here as well.

So, without further ado, here are the domain records you’ll need for email.

MX: What Servers Should Email For Me Be Sent To?

The MX, or Mail Exchange record, is the simplest record to understand. It identifies the mail server that should be used to receive email that is addressed to you. Sending an email to someone@example.com, for example, will trigger the mail client to open a connection to one of the hosts listed in the MX for the example.com domain, in order to transmit the message.

Mail exchange hosts are specific by adding a domain record with the MX type¹. The value will consist if a number which indicates a priority, followed by a hostname or an IP address, e.g. 10 smtp1.mailserver.example.com. It’s possible to list multiple MX records for a single domain, with each one having a different priority. In general, a MX record with a lower priority will take precedence over one with a higher one.

SPF: What Servers Are Allowed To Send Your Emails?

SPF, or Sender Policy Framework, is a mechanism for declaring whether a specific mail server is permitted to send emails for a particular domain. It is used by remote mail servers receiving emails from your domain to confirm that they are coming from a mail server that you know about and have authorised to send emails on your behalf. The policy part are the rules governing this, and it’s up to the domain owner to specify what these are. The rules themselves are are quite expansive; and can include things like how to handle email that did not come from a server that you control – as would be the case for email sent from spambots pretending to be from you — along with referencing policies defined in another domain.

A SPF policy is declared for a domain using a TXT record type². The value will be something that starts with v=spf1, followed by the actual policy specific in a simple domain specific language. The mail service that will usually indicate what you should use for an SPF policy, and there will usually be one SPF record for each email address domain.

SPF itself does not given total protection over those attempting to impersonate a sender from your domain. It will only verify that the email “envelope” is from the domain that you can control. But a single email may be transmitted via multiple servers, with each of these “hops” using a new envelope and thereby being subjected to a different SPF policy. We need one more thing to verify the original message end-to-end.

DKIM: Is The Email Really From You?

DKIM, or DomainKeys Identified Mail, verifies that the actual message itself is really from you. Once the email reaches the final destination, the receiving mail server can confirm that the message is from you using the DKIM records that are stored against that domain. The specifics on how this is done is beyond the scope of this post, but the short version is that a cryptographic signature is created when the mail is sent, and the receiving mail service can use the public keys stored in the DKIM records to verify that the signature is correct.

DKIM records can either be TXT or CNAME records. They will usually have names like <something>._domainkey; and either a large value beginning with v=DKIM1 if they are a TXT record, or a reference to another domain if they’re a CNAME records. You may get two or three DKIM records for each domain that you register, each one with a slightly different names.

It should be noted that this is not the complete list of domain records that are available for dealing with email. This is also DMARC which extends these two policies, and is available if required. I personally have not had to set up a DMARC record for the domains that I had to deal with, so there is not much I can say about it.

I hope you found this post useful. General information about the various technologies required to setup a domain for email delivery was hard to come by, and I’d wish a post like this was available to me when I was first learning how to do this.