DKIM, SPF, MX, and other email DNS records

At face value email seems pretty simple I write an email and address it to your email address. My provider then talks to your provider and the email I wrote ends up in your inbox. If you want to reply you just hit the "reply" button and the same thing happens to me. Simple, right?

It's not until you want to use a custom domain, self-host, or change providers. At that moment you peak behind the curtain and realise the decades of legacy decisions stack ontop of each other.

Unfortunately many non-IT folks run into this seemingly insurmountable wall. All they want is an email address on their own domain for their own business and suddenly they're met with DNS records galore with no real idea of what they are.

This article acts as a short reference piece for all of the major email DNS records you might come across. It's not a guide on how to host your own email or what provider to use. It's here to help you understand what all those DNS records are that you're being asked to configure.

We'll be working with the domain of example.com in our examples.

MX - Mail Exchange

This is the oldest email DNS record around and it provides people with instructions on where to send email for your domain. This is how someone knows what mail server to speak to when sending you an email. To receive email this is all you need to have setup!

An MX record has four parts.

1. Sub-domain - Typically you'll set this as @when you want to target the root of the domain for addresses like [email protected] but you can set it to a value such as mail to get addresses like [email protected].
2. Value - This is the full domain of the mail server you want to target. For example mail1.example.com. When someone wants to send you email this is the server they'll speak to.
3. Priority - We often try to have at least 2 MX records for any domain or sub-domain. This gives us redundancy, so that if one mail server goes down, people can send email to the other one so your email still gets to you. Your email provider will tell you how to set this, usually we go with increments of 10 so your first record will have priority 10 and the second will have priority 20.
4. Time to live - This is standard across all DNS records. When a system requests a DNS record it will keep a copy of it for the amount of time specified in this time to live value. Until that time has elapsed it won't request it again. If you're going to move to a new email provider it's a good idea to set this down to around 1 minute and wait for all old requests to have timed out. IE if you previously had it set to 4 hours, set it down to 1 minute and wait just over 4 hours.

SPF - Sender Policy Framework

Back when email was first created and used there weren't many people on the internet. As such we could trust people to only try to send email from their email address. As the internet grew in usage this obviously became a problem. Anyone could contact a mail server (via an MX record) and claim to be anyone else and send an email. The SPF record prevents this by specifying what mail servers are allowed to send email on behalf of the domain.

Why is this better? Because the SPF record is setup by the domain owner, you know that the domain owner has authorised the given mail server to send email with their domain name. Now, when a mail server receives an email it will request the supposed senders SPF record and check that the incoming email is being sent from an authorised sender.

The SPF record is not it's own DNS record type, instead it uses the TXT (text) record type in a special prescribed format. A very simple SPF record might look like this:

v=spf1 include:spf.example.com -all

• v=spf1 - This is the identifier for someone to know that this is an SPF record.
• include:spf.example.com - This is the domain of a 3rd party authorised email server. You can add as many of these as you need, but should only add those which should be sending email on your behalf. You can also include servers via IP addresses which is useful if you run your own email servers.
• -all - This bit is a little cryptic, it instructs the receiving mail server what to do should an email be sent to it which is not authorised by this SPF record. -all says it should be rejected, ~all would have it go into the receivers spam folder, and ?all would allow anyone to send email on your behalf. Typically it is best to use -all.

You may only have one SPF record per sub-domain / root domain. That means if you need to authorise more services to send email on your behalf, you'll need to expand your existing SPF record or make them use a sub-domain such as marketing.example.com.

SPF has been around for a long time now, if you do not set it you're likely to have your emails either end up in people's spam folders or outright rejected. Fighting email spam is hard and if a receiving server cannot find out who is allowed to send emails on behalf of a domain it will decide what it wants to do for it's users.

DKIM - DomainKeys Identified Mail

