In the previous article we talked about what PTR records, A records, and MX records are. This article will explain how misconfiguration of these DNS records could negatively impact the functionality of your Email Server.

Why PTR records are Important for Email Servers

Networks or servers may utilize PTR records to help determine whether a connection from a particular IP is wanted. This should be important to Email Server operators, as it could affect the ability to connect, and therefore the ability to send email. Having a PTR record that doesn’t look like unwanted traffic will improve your Email Server’s chances of successfully sending an email.

For example, IPs that do not have a PTR record configured will show up as ‘NXDOMAIN’ when a reverse DNS lookup is performed on that IP. Such IPs are considered not properly configured to be an Email Server. There is an extremely high chance when attempting to send email from an Email Server with no PTR record that it will be outright rejected by the receiving server. And rightfully so, as a large portion of devices infected with malware — specifically malware that enables it to send spam — happen to have no PTR records.

:~$ nslookup 1.2.3.4
** server can't find 4.3.2.1.in-addr.arpa: NXDOMAIN

Merely having a PTR record also isn’t enough. PTR records often will reflect the type of network or device that is behind the IP. Home users will usually have a very particular PTR naming convention. Below is an example of a home user IP:

:~$ host 64.46.8.84
84.8.46.64.in-addr.arpa domain name pointer 64-46-8-84.dyn.novuscom.net.

The format of “ip.address.isp.domain” is a very common PTR naming convention for IPs purposed for home users. In this case, the ‘dyn’ in the PTR would infer that it is a dynamic IP. If you haven’t already, you should make sure the IP of your Email Server is NOT dynamic, as Email Servers should not be using dynamic IPs.

It’s fairly common that Email Servers will have the ability to check that the PTR does not look like a home user’s IP and perform an action (such as filtering or rejecting) based on this. Falling in a similar line of logic with not having a PTR record, a large portion of devices infected with malware happen to be home user devices. Therefore, it is important that the PTR of an IP running an Email Server is updated to a custom record that indicates the responsible party’s domain and that it is a server that will be sending email.

Why MX records are Important for Email Servers

MX records provide other Email Servers the information needed to properly reply to emails that it has received from remote sources by locating the correct Email Server that stores the email of the email address being replied to. Lacking an MX record could potentially affect email deliverability. MX records are considered optional by standards (RFC 5321), but today the majority of Email Servers will have an MX record.

Some Email Servers have the ability to make an MX record lookup while in the process of receiving an email (viz. Simple Mail Transfer Protocol). Such a check could be done on the remote Email Server’s IP address, PTR record, or MAILFROM domain. Although it may not be that effective as a check for identifying unwanted email, it has been observed in the past that a decent amount of Spam comes from domains with no MX record. This observation could compel some Email Server operators to perform this check and action accordingly. Be aware that some Email Servers will make this check, even if you don’t necessarily believe that they *should*.

Why A records are Important for Email Servers

Since MX records are optional, if your Email Server does not have an MX record it won’t necessarily mean that you wouldn’t be able to receive email. The default action in this case is to attempt to deliver based on the A record of the domain of the email being replied to.

There is another case (albeit uncommon, nor recommended) where A records could affect email deliverability negatively. Some Email Server operators will check the A records in an email that it has received. This can be the domain in the PTR record, the MAILFROM address (SMTP), the From address (Email headers), or the domain of a URL in the body of the email.

What happens is that the IP addresses obtained from these A record checks will be checked against Real-Time Blackhole Lists (RBLs). Many RBLs discourage this type of check, as it requires a very specific type of RBL to make this check effective. However, it has been observed that despite this, some Email Server operators will use RBLs in this unintended way and filter or reject the email if they find an A record listed on an RBL. Again, even if you do not agree with this check, be aware that some Email Servers will make this check.

Conclusion

There are so many Email Servers out there in the world, operated by many different people. It shouldn’t be a surprise that these Email Server operators have different methods when it comes to accepting and filtering email, based on what they see in their part of the world. Since many small to medium sized Email Servers depend on being able to deliver to extremely large email services such as Gmail, they will be forced to conform with Gmail’s requirements for accepting email in order to keep clients happy.

Being aware of all of the little things that can affect your email deliverability (whether you agree with it or not) will help avoid future headaches.