If you would like to read the other parts in this article series please go to:
In this final article of our series about SPF and reverse DNS, we will be validating a reverse DNS, address some best practices related to Firewall and Reverse DNS to prevent your Exchange Server being in a black list.
In order to test we can use the address http://mxtoolbox.com and type in ptr:<IP-address> format and hit enter, the result will be shown underneath, as shown in Figure 01.
Using nslookup we have the same results (Figure 02), the only difference between the first and the second attempt is that we used set type=ptr and the output in the second instacne comes with the information using in-addr.arp format.
In the previous article, a simple scenario was shown but there are a couple of best practices that can save a lot of time for the administrator down the road and at the same time increase your security.
The first recommendation is for those environments that have a range of Public IPs available on their Firewalls. In the scenario depicted on Figure 03, a recommendation is to force all the Exchange traffic (especially the SMTP 25 outbound) to use a different IP from the rest of servers and end-users. Let’s say that by default your firewall uses the IP 188.8.131.52 as the outbound IP, then a possible solution would be to assign another Public IP (in this case 184.108.40.206) to Exchange when going out to the Internet.
This simple change avoids any infected server or workstation doing any damage with the Public IP of your Exchange Server, and if you can implement that, then make sure to create your reverse DNS for that specific Public IP before making the changes at the firewall level.
The second suggestion is to make sure that only Exchange Server(s) is/are able to go out on the Internet using the 25 (SMTP) port, as shown in Figure 04. That is key to keeping your Exchange Server out of a black list. A simple scenario where this simple rule can prevent a lot of problems is when there is no restriction for the 25 port in place (trust me I’ve seen that in the field). Then, a workstation or even another server gets infected and it starts sending spam all over the Internet, and this kind of activity most likely will get your Public IP blacklisted (if you are using the same Public IP for Exchange and other traffic).
If you are using a Load Balancer solution on your environment, make sure to check which IP address is being used by Exchange Server(s) because sometimes the IP is coming from the Load Balancer and not from Exchange. Check with your Load Balancer vendor or Firewall logs before enforcing the firewall rule.
The third suggestion is to keep it simple and consistent, if you have several Exchange Servers on the same site that are able to send message to the Internet, make sure that all of them share the same Public IP.
In this article series, we went over these two important components related to DNS and they have been around for a long time, for instance SPF was introduced back in Exchange Server 2003 SP2 if my memory serves me well). So how about the Cloud/Office 365, do we need to worry about those two items? Yes, definitely!
What do I need to configure based on my scenario? We created the matrix bellow to illustrate the requirements based on your scenario. Although the rule to memorize is simple: SPF should be always configured, and Reverse DNS does not require configuration only when you have a full Office365 scenario (no on-premises involved).
Using Office365 admin portal (Figure 05), the administrator can check the DNS requirements for any domain configured. If we look at the Exchange Online section we can see the recommendations. For this article we are interested only on the TXT (which is the SPF record) and it is a requirement to add include:spf.protection.outlook.com in your existent SPF before you start sending outbound traffic through Office365.
The same rule applies for EOP (Exchange Online Protection) customers that are not using Office365. These are the basic steps required before configuring the service, and the second step should be performed for any new Public IP that you are planning to add to your infrastructure later on.
In this section, we are listing some of the questions that are most common when the discussion is about SPF and reverse DNS, and some of them I got from customers and others on the forums/communities on the Internet.
Question: Should I configure SPF records on my internal DNS zone?
Answer: The simple answer is no and it will not do you any good configuring it. The SPF should always be configured on the Public DNS Zone.
Question: Can I go ahead and create a reverse zone on my DNS and will it work automaGically?
Answer: No, you must have the sub-delegation from your ISP (check the second article of this series) and your DNS service must provide the reserve lookup zones feature (it is built-in on DNS Server running on Windows, but not that common on DNS providers on the Internet).
Question: Microsoft Wizard is telling me that I do not have an SPF however I do see the entry in my DNS, am I doing something wrong?
Answer: No, unfortunately, TXT records nowadays are used for several other purposes including verification of Office365 domains, Hybrid configuration etc. The Microsoft wizard sometimes confuses all that information and gives an error, but just ignore it.
Question: What is the difference between spf:domain.ca and txt:domain.ca when using MXToolbox.com webpage?
Answer: The TXT will give all the information as is in the DNS records, and using spf: then a nice graphical view with validation will be displayed.
Question: What is the difference between SPF record and TXT record?
Answer: SPF record is not a special type of record on your DNS, all the information related to SPF is defined in a TXT record. You will not find an SPF record entry (in most of DNS providers) but a TXT instead.
Question: Can I get away with reverse DNS if I have all outbound traffic going to EOP/Office365?
Answer: No, Microsoft recommends that you configure the reverse of all servers that will send messages outbound even when they relay those messages in Office365/EOP.
Question: My Exchange Server does not have a static IP address and the range that I have is in a blacklist. Do I have any chances of sending an outbound message and not be blocked or have my e-mails arriving in the Junk e-mail folder of the end-users?
Answer: My recommendation is to move your stuff to Office365 to avoid any problems. If Office365 is not an option, then I would recommend using services from some providers that allow you to send and receive e-mails through their servers.
Question: (continuing from the previous question), well besides having dynamic IPs my provider also blocks the 25 port, do I still have a chance?
Answer: The situation is getting worse by the minute, but yes, you can still use the same providers to receive your e-mail (your domain MX record will be pointing to the provider service) and they will forward in a specific port to your environment. The solution is not elegant and there are many moving parts on that equation, so I would recommend using a Cloud Service or getting a static IP address to reduce the complexity of the production environment.
In this final article of our series, we went over some recommendations about reverse DNS and some hints to use on your firewall to improve your overall security. The last section was a Q&A about some common questions about SPF and reverse DNS.
Some of the resources that were used during the creation of this article series are listed in this section for future reference.
If you would like to read the other parts in this article series please go to:
Deep fakes are a catastrophe waiting to happen. Facebook’s attempt to create a tool that differentiates between real and fake…
Microsoft Intune is getting a bunch of new updates that will streamline the administration experience for users of the popular…
As businesses evolve into a SaaS/IaaS model for accessing applications, new network technology is crucial. SD-WAN is just such a…
What you don’t know about Exchange and your network can come back to bite you. Monitoring Exchange is one way…
Warnings are nice, except when they are annoying and unnecessary. Here’s a tip to show you how to remove warning…
Having a Group Policy Central Store in Active Directory made life easier for administrators. But does it still work in…