Selfhosted email: DNS records
Date
Tags
#selfhosting
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.
My setup
I have a VPS server running mailcow 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 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, but in short:
- SPF records tells other mail servers that only the specified mail server (in this case,
mx
which points tomail.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 can help with avoiding the spam folder. More on that in a later blog post.
References
Mailcow has their own recommended DNS records guide which, in conjunction with their admin page, should make setting up DNS records a breeze.
This guide has a lot of in-depth information about the SPF, DKIM and DMARC records (TXT records above).