---
title: "Selfhosted email: DNS records"
author: Yarmo Mackenbach
slug: email-dns
date: "2020-02-18 18:39:54"
published: true
---

When selfhosting email, an essential element to get right are the DNS records. Some are absolutely mandatory for email to work, some build trust and some just make life easier. Here's an overview of how I set up DNS for my personal mail server.

<!--more-->

## My setup

I have a VPS server running [mailcow](https://mailcow.email/) and two domains: one linking to the mail server, admin page and the web client (let's call this `mail.server.domain`), and the other just being a email domain used in the email address (let's call this `public.domain`, so the email address would be `hi@public.domain`). This way, even if you know the email domain, you don't directly know server domain. Granted, one could find this out by looking at a few DNS records.

The benefit is that I can host email for multiple domains, as long as they all point to `mail.server.domain` by using the correct DNS records.

Please note that using a single domain is just as easy, as `mail.server.domain` and `public.domain` will simply be the same. Another scenario for which you could use the 2-domain setup is when you want your email address to be `hi@public.domain` (without subdomain) but wish to put the mail server (and/or web client) on `mail.public.domain` (with subdomain).

I use [DigitalOcean](https://www.digitalocean.com/docs/networking/dns/) as my VPS and DNS server.

## Mandatory DNS records for server.domain

### A records

A records link domain names to IP addresses. When you want to use the admin page or web client provided by your email selfhosting software, the browser needs to know the IP address of the server/VPS and that is what the A record is used for. A records are not used by mail servers when sending or receiving emails.

```
TYPE  HOSTNAME            VALUE    TTL
A     mail.server.domain  1.2.3.4  3600
```

## Mandatory DNS records for public.domain

### MX records

MX records tell other mail servers where to actually send the emails. In my case, my email address is `hi@public.domain` but my mail server is located at `mail.server.domain`. Other mail servers look at the address, see `public.domain` and will assume this is our mail server. We use MX records to direct the emails to `mail.server.domain` instead.

```
TYPE  HOSTNAME       VALUE               PRIORITY  TTL
MX    public.domain  mail.server.domain  1         14400
```

## Optional DNS records for public.domain

A and MX records is all you need to get a functional email address. However, for ease of use and good reputation/trust, a few additional DNS records are recommended.

### SRV records (ease of use)

SRV records are used to link specific protocols to specific domains and ports. Just like how MX records tell other mail servers to direct their mails to your mail server on a different domain, the same must be done for mail clients. Say you want to use Thunderbird (or any other mail client) to access your emails. You will log in with your address (`hi@public.domain`) and password in Thunderbird, and it will then assume your mail server must be located at `public.domain`. It will not find it there, warn you about this and you will have to manually enter your IMAP and SMTP server details. If you have set up SRV records, Thunderbird will automatically detect the correct server location (`mail.server.domain`) and save you some hassle.

```
TYPE  HOSTNAME            VALUE               PORT  PRIORITY  WEIGHT  TTL
SRV   _imap._tcp          mail.server.domain  143   1         100     14400
SRV   _imaps._tcp         mail.server.domain  993   1         100     14400
SRV   _pop3._tcp          mail.server.domain  110   1         100     14400
SRV   _pop3s._tcp         mail.server.domain  995   1         100     14400
SRV   _submission._tcp    mail.server.domain  587   1         100     14400
SRV   _smtps._tcp         mail.server.domain  465   1         100     14400
SRV   _sieve._tcp         mail.server.domain  4190  1         100     14400
SRV   _autodiscover._tcp  mail.server.domain  443   1         100     14400
SRV   _carddavs._tcp      mail.server.domain  443   1         100     14400
SRV   _caldavs._tcp       mail.server.domain  443   1         100     14400
```

### TXT records (good reputation)

TXT records are simply messages that provide additional information. Here, TXT records are used to tell other mail servers more about your own mail server in order to build some trust between them: these records are a useful tool against spoofing where bad actors try to impersonate you and pretend you are sending the bad emails they are sending.

```
TYPE  HOSTNAME         VALUE
TXT   @                "v=spf1 mx ~all"
TXT   dkim._domainkey  "v=DKIM1;k=rsa;t=s;s=email;p=..."
TXT   _dmarc           "v=DMARC1;p=reject;rua=mailto:admin@public.domain"
```

Detailed information on these records can be found [here](https://www.skelleton.net/2015/03/21/how-to-eliminate-spam-and-protect-your-name-with-dmarc/), but in short:

- SPF records tells other mail servers that only the specified mail server (in this case, `mx` which points to `mail.server.domain` via the MX record) is allowed to send emails for your email domain (in this case, `public.domain`);
- DKIM applies a virtual signature to all your sent emails and other mail servers use the second TXT record above to validate that signature;
- DMARC records tell other mail servers what should happen to emails that fail the SPF and DKIM policies; the record above states these emails should be rejected and a notification sent to `admin@public.domain`.

The DKIM record contains a cryptographic key (replaced above by `...`). In my case, this key was generated for me by mailcow and is unique for each email domain.

Please note that having the above TXT records does not guarantee that other servers trust you immediately: your emails are still likely to end up in spam folders at first. Using intermediaries like [mailgun](https://www.mailgun.com/) can help with avoiding the spam folder. More on that in a later blog post.

## References

Mailcow has their own [recommended DNS records guide](https://mailcow.github.io/mailcow-dockerized-docs/prerequisite-dns/) which, in conjunction with their admin page, should make setting up DNS records a breeze.

[This guide](https://www.skelleton.net/2015/03/21/how-to-eliminate-spam-and-protect-your-name-with-dmarc/) has a lot of in-depth information about the SPF, DKIM and DMARC records (TXT records above).