Mail server DNS records explained

If you want to run a mail server on the public internet, you need to set up your DNS records correctly. While some DNS records are necessary to send and receive emails, others are recommended to build a good reputation. Why is that so important? Because Spam-Mails are a big problem, most public mail servers just reject mails from servers with a bad reputation. In this article, I explain to you which DNS records you should configure to run a fully functioning mail server with a good reputation.
Watch the Video

Set up an A record for your mail server 

I strongly recommend adding a separate A record that will resolve to the public IP address of your mail server. You could use an FQDN, for example. This is also needed when your web server has a different IP address than your mail server. 

In the following example, you can see how the mail server’s address is configured for the domain 

Set up an MX record for your mail server 

The MX record is important when you want to receive emails. This tells everyone which IP address to contact. Let me do a short example. Let’s assume you’re running a mail server for the domain If someone wants to send you a mail to christian(at), the foreign mail server needs to contact the correct mail server via its IP address. Therefore, the sender’s mail server will first look up the MX record (Mail Exchanger) on your DNS server. That tells the sender which mail server is responsible for the domain 

The MX record resolves to your mail servers, A record. Enter the mail server’s FQDN (Fully-qualified-domain-name) that will resolve to the mail server’s public IP. In the following example, you can see how the mail server’s address is configured for the domain 

Set up an RDNS record for your mail server 

The reverse DNS record or also called PTR (Pointer Resource Record) is important when you want to send mails. Almost all mail servers check the RDNS record to perform simple anti-spam checks. How does that work? RDNS is just like a DNS query, just backward. The receiving mail server will perform a reverse DNS lookup on your IP address and check if it’s matching your mail server’s FQDN. If you don’t have a matching RDNS record on your public IP address, that looks suspicious. In this case, most mail servers will just reject your mails with an error code PTR 554 or drop them silently. 

Note, that your RDNS record is not configured on your DNS server, instead, it’s configured on your hosting provider where you got your public IP address from. In the following example, you can see how the mail server’s FQDN is configured on my public address. 

Set up SPF, DKIM, and DMARC for your mail server DNS records 

Probably not all mail servers will reject your mails when one of these records is missing. Nevertheless, you should configure them all to build a good reputation for your mail server. Because some mail servers just reject emails silently without sending you an error code. Do your best efforts to make sure everybody is receiving your emails and set up SPF, DKIM, and DMARC records. 

SPF (Sender Policy Framework)

Why do we need an SPF (Sender Policy Framework) record? The problem is that you can send mails with any sender address by modifying the “envelope from”, even if the domain doesn’t belong to you. This is called spoofing and is a common vulnerability. The SPF is a TXT record on your DNS server that specifies which hosts are allowed to send mails for a given domain. When a mail server receives mail that seems to come from your domain, it can check if it’s a valid message. Some mail servers reject mails if they can’t validate that the message comes from an authorized mail server. 

To set up your SPF record, create a new TXT record for your domain v=spf1 ip4:<your-mail-server-public-ip> -all. In the following example, you can see how the mail server’s SPF record looks for the domain 

DKIM (Domain Key Identified Mail)

SPF is a good way to protect against spoofing, but it has some limitations. DKIM (Domain Keys Identified Mail) allows the receiving mail server to check that an email was indeed sent by the owner of that domain. The sending mail server adds a digital signature to every mail that is sent. This DKIM signature is added as a header and secured with encryption. These signatures are not visible to the end-user, it’s all done on the mail servers. The sending mail server generates a random hash value that is encrypted via a private key and adds it to the DKIM signature. The receiving mail server checks if the DKIM signature is valid by obtaining the corresponding public key on the sender’s DNS server. 

If you want to add DKIM to your mail server, you first need to create a private and a public key pair. When creating your DKIM key, you also need to configure a DKIM selector on your mail server. Only your mail server should know the private key, don’t share this with anyone! Then you need to create a TXT record for the host <dkim-selector>._domainkey with the value v=DKIM1;k=<rs>;p=<public-key>.

In the following example, you can see how to create a DKIM key on the Mailcow server. 

If you’re not using the Mailcow server, you can use a free DKIM generator like

This is an example of how to create the DKIM record on your DNS server. 

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC (Domain-based Message Authentication, Reporting, and Conformance) extends your existing SPF and DKIM records. It makes sure that the sender’s emails are protected by SPF and DKIM, and tells the receiving mail server what to do if these checks fail. 

To set up your DMARC record, create a new TXT record for the host _dmarc with the value v=DMARC1;p=<policy>. The policy argument tells the receiving mail server what it should do with a mail if it fails DMARC. You can set this to either “none”, “quarantine” or “reject”. There are some other optional arguments you can use to send daily reports or a specific percentage of suspicious emails the DMARC policy should apply to. You can find more details about all the different options in my DMARC cheat sheet. 

In the following example, you can see how the DMARC record looks for the domain 

Set up autoconfiguration DNS records for your mail server 

If you’re using mail clients like Outlook, Thunderbird on your Computer, or Mobile devices they offer the ability to do an “autoconfiguration” also called Auto-discover. That means you just need to enter your email address and password and the mail client tries to resolve the mail server IP addresses, used ports, and encryption settings for IMAP and SMTP. You can achieve this by adding SRV DNS records that are defined in the RFC 6186 standard and some specific records that are used in Outlook clients. 

In the following example, you can see how the autoconfiguration records look for the domain 

This is an example of how to create such a record for the _autodiscover record used in Outlook clients. 

How to check if your DNS records are configured correctly on your mail server? 

Now you should be able to send and receive mails, your domain is protected against spoofing and your mail clients can be configured via auto-discovery. To check your mail server DNS records, you can use a diagnostic tool like

It can check if you set up all your DNS records correctly and also perform other checks, f.e. the blacklist check. This reveals if your mail server’s IP is blacklisted, which could be problematic when you want to send mails.