If an SPF is a declaration of who is authorised to send email, DKIM is the proof that comes with each email sent. DKIM uses public key cryptography which we won't go into here. The only thing you need to know is it uses two keys: a private key which is kept secret by the owner, and a public key which is shared with anyone. In this case the private key is used to create a digital signature for an email and the public key can be used to verify the signature.

The DKIM DNS record is used to share the public key with the world. When an email arrives the receving mail server checks to see if there is a DKIM record for the senders domain and if so it attempts to verify the emails signature. If the signature doesn't exist or doesn't pass verification then it's either sent to the users spam folder or rejected completely.

Like an SPF record, a DKIM record uses the TXT DNS record type with a special text format.

A DKIM record will have a name such as ._domainkey.example.com for a root email address such as [email protected]. For emails on a sub-domain it'll be something like mail._domainkey.example.com for emails coming from [email protected].

The value of the record will look something like:

v=DKIM1; p=76E629F05F709EF665853333EEC3F5ADE69A2362BECE40658267AB2FC3CB6CBE

• v=DKIM1 signals that this is a DKIM record
• p=... is the public key which can be used to verify an emails DKIM signature

Alternatively, you can use a CNAME record type rather than a TXT record. This is used when you're using a 3rd party to host your email for you, in that case the target value will be given to you by the email provider. When a mail server meets a CNAME DKIM record it will forward it's request onto that target to find the key.

It is possible to have multiple DKIM records which can help you rotate your signing keys for improved security. How to do that is outside the scope of this article, if you're using a 3rd party provider they will tell you how to setup the DKIM records if they support it.

DMARC - Domain-based Message Authentication Reporting and Conformance

The DMARC record instructs a receiving mail server on how to react to emails that fail SPF or DKIM checks.

The DMARC record allows you say something like "if an email fails DKIM and SPF, mark it as spam" or "if an email fails DKIM and SPF, reject the email completely". There are a number of controls in a DMARC record and much like an SPF and and DKIM record it's a TXT record type that follows a particular format so they can be machine readable.

The name for a DMARC record is just @ to target the root domain or the name of the subdomain you're sending from. Then it's onto the value, there are a bunch of options in a DMARC record all of which can be composed together to create your desired policy. Each option is separated from the rest via a semi-colon and space. Here's an example:

v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:[email protected];

DMARC has a lot of different options. We'll explore some of the common ones you'll want to set. If you want to see all the available options, this site has a good list.

• v=DMARC1; - this is required, much like the DKIM and SPF records this denotes that the record is a DMARC policy. It must be included and is usually the first item in the value field.
• p= - This is the main "policy", it determins what happens if DKIM or SPF fail. These are: none (do nothing special), quarantine (send to spam), and reject (reject the email and do not deliver it). You will likely want quarantine at least or reject once you're happy everything is setup correctly. Bare in mind that email providers may choose to ignore these in some cases, it's been known for providers like gmail and outlook to take a more harsh action on emails failing DKIM and SPF even if p=none.
• rua= - The Report URI Aggregate option lets you specify a URL to send aggregate DMARC reports to. Setting this to something like mailto:[email protected] will mean you get daily emails from providers who receive your emails with an aggregate report of the SPF and DKIM checks. This is optional but it's a good idea to set it up so you can analyse any delivery issues that come up. This can be any URL, if you prefix it with the mailto: protocol then it'll be emailed to the given address. I generally setup a separate mailbox or folder for these to go to.

Final notes

MX, SPF, DKIM, and DMARC are the minimum records you'll want when setting up email for your domain. Without them you open yourself up to having people sending emails pretending to be you, or not receiving email intended for you.

It's worth noting here that email providers will take some of these, in particular DMARC with a grain of salt. If you don't setup these records, you're more likely to end up in someone's spam folder because you've failed to protect your domain and so providers will trust you less. There's always the chance that they enforce a stricter policy than what you've prescribed, although on the whole your DNS records should be respected. DMARC reports should help you solve most issues, and if you're using a reputable 3rd party you shouldn't have IP reputation issues (which is a whole other kettle of fish).