It is not uncommon to have a single server that is the sole provider of email for a domain. There is no requirement that a domain have multiple receiving mail servers or that those mail servers be in different subnets. It is a best practice, certainly, but no RFC is being broken by not doing those things.
We have received a warning in a DNS checking system that warns of only
having one MX record as well as warning that our NS and MX records are
not in different subnets.
What DNS check are you using? I think they are being very aggressive with their warnings, unless they are simply listing those as suggestions or "best practices." Furthermore, are your clients experiencing any problems or complaining?
Will this make a difference to the incoming load on the mail server?
Having two MX records point to the same mail server will have no effect on load.
Is this even a valid problem?
Yes, it's a valid problem. However you have to gauge just how much redundancy you need and what services your customers are satisfied with. Two MX records pointing to one server does nothing except keep up appearances. The same goes for NS records. Having two mail servers for your domain that are both synced and accepting mail for the same email addresses is adding redundancy to your systems. However you can certainly operate a set of mail domains on one server and thus have only one MX record without "breaking anything. Please make sure that you protect yourself through adequate backup and restoration procedures that give you acceptable Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
How can we handle the issues that the DNS check is referring to?
You can assign multiple IP addresses to your server and have your mail daemon listen on those multiple IP addresses. Then create an A record for each IP address, and then attendant MX records that point to the A records. Does that "solve" it? It satisfies the letter of the law but not the spirit. It suppresses that warning from whichever DNS check you're using, but it doesn't solve the underlying issue that the warning intends to alert you to. The warning is telling you to have two email servers, not just two MX records.
To truly solve the issue, have two mail servers if possible.
I don't know how to handle the warning that the MX records should be
on a different subnet from each other.
That is, in my opinion, a very aggressive suggestion. Technically you could once again satisfy the letter of the law, if not the spirit. You could have your server provider give you an IP address on a different subnet but the same VLAN that your server is on and assign it to an interface. It would do nothing but take your money and introduce fruitless complexity, however.
Where can I learn more about these topics?
I would recommend DNS and Bind by Cricket Liu as a good place to start. Also, inspect pertinent RFCs and seek to understand them.
TL;DR
The warnings that you are receiving are telling you about your system's shortcoming in measuring up to best practices. They are not absolutely necessary to the safe operation of a mail system. Unless you have the time and money to invest in another server, you may safely ignore those warnings insofar as you also take due diligence to backup your data and practice proper, timely restorations.
Best Answer
This is done by modifying the
LocalNetPriorityNetMasksettings. It tells your DNS server which networks are local to itself. Unfortunately, it is "Subnet Mask" based, and you aren't using logical subnet boundaries with your .10, .20, .30 convention. So, it's not a perfect solution, but you might be able to make it work depending on the true network addresses you are using.First of all, here is information on using LocalNetPriority and LocalNetPriorityNetmask. It can be partially configured via the DNS management console, command line and/or with group policy by adding/modifying the registry keys here:
HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LocalNetPriorityHKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LocalNetPriorityNetMaskConfiguring Subnet Prioritization
Description of the Netmask Ordering principal
The LocalNetPriorityNetmask is more akin to a Cisco Wildcard mask. i.e. It is inverted. So, in your case an example would be to change LocalNetPriorityNetMask to use a subnet mask of /21 (255.255.248.0) e.g.
0x000007FFThis would place systems in the following IP ranges on the "same" local network as far as DNS is concerned:
192.168.8.0 - 192.168.15.255192.168.16.0 - 192.168.23.0This covers two of your examples. But the 3rd one we fall apart. If we continue with this netmask across all our DNS servers then we get the following IP range:
192.168.24.0 - 192.168.31.255This doesn't cover both IP addresses you provided at the .30 location. Unfortunately, you would have to increase the size of your LocalNetPriorityNetMask to /18 to cover the .30 and .32 IP addresses and this unfortunately would include the entire range 192.168.0.0 - 192.168.63.255.
So, you can see this breaks down because your IP addressing scheme does not follow logical subnet boundaries. You'll have to see what you can do to make this work. But, the above information is how it is done.