Problem

I set up an MX record and my mail doesn't work, why?

Solution:

Below we list the most common mistakes when it comes to problem solving MX records and SMTP email delivery.

Solution 1 - CNAMEs:

MX records themselves need to point to hostnames.  These hostnames can either be A or AAAA records, but not CNAME records.  MX records need to point directly to a hsot value and not an alias of that host by means of a CNAME. Likewise you can not enter an IP Address for a MX record either, it must be a hostname.  All hostnames must point to valid IP addresses with the appropiate A (IPv4) or AAAA (IPv6) record.

Bad Example 1.1

You create a MX record called mail.example.com for the domain example.com but mail.example.com has no IP address because there is no A or AAAA record for mail.example.com

Bad Example 1.2

You create a MX record called mail.example.com for the domain example.com but mail.example.com is in fact a CNAME to record called mailserver.example.com which has A or AAAA records.  Although this looks okay because there are correct A and/or AAAA records for mailserver.example.com, and there is a correct CNAME record mail.example pointing to mailserver.example.com.  The use of the CNAME in the MX record is invalid.

Solution 2 - Trailing dot

This can confuse a lot of poeple.  A lot of DNS portals will happily accept hostnames and FQDN (Fully Qualified Domain Names) in records, including MX records.

The portal then naturally assumes that value is part of its domain name unless the value ends with a "."

Example 2.1 - No Trailing dot

You create an A record called mailserver and point it to a valid IP Address (x.x.x.x)

You create the MX record and enter the value "mailserver"

The DNS service and its portal naturally assume (correctly) that the value "mailserver" is part of the domain name (example.com) so the fully qualified value of that MX record becomes mailserver.example.com

In this example we can see that this is perfectly correct and valid.

Example 2.2 - No Trailing dot

This example is similar to the above example (2.1) except this time we are delivering the email to a mail server thats not part of the domain name (example.com).  In fact in this example we will assume the emails are going to be delivered to profilter (Cloud based email spam filtering solution)

The DNS service and its portal still assume (correctly) that the value "mxXXXX.smtp-engine.com" is a subdomain part of the domain name (example.com) so the fully qualified value of that MX record becomes mxXXXX.smtp-engine.com.example.com

Because there was no trailing dot (".") on the record it assumes its a subdomain and therefore appends to the end the domain name.

So this example emails would not be delivered as the record mxXXXX.smtp-engine.com.example.com doesn't existing

Example 2.3 - With a trailing dot

This example we can see that this is perfectly correct and valid.

This example is similar to the above example (2.2). We will still deliver the email to a 3rd party mail server thats not part of the domain name (example.com).  We will still assume the emails are going to be delivered to profilter

You create the MX record and enter the value "mxXXXX.smtp-engine.com." - Note the trailing "." on the end of the value.

The DNS service and its portal now know that because there is a trailing dot it is already fully qualified and will not append the domain name on the end as well. So the fully qualified value of that MX record is mxXXXX.smtp-engine.com.

Because there was no trailing dot (".") on the record it assumes its a subdomain and therefore appends to the end the domain name.

Solution 3 - Correct Value

Sometimes the obvisous answer is often the best, but have you entered the record correctly.

Checked the spelling of the record?

Solution 4 - Firewalls

So you have all the DNS records setup correctly but still not receiving emails?

Check the firewall settings and any necessary port translations.

Typically email is delivered to a mail server on TCP Port 25.  This is the default TCP port that mail servers use to forward emails to another email server.  However if your mailserver is on the private LAN behind a firewall you need to check the firewall settings

• Check the firewall allows traffic from port 25 to the server
• Check the firewall allows the mailserver to send traffic out on port 25 as well.
• Check port transaltions from the real public IP address are going to the correct private local LAN IP Address

Solution 5 - ISP

Some ISP (Internet Service Providers) block, filter or redirect SMTP traffic.  Sometimes to enable SMTP email to your domain its actually an upselling service by ISP which removes the block, filter or redirect.

If in doubt, always ask your ISP the following questions

1. Do you block, filter or redirect SMTP traffic?
2. Do you allow the sending of emails using my own domain name? 
   Ie. sending an from This email address is being protected from spambots. You need JavaScript enabled to view it. rather than having to send an email using This email address is being protected from spambots. You need JavaScript enabled to view it.

Solution 6 - MX records in the wrong order

This is a common mistake as well, because people often assume (incorrectly) that the higher the MX priority number is the higher that mailserver is.

Wrong...

MX priority number can between 0 and 65535, but the lower the number the higher the priority for delivery.

Example 6.1 - Correct MX Priorities

You have two mailservers for the domain example.com.  A primary mailserver called mail1 and secondary backup server, in this case we will use the hosted service backupMX (mxXXXX.smtp-engine.com)

You create the MX records as follows

MX 10 mail1.example.com.

MX 20 mxXXXX.smtp-engine.com.

Because the mail1.example.com has the lowest number its considered the highest priority and email delivery will first attempt that server before resorting to the next email server on the list.

Example 6.2 - Incorrect MX Priorities

You have two mailservers for the domain example.com.  A primary mailserver called mail1 and secondary backup server, and as before we will use backupMX as the secondary MX server (mxXXXX.smtp-engine.com)

You create the MX records as follows

MX 10 mxXXXX.smtp-engine.com.

MX 20 mail1.example.com.

Because the mail1.example.com is no longer the highest priority mail server, emails in fact tried the backupMX server first.

So it is always best to check the prority order of MX records to ensure the email server you want to be the primary is the MX record with the lowest number.

Solution 7 - MTA-STS

Check to see if you have published in DNS a MTA-STS record and if so is correct?

If you have a MTA-STS policy in place it's important to ensure it includes all the methods your domain can receive emails and from where.

Please see the FAQ on MTA-STS and TLS-RPT.