Selfhosted email: DNS records
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.
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
email@example.com). 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
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
firstname.lastname@example.org (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 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 188.8.131.52 3600
Mandatory DNS records for public.domain
MX records tell other mail servers where to actually send the emails. In my case, my email address is
email@example.com 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
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 (
firstname.lastname@example.org) 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:email@example.com"
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,
mxwhich points to
mail.server.domainvia the MX record) is allowed to send emails for your email domain (in this case,
- 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
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.
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